El tercer proyecto de la serie no repite el enfoque de los dos anteriores. Acá el trabajo no fue sobre el ingreso de datos ni sobre la coordinación de turnos, sino sobre lo que pasa después: cómo el equipo de soporte de una operadora ferroviaria lee lo que ya tiene registrado y decide qué hacer con eso.
Cuando empezamos a trabajar con la mesa de soporte de una empresa de mantenimiento de vía, el pedido inicial era simple: ordenar los tableros que ya usaban. Tenían tres planillas distintas, un panel heredado de una herramienta vieja y un canal de mensajes donde se cargaban las incidencias de campo. Todo funcionaba, pero nadie podía responder con precisión cuántos reclamos abiertos había por sector ni cuánto tardaba en resolverse un bloqueo de vía.
La primera revisión dejó algo claro: el problema no era la falta de datos, era la falta de una lectura común. Cada supervisor interpretaba los mismos números de manera distinta porque las columnas no significaban lo mismo en cada planilla. Antes de tocar cualquier pantalla, hubo que acordar qué se consideraba una incidencia abierta, cuándo se cerraba y quién podía hacerlo.
Armamos tres talleres cortos con los supervisores de turno y con el área de calidad. En el primero mapeamos el recorrido real de una incidencia, desde que llega por radio hasta que se firma el cierre. En el segundo definimos un vocabulario mínimo: estados, prioridades y responsables. En el tercero ya estábamos mirando bocetos en papel de lo que después sería el tablero.
No hubo desarrollo a medida. Se trabajó sobre la herramienta que ya tenían, reconfigurando vistas y permisos. Eso acortó los tiempos y evitó sumar una plataforma nueva a un equipo que ya venía cargado de sistemas.
A las cuatro semanas, el reporte diario dejó de armarse a mano. Los supervisores empezaron a usar el tablero como punto de partida de la reunión de cambio de turno, y el área de calidad pudo empezar a mirar tiempos de cierre por tipo de tarea. No fue un cambio espectacular: fue un cambio que se sostuvo porque las reglas eran pocas y estaban escritas.
Lo que más costó no fue la herramienta. Fue sostener el vocabulario acordado cuando aparecían casos raros, esos que no encajan en ninguna categoría y tientan a inventar una nueva. Dejamos una regla simple: si un caso no entra en las cinco categorías, se documenta aparte y se revisa en la reunión mensual. Así el tablero no se llena de excepciones.
Este proyecto sirvió como aprendizaje para los siguientes trabajos con mesas de soporte: conviene definir el vocabulario antes de diseñar cualquier pantalla. Si los estados no están claros, el tablero más prolijo sigue siendo ilegible.
Si te interesa cómo encaramos este tipo de reordenamiento en mesas de soporte, podés escribirnos desde contacto o revisar el enfoque general en soluciones.