Un proyecto concreto que suma un ángulo distinto sin repetir lo que ya se contó en los casos anteriores.
Cuando cerramos la primera etapa del portal de soporte, el equipo de administración de carteras ya tenía un tablero funcionando. Pero a las pocas semanas empezaron a llegar consultas que no encajaban en ninguna categoría prevista: reclamos por filtraciones en oficinas del corredor Panamericana, pedidos de acceso para proveedores de mantenimiento, y avisos de variaciones en el consumo eléctrico de dos torres en Puerto Madero. Todo eso terminaba en correos sueltos o en planillas paralelas que nadie consolidaba.
El problema no era técnico. Era de diseño de información. El tablero original estaba pensado para reportar avance de obra, no para absorber señales operativas que llegan después de la entrega. Revisamos los registros de tres meses y encontramos que casi el 40% de los tickets se resolvían fuera del sistema, sin trazabilidad ni responsable asignado.
Reorganizamos el tablero en tres capas: incidencias de obra, consultas de ocupantes y alertas de consumo. Cada capa tiene su propio responsable y su propio tiempo de respuesta esperado. Incorporamos un campo de clasificación obligatorio que antes era opcional, y eso solo ya redujo los tickets sin categoría a menos de una decena por mes.
Lo que no resolvimos: la integración con el sistema contable del cliente quedó fuera del alcance por una decisión de prioridades. Los datos de facturación siguen cruzándose a mano. Es una limitación conocida y documentada, no un olvido. Para el próximo trimestre está previsto revisar si conviene abordarla o mantener el proceso manual.
El aprendizaje más útil fue entender que un tablero de soporte no se diseña una vez. Se ajusta cuando cambia el tipo de consulta que recibe. Eso es lo que diferencia este caso del resto de la serie: acá el trabajo empieza después de la entrega, no antes.
El tablero que usaba el equipo de soporte para seguir reclamos de inquilinos corporativos arrastraba planillas paralelas y reportes armados a mano cada lunes. La actualización no buscó sumar pantallas nuevas, sino ordenar qué se mira primero y qué se puede dejar de mirar.
Durante tres años se fueron agregando widgets a pedido de distintas áreas: mantenimiento, cobranzas, seguridad y atención a locatarios. El resultado era una pantalla con catorce bloques donde nadie sabía cuál era el indicador prioritario de la mañana. Antes de rediseñar, se hizo un relevamiento de qué consultaba cada rol y con qué frecuencia real.
La primera versión organizaba la información por sector interno. La segunda la reorganizó por momento del día: apertura, mediodía y cierre. Eso obligó a discutir qué métrica importa a las 8 y cuál recién a las 17. Los indicadores de reclamos críticos en oficinas premium quedaron arriba; los reportes históricos de ocupación bajaron a una pestaña secundaria.
No se podía reemplazar la herramienta de tickets porque el equipo de mantenimiento ya tenía flujos armados ahí. El refresh se hizo como capa de lectura sobre esa base, con actualización cada quince minutos. Eso limitó la sensación de tiempo real, pero evitó duplicar registros y mantuvo un único historial por reclamo.
Después de dos meses, el armado del reporte semanal pasó de casi una jornada completa a una revisión de veinte minutos sobre datos ya consolidados. Lo más útil no fue la velocidad sino la trazabilidad: cada número del tablero ahora se puede abrir y ver de qué ticket o contrato proviene, algo que antes quedaba en la memoria de quien armaba la planilla.
La siguiente etapa es conectar los reclamos recurrentes de un mismo edificio con el cronograma de obra o mantenimiento preventivo. Hoy esa relación se detecta a mano. También falta definir quién recibe las alertas fuera del horario laboral, un tema más de proceso que de software y que el equipo todavía discute.
El refresh del tablero se documentó como caso interno para futuras integraciones en otros edificios de la cartera. Si querés ver cómo se aplicó en un activo puntual, está disponible el detalle del proyecto.
Ver el caso completoCanales de soporte para equipos de facility y administración de carteras
Después de la primera iteración del Support Dashboard Refresh en un edificio corporativo de Puerto Madero, quedó claro que el tablero no se sostiene solo con buena visualización de datos. La mesa de soporte recibía consultas por canales dispersos y el tiempo de respuesta variaba según quién estuviera de guardia. Definimos tres vías de contacto formales y un esquema de tiempos que ahora se replica en otros activos de la cartera.
Para incidencias que afectan la operación diaria del edificio: accesos, climatización, ascensores, control de iluminación. Se atiende por correo a info@pharajon.com y por teléfono al +54 9 11 0018 7888 de lunes a viernes de 8 a 19 h. El equipo de guardia confirma recepción y asigna responsable dentro de la primera hora hábil.
Dudas sobre cánones, liquidaciones, lecturas de medidores o modificaciones de contrato van por correo con copia al administrador del consorcio. Respondemos en un plazo de dos días hábiles. Si la consulta requiere revisar documentación de obra o certificados LEED del activo, se coordina una reunión breve antes de responder por escrito.
Los usuarios del dashboard pueden señalar métricas faltantes, filtros confusos o alertas mal calibradas. Estas observaciones se agrupan y se revisan cada quince días con el equipo de producto. No son urgencias operativas, pero son la materia prima del próximo ajuste del tablero.
Tiempos de referencia acordados con los ocupantes: incidencia crítica, respuesta en 1 hora; consulta administrativa, 48 horas hábiles; sugerencia de producto, revisión quincenal. Fuera de horario, el teléfono deriva a guardia externa y el correo queda registrado para el día siguiente.
Antes de escribir, conviene revisar las vías de contacto generales o consultar las condiciones de uso del portal en términos.
Antes de arrancar con el rediseño del panel de soporte para la administración de carteras comerciales, dejamos por escrito los alcances. La idea es simple: evitar que cada área interprete lo mismo de forma distinta a mitad del proyecto. El refresh abarca la capa de visualización de tickets, el histórico de incidencias por edificio y los filtros por contrato de locación. No toca el motor de facturación ni la integración con el sistema contable, que siguen operando como hasta ahora. Tampoco reemplaza la carga manual de reclamos de mantenimiento: eso queda para una etapa posterior, cuando el equipo de operaciones valide los flujos nuevos.
El refresh del dashboard de soporte en Pharajon no lo cerró un proveedor externo. Lo llevó adelante el equipo interno de operaciones, con la coordinación de Sofía Rojas Flores, que viene del lado de la administración de carteras comerciales y no del software. Esa diferencia se nota en las decisiones: menos widgets, más trazabilidad por contrato.
Sofía trabaja en Pharajon desde la etapa de oficinas en el corredor Panamericana y hoy supervisa la lectura de indicadores de ocupación, vencimientos y reclamos técnicos en torres corporativas y parques industriales privados. Antes de este proyecto había pasado por mesas de tasación y por la puesta en marcha de un sistema de contratos en la nube, así que conoce de cerca el momento en que una planilla deja de alcanzar. En el refresh del dashboard se ocupó de definir qué métrica merece estar arriba y cuál puede esperar al reporte mensual, una discusión menos técnica de lo que parece y más ligada a cómo se toman decisiones de inversión.
Para consultas sobre este caso, plazos de implementación o criterios de seguimiento, conviene escribir directo. Respondemos desde Córdoba, con reuniones presenciales en Buenos Aires cuando el proyecto lo pide.
Calle Pública 5, Córdoba, Córdoba, X5000, Argentina.