Un jueves a las 6 de la mañana, la bodega principal de Logística Andina en Funza no pudo despachar durante tres horas. Las pistolas de escaneo no sincronizaban con el sistema de inventario.

El jefe de bodega había reportado la falla el martes. Lo hizo por correo a un ingeniero que ese día estaba atendiendo otra sede. El correo quedó enterrado entre 140 mensajes sin leer.

La gerencia pidió una auditoría y el resultado fue peor de lo que esperaban: 37% de las solicitudes a TI de los últimos tres meses no tenía ninguna respuesta registrada.

Las solicitudes llegaban por cinco canales: correo personal de cada ingeniero, un buzón compartido, Teams, llamadas y el famoso “ya que pasas por aquí”. No había prioridad, no había dueño y no había forma de saber cuánto se demoraba algo.

El equipo de TI no era lento. Estaba atendiendo lo que gritaba más fuerte, y eso casi nunca coincidía con lo que más impacto tenía en la operación.

Diseñamos la mesa de ayuda alrededor de una pregunta: ¿qué tan rápido debemos responder según el impacto en la operación? De ahí salió la matriz de prioridad y los SLA.

Un formulario de ClickUp, publicado en la intranet y en un código QR pegado en cada bodega, es la única entrada. El formulario pide sede, categoría e impacto. Con eso una automatización calcula la prioridad, asigna al ingeniero de la sede y pone la fecha límite según el SLA.

Si la fecha límite se vence, la tarea cambia a estado “SLA vencido”, se reasigna al líder de TI y llega una notificación a su celular.

La parte técnica tomó dos semanas. Lo que más tiempo llevó fue acordar la matriz de prioridad con los jefes de cada sede, porque todos querían que lo suyo fuera crítico.

En el piloto, el 60% de los tickets llegaba marcado como “Crítico”. Los usuarios aprendieron rápido que crítico se atendía primero.

Cambiamos la pregunta del formulario. En lugar de “¿Qué prioridad tiene?” preguntamos “¿Qué pasa si esto no se resuelve hoy?” con opciones concretas (“la sede no puede despachar”, “una persona no puede trabajar”, “es una molestia”). Los tickets críticos bajaron a 8%, que era lo real.

El dashboard de la mesa de ayuda muestra cada semana el cumplimiento de SLA, los tickets abiertos por sede y las categorías que más se repiten. Ese último dato llevó a cambiar 40 escáneres que generaban un tercio de los tickets.