Reconstruir el tablero de soporte para que el equipo de atención vea primero lo que decide, no lo que solo informa.
Este proyecto arrancó con una queja concreta: el tablero de soporte tenía veintiocho paneles y nadie lo abría antes de las once de la mañana. El equipo de atención al cliente de una cadena de retail con operación en Buenos Aires y Rosario lo usaba como archivo de consulta, no como herramienta de trabajo. La tarea no era sumar métricas nuevas, sino decidir cuáles sobraban.
El tablero pasó de veintiocho paneles a nueve visibles, con tres indicadores críticos en la franja superior. El equipo empezó a abrirlo al inicio del turno, no a media mañana. Las consultas por chat sobre "cómo venía el día" bajaron porque el dato estaba donde se esperaba. Y el panel de reaperturas, que antes vivía escondido, se volvió el más consultado: mostraba un problema de clasificación de casos que se venía arrastrando sin que nadie lo mirara de frente.
No hubo cambio de herramienta ni migración de plataforma. Todo el rediseño se hizo sobre la misma base, con criterio de priorización y una limpieza que llevó más tiempo discutir que ejecutar. Ese suele ser el punto que se subestima en este tipo de proyectos.
El proyecto Support Dashboard Refresh no salió de una hoja en blanco. Detrás hay un equipo chico que trabaja con datos de atención al cliente todos los días y que conoce de memoria las planillas que el tablero vino a reemplazar.
Lideró la definición de las cinco métricas que quedaron en el tablero: tiempo de primera respuesta, reapertura de tickets, backlog por turno, motivo de contacto y resolución en el primer contacto. Antes de eso pasó dos semanas revisando qué se consultaba de verdad en los reportes viejos y qué nadie abría nunca.
Se encargó de unificar las fuentes que alimentan el tablero: el sistema de tickets, la base de clientes y el registro de devoluciones. El trabajo más pesado no fue el modelo sino limpiar los estados duplicados que arrastraban años de carga manual y que hacían que dos áreas contaran el mismo ticket como propio.
Los supervisores de turno participaron desde la primera versión del prototipo. Aportaron los casos raros que ningún manual recoge: picos de consultas por cortes de servicio, campañas que saturan un canal y reclamos que llegan por vías informales. Sin esa lectura, el tablero habría mostrado números correctos pero inútiles para decidir.
Después de la puesta en marcha quedó una rutina de revisión semanal: se comparan los indicadores con lo que reportan los supervisores y se ajustan umbrales cuando el volumen cambia por temporada. Es la parte menos vistosa del proyecto y la que evita que el tablero se convierta en otro reporte archivado.
Si querés ver cómo se armó el tablero, qué datos entraron y qué decisiones habilitó, el detalle del proyecto está en la página principal.
Ver el caso completoCanales de soporte para el tablero de atención al cliente de Magic AI Pro
El proyecto Support Dashboard Refresh dejó el tablero de atención en un estado que ya no depende de una sola persona para interpretarse. Pero un panel nuevo también genera dudas nuevas: por qué un ticket aparece con prioridad distinta a la que se cargó, por qué una métrica de tiempo de primera respuesta se movió sin que nadie tocara la configuración, o qué hacer cuando el equipo de guardia no coincide con el turno que reportó el problema. Estas son las vías reales para resolverlo, con el tiempo de respuesta que manejamos hoy.
Escribí a info@magicaipro.com detallando el nombre del panel, la sucursal o el turno afectado y una captura del filtro que estás usando. Respondemos dentro de las 24 horas hábiles. Si el problema bloquea la operación de un turno completo, indicalo en el asunto y se prioriza el mismo día.
Para casos donde el tablero no carga o muestra datos de un turno anterior, llamá al +54 9 11 7077 2838. La línea se atiende de lunes a viernes de 9 a 18, hora de Buenos Aires. Fuera de ese horario queda registro en el buzón y se retoma a primera hora del día siguiente.
Si después de usar el tablero refrescado querés sumar un indicador, ajustar umbrales de alerta o cambiar la lógica de prioridades, la solicitud se evalúa en una reunión breve. Estos pedidos no son incidencias: se agendan y se responden en un plazo de tres días hábiles con una propuesta concreta de qué se puede tocar sin romper los cálculos existentes.
Antes de escribir, vale revisar las preguntas frecuentes: varias dudas sobre filtros de fecha, permisos por rol y diferencias entre tiempo de primera respuesta y tiempo de resolución ya están documentadas ahí. Si tu caso no aparece, escribinos igual y lo sumamos.
Ver contacto y horarios de atención o consultar las condiciones de uso del panel.
El tablero anterior tenía veintitrés métricas y nadie lo abría después de la reunión de los lunes. Lo rearmamos alrededor de tres preguntas concretas: qué se está rompiendo ahora, cuánto tarda en resolverse y quién queda trabado esperando respuesta. La primera versión quedó en producción a las tres semanas, con datos del sistema de tickets y del chat interno.
El trabajo no fue de diseño visual. Fue de recorte. Sacamos gráficos que se veían bien pero no disparaban ninguna acción, y dejamos una fila de alertas que se actualiza cada quince minutos. El resto del panel es contexto: volumen por franja horaria, backlog por antigüedad y reincidencia por cliente.
Antes el equipo miraba el total del día a las seis de la tarde. Ahora ve la cola abierta en tiempo real, ordenada por antigüedad y por criticidad del cliente. Eso cambió el orden en que se agarran los casos.
Mezclar ambos indicadores escondía el problema real. Al separarlos quedó visible que la demora estaba en la asignación, no en la resolución. El cuello de botella no era el que suponíamos.
El panel muestra cuántos casos activos tiene cada persona y desde cuándo. Sirve para reasignar sin preguntar en el chat. También expone los turnos donde la carga se concentra y el resto queda ocioso.
Un ticket cerrado que reaparece a los diez días no es un ticket nuevo. Marcamos esos casos y los agrupamos por causa. La mitad venía de respuestas incompletas en el primer contacto.
No reemplaza criterio ni prioriza por sí solo. Si la etiqueta del ticket está mal puesta, el dato miente. La calidad de la clasificación sigue dependiendo de quien atiende, y eso no lo arregla ninguna vista.
La etapa que viene es anticipar: detectar patrones de caída en un servicio y avisar al equipo antes de que llegue el primer reclamo. Todavía estamos midiendo qué señales sirven y cuáles generan ruido.
El tablero de soporte se rearmó en seis semanas. Antes de tocar la herramienta, el equipo acordó qué preguntas debía responder cada turno y quién las hacía. Sin ese paso, cualquier rediseño termina siendo cosmético.
Consultar por diagnósticos similaresUn caso de rediseño de tablero operativo en un centro de atención al cliente de una cadena minorista argentina. El problema no era la falta de datos, sino que nadie sabía qué mirar primero al abrir el turno.
Punto de partidaCuarenta y dos métricas repartidas en cuatro pantallas, sin jerarquía. Los supervisores abrían el tablero, revisaban dos números y volvían al Excel paralelo que habían armado por costumbre.
Qué se cambióSe redujo la vista de turno a cinco indicadores: cola viva, tiempo de primera respuesta, reaperturas, casos escalados y adherencia al guion. El resto quedó en una vista de análisis separada, consultable pero fuera del flujo diario.
Datos que faltabanEl sistema de tickets no registraba bien los motivos de contacto. Se trabajó tres semanas en normalizar categorías antes de construir cualquier visualización. Sin ese trabajo previo, los filtros habrían mostrado ruido.
AdopciónLa adopción se midió por uso real: cuántas veces se abría el tablero por turno y cuántas decisiones quedaban registradas. El Excel paralelo se abandonó recién en la quinta semana, cuando los supervisores empezaron a citar el tablero en las reuniones de traspaso.
Qué quedó pendienteLa integración con el sistema de fuerza laboral sigue manual. Estimar dotación por franja horaria requiere exportar datos y cruzarlos aparte. Es el próximo paso acordado con el área.