Si un panel deja de refrescar, una fuente de datos del sistema de tickets se cae o los indicadores muestran valores inconsistentes, abrimos el caso con prioridad alta. El equipo de guardia responde dentro de las primeras dos horas hábiles y trabaja con el cliente para aislar si el problema está en la capa de ingesta, en la transformación o en el propio origen. Mientras se resuelve, dejamos un panel alternativo con los últimos datos válidos para que el equipo de soporte no pierda visibilidad.
Support Dashboard Refresh
Reordenar las señales del equipo de soporte para que la operación diaria deje de depender de tres planillas paralelas.
El pedido llegó desde un área de soporte técnico con nueve analistas y dos turnos. Trabajaban sobre una herramienta heredada que mostraba tickets abiertos, pero no distinguía entre incidencias de infraestructura cloud, consultas de accesos y pedidos de cambio en bases de datos corporativas. Cada analista llevaba su propio control en hojas de cálculo para no perder el hilo de los casos que escalaban a segundo nivel.
El objetivo no era sumar otra pantalla, sino reducir el tiempo que se pierde reconstruyendo contexto antes de responder. La consigna fue concreta: que cualquier persona del turno entrante entienda en menos de un minuto qué está crítico, qué está esperando respuesta de un tercero y qué ya tiene dueño asignado.
Qué había que resolver
La herramienta anterior mezclaba severidad con antigüedad. Un ticket de baja prioridad abierto hacía tres días aparecía arriba de una caída de servicio reportada hacía veinte minutos. Además, los estados no estaban normalizados: "en revisión", "pendiente cliente" y "esperando proveedor" se usaban de forma distinta según quién los cargara, así que los reportes mensuales no cerraban entre turnos.
También faltaba visibilidad sobre la carga real. Nadie sabía si un analista tenía ocho casos activos o veinte, porque el conteo se hacía a mano al cierre del día. Eso generaba escalamientos tardíos y una sensación permanente de urgencia que no siempre se correspondía con la criticidad técnica.
Cómo lo encaramos
Antes de tocar la interfaz hicimos un relevamiento de dos semanas observando cómo se usaban los estados en la práctica. De ahí salió una lista corta de cinco estados posibles, con una regla de transición clara para cada uno. Lo que no encajaba en esos cinco se resolvió como etiqueta secundaria, no como estado nuevo.
Definimos tres vistas en lugar de una única pantalla saturada: una de guardia con lo crítico y lo que está por vencer, una de seguimiento por responsable, y una de cierre para revisar casos resueltos y detectar reincidencias. Cada vista responde a un momento distinto del turno, no a un rol jerárquico.
Implementación
La integración se hizo sobre la API del sistema de tickets existente, sin migrar el histórico. Se agregó una capa de normalización que traduce los estados viejos a los nuevos y marca los casos ambiguos para revisión manual durante las primeras semanas. El panel de guardia se actualiza cada minuto; las otras dos vistas, cada quince, para no castigar la base con consultas innecesarias.
Sumamos un indicador de carga por analista que cuenta casos activos ponderados por severidad, no por cantidad bruta. Un caso crítico pesa más que tres consultas de acceso. Ese número se acordó con el equipo antes de programarlo, porque de nada sirve una métrica que el propio equipo no reconoce como justa.
Qué cambió después
El traspaso de turno pasó de una reunión de veinte minutos a una revisión de la vista de guardia en cinco. Los escalamientos a segundo nivel ahora llevan motivo obligatorio, lo que permitió ver que casi la mitad de los casos que subían eran en realidad pedidos de acceso mal clasificados en origen. Eso derivó en un ajuste del formulario de entrada, no en más personal.
Los reportes mensuales dejaron de discutirse. Al estar los estados normalizados, el conteo entre turnos coincide y las diferencias se explican por casos puntuales, no por criterios distintos. Quedó pendiente revisar la vista de cierre cada trimestre, porque las reincidencias cambian según la estacionalidad de la operación.
Este trabajo se apoyó en lo aprendido en el portal de incorporación de clientes, donde ya habíamos normalizado estados de proceso para un flujo con varios responsables.
Para ver el conjunto de casos del área, está la sección de proyectos.