Si tu equipo gestiona solicitudes entrantes, ya sean tickets de soporte al cliente, problemas del servicio de ayuda de IT, revisiones de contratos o aprobaciones internas, probablemente tienes una idea informal de cómo es un tiempo de respuesta aceptable. Un problema crítico necesita atención en una hora. Una pregunta de facturación de un cliente importa más que una pregunta general. Un ticket que llegó ayer por la mañana y no se ha tocado es un problema.

Cargas todo eso en tu cabeza. Igual que todos los demás del equipo. El problema es que cuando solo existe en las cabezas de las personas, es invisible en el tablero. Un ticket que ha estado sin respuesta durante cuatro horas parece exactamente igual que uno que acaba de llegar. Tienes que leer cada elemento para saber qué está en llamas. Las cosas se pasan por alto. Y cuando algo se pasa por alto, la conversación siempre es la misma: «¿Por qué nadie señaló esto antes?»

Para eso se supone que sirve el seguimiento de SLA. Y la mayoría de las herramientas lo ofrecen técnicamente. Pero el proceso de configuración siempre ha sido lo que impide que los equipos lo usen realmente.

El muro de configuración

Cuando buscas SLA en una herramienta empresarial típica, encuentras un panel de configuración que asume que ya sabes lo que estás haciendo. Horario comercial. Cadenas de escalada. Matrices de prioridad. Reglas de incumplimiento personalizadas por nivel. Flujos de trabajo de notificación vinculados. Es genuinamente poderoso si tienes un administrador de IT dedicado para configurarlo todo, y genuinamente inutilizable si no lo tienes.

Así que la mayoría de los equipos lo omiten. Usan fechas de vencimiento y esperan lo mejor. Algunos construyen el seguimiento en hojas de cálculo. Algunos se rinden y solo hacen un check-in matutino para ver qué ha esperado demasiado tiempo, lo que significa añadir una reunión a un problema que debería tener una solución técnica.

Queríamos cambiar eso. No haciendo la configuración más fácil. Eliminando la mayor parte de ella.

Empezar con una plantilla, no con una hoja en blanco

Lo primero que construimos fue una biblioteca de plantillas SLA organizadas por sector y tipo de equipo. Soporte IT, éxito del cliente, helpdesk de RRHH, revisión legal, instalaciones, ingeniería de software, y más. Cada plantilla viene precargada con los objetivos de respuesta y resolución estándar para ese tipo de trabajo. Primera respuesta en 1 hora para problemas críticos, 4 horas para prioridad alta, 24 horas para normal. Números que coinciden con las expectativas reales en lugar de números que tienes que investigar y justificar tú mismo.

Eliges la plantilla más cercana a tu situación, ajustas lo que no encaja, y listo con la configuración. Todo el proceso lleva unos minutos.

Puede parecer una cosa pequeña, pero elimina la mayor barrera: la hoja en blanco. La mayoría de los equipos no omiten el SLA porque no lo quieren. Lo omiten porque empezar de cero parece un proyecto en sí mismo.

Una columna. Tres cosas suceden.

Esta es la parte que todavía sorprende a la gente cuando lo ve por primera vez.

Vas al tablero donde quieres hacer seguimiento de SLA. Añades la columna SLA. Eso es todo.

Gript crea automáticamente tres columnas vinculadas: Estado (SLA), Prioridad (SLA), y el propio temporizador SLA. Están conectadas entre sí y a tu plantilla. Cuando estableces la prioridad de un ticket como Crítico, el temporizador sabe que tiene una ventana de respuesta de 1 hora. Cuando alguien cambia el estado a En espera del usuario, el reloj se pausa automáticamente. Cuando el estado pasa a Resuelto, el temporizador se detiene y el resultado queda registrado.

No configuras nada de eso. Está incorporado en la relación entre las tres columnas.

Lo que el tablero realmente te dice

Una vez que la columna SLA está en marcha, tu tablero comunica de una manera que antes no podía. Puedes ver de un vistazo qué tickets son nuevos y sin tocar, cuáles están esperando al cliente, y cuáles ya han superado su ventana. La celda SLA muestra un temporizador en vivo y una barra con código de colores en la parte inferior. Oscuro significa que el reloj todavía está corriendo. Rojo significa que la ventana ha pasado.

La columna Prioridad (SLA) gestiona la lógica de qué objetivo aplica. Un ticket crítico (P1) tiene una ventana más ajustada que uno de alta prioridad (P2). El mismo tablero puede gestionar ambos al mismo tiempo, y el sistema conoce la diferencia sin que tengas que hacer nada extra.

La columna Estado (SLA) está separada del estado de tarea habitual, y eso es intencional. Cuando un ticket pasa a En espera del usuario, el reloj se pausa. Ese tiempo no debería contar contra tu objetivo de respuesta. Cuando está Cerrado, está completamente fuera de la cola. Estos estados tienen un significado específico en el contexto SLA, y las tres columnas trabajan juntas para seguirlos correctamente.

Presupuesto de errores y Detector de sandía

El presupuesto de errores viene de la ingeniería de confiabilidad del software. Representa cuánto margen te queda antes de que incumplas tu objetivo SLA para el período. Si te comprometes a resolver el 95% de los tickets a tiempo y actualmente estás al 91,2%, tu presupuesto de errores te indica cuántos incumplimientos más puedes absorber antes de caer por debajo de ese umbral. Los equipos con un presupuesto saludable pueden asumir más volumen. Los equipos que rondan el cero necesitan ralentizarse o agregar capacidad. La mayoría de los equipos no tienen visibilidad sobre esto hasta que es demasiado tarde. Lo ponemos en primer plano.

El Detector de Sandía es diferente. El nombre viene de una expresión común en los negocios: verde por fuera, rojo por dentro. Una métrica sandía es aquella donde los números parecen buenos pero la realidad subyacente es diferente.

En el contexto SLA, la situación sandía clásica es esta: tu puntuación muestra el 96% de los tickets resueltos a tiempo, pero tu satisfacción del cliente es baja. Lo que normalmente sucede es que los equipos optimizan para la métrica reportada. Si la métrica es «¿cerramos técnicamente esto en 4 horas?», la gente encuentra formas de cerrar técnicamente las cosas en 4 horas, incluso cuando el problema real no está resuelto.

El Detector de Sandía señala esa brecha. Cuando tu puntuación SLA es alta pero las señales de satisfacción son bajas, lo destacamos como una advertencia. No como una acusación, y no como una respuesta definitiva sobre qué salió mal. Solo como una señal que vale la pena atender.

No solo para departamentos de IT. Para todos.

Lo construimos para equipos de soporte primero, porque ese es el caso de uso obvio. Pero algunos de los equipos que más provecho le han sacado no eran equipos de soporte en absoluto.

Colas de solicitudes IT internas. Revisión de contratos legales. Flujos de trabajo de aprobación financiera. Donde sea que lleguen solicitudes y alguien necesite responder dentro de un tiempo definido, el seguimiento SLA ayuda. Y porque Gript te permite ver varios tableros juntos en la página de análisis, puedes ver cómo va el SLA en diferentes equipos y proyectos desde un solo lugar.

El objetivo nunca fue construir algo para especialistas en SLA. Fue hacer que funcionara para el equipo que sabe que necesita seguimiento de tiempos de respuesta, miró las herramientas existentes, y cerró la pestaña del navegador. Elige una plantilla, añade una columna, empieza a medir.

Eso es todo.