Cómo medir el SLA de soporte (y por dónde empezar a mejorarlo)
Guía práctica para medir el SLA de soporte sin hojas de cálculo: qué tiempos importan, cómo se calculan y qué hacer cuando no los cumples.
El director de soporte de una empresa de software que usa MelonHelp nos contó algo que se repite más de lo que pensábamos: cada vez que liderazgo le preguntaba cómo iba el área, no tenía una respuesta con números, solo la sensación de si el equipo venía bien o mal. El problema se puso serio cuando necesitó pedir una persona más para el equipo y no tuvo con qué justificarlo: ni un tiempo de respuesta promedio, ni un porcentaje de tickets resueltos a tiempo, nada que mostrarle a quien aprobaba el presupuesto. Terminó armando los números a mano, revisando conversaciones de Slack una por una, para una reunión que era en dos días.
Ese es el problema del SLA sin medir: no es que el soporte vaya mal, es que nadie puede probar si va bien. SLA significa acuerdo de nivel de servicio, y en la práctica se reduce a dos preguntas: ¿cuánto tarda tu equipo en responder por primera vez? ¿cuánto tarda en resolver? Definir esas metas y medirlas es el paso que casi todos dejan para “cuando haya tiempo”, hasta que una situación como esa obliga a resolverlo en dos días en vez de en dos meses.
Qué tiempos importan de verdad
No hace falta rastrear diez métricas para tener un SLA útil.
El tiempo de primera respuesta (FRT) es el que más pesa: desde que llega el ticket hasta que alguien del equipo responde por primera vez, aunque sea para decir “lo estamos viendo”. Junto a él va el tiempo de resolución, que cuenta desde que se abre el ticket hasta que se cierra.
Con esos dos ya se puede armar la tasa de cumplimiento: de todos los tickets del período, qué porcentaje respetó la meta que definiste. Es el número que le faltó al director de soporte del ejemplo para su reunión, y el que más usan los equipos que reportan soporte hacia arriba en la organización.
Hay quienes además miden tiempo de primera respuesta útil (una respuesta con información real, no un genérico “gracias por escribir”). Es bueno de agregar más adelante, pero si estás arrancando, con los dos primeros ya tienes más información de la que probablemente tienes hoy.
Cómo se calcula (sin vueltas)
El cálculo del FRT es una resta: hora de la primera respuesta menos hora de creación del ticket, promediada sobre el período que quieras analizar. Lo que complica no es la fórmula, es decidir qué cuenta como “hora hábil”. Si tu equipo trabaja de 9 a 18, un ticket que entra a las 22 y se responde a las 9 del día siguiente no tardó 11 horas reales de atención: tardó los minutos que pasaron desde que abrió la oficina. Definir esto antes de medir evita que tus números castiguen a tu equipo por horarios en los que nadie estaba trabajando.
La tasa de cumplimiento se calcula dividiendo los tickets que respetaron la meta por el total del período. En los equipos que vemos usar MelonHelp, apuntar a que al menos 9 de cada 10 tickets cumplan la meta suele ser razonable; bajar mucho de ahí casi siempre significa que falta un criterio claro de quién responde primero, más que un problema de que el equipo sea lento.
Por qué casi nadie lo mide
Medirlo a mano es tedioso: implica anotar en una planilla cuándo entró cada mensaje y cuándo se respondió, tal como terminó haciendo el director de soporte del ejemplo, y ese registro se abandona a la segunda semana porque nadie tiene tiempo de mantenerlo al día mientras también responde clientes.
El resultado es que el equipo opera con una sensación, no con un dato. Y esa sensación suele estar sesgada hacia lo optimista: uno recuerda los tickets que resolvió rápido, no los tres que quedaron dando vueltas cuatro días en un canal de Slack.
Qué mide MelonHelp automáticamente
Cuando un mensaje se convierte en ticket en MelonHelp (con el emoji 🎫 sobre el mensaje de Slack, o desde WhatsApp), el sistema empieza a contar el tiempo desde ese instante. Sin que nadie tenga que anotar nada, quedan registrados el momento de creación, el de la primera respuesta y el de cierre, y eso arma el reporte de tiempos: el FRT promedio y el porcentaje de tickets dentro de la meta que definiste. Es justo lo que le hubiera ahorrado al director de soporte esos dos días revisando Slack a mano.
Lo que hoy no hacemos son escalamientos automáticos complejos con múltiples niveles de SLA por prioridad. Si tu operación necesita SLAs distintos para clientes enterprise frente al resto, con reglas de escalamiento en cascada, un service desk más grande como Zendesk o Freshdesk lo va a cubrir mejor. Lo que sí resolvemos es el caso más común: un equipo chico o mediano que necesita ver sus tiempos reales sin construir una planilla ni migrar de Slack.
Qué mejora el SLA sin sumar gente al equipo
Lo primero, y lo que más impacto tiene, es dejar de asignar tickets por “el que lo vea”: definir quién responde primero cuando entra uno nuevo. La asignación ambigua es la causa número uno de tickets que tardan horas en tener una primera respuesta, más que la falta de gente.
Después ayuda separar “primera respuesta” de “resolución” en la cabeza del equipo: un ticket complejo puede tardar días en resolverse y aun así cumplir el SLA si alguien avisó rápido que ya lo estaban viendo. Y revisar el reporte una vez por semana, no una vez al mes: cuando el problema se detecta a los 30 días, ya se perdió un mes entero de tickets mal atendidos que no se pueden recuperar.
Si tu equipo todavía no tiene claro qué sistema usar para organizar esto, conviene primero resolver esa base: en qué es un sistema de gestión de tickets y cómo elegir uno repasamos las opciones antes de meterse con métricas.
Con menos de diez consultas por semana, esto todavía no hace falta
Si tu equipo recibe menos de diez consultas por semana, medir el SLA con esta rigurosidad es más trabajo del que vale la pena: cualquier persona del equipo sabe de memoria si están respondiendo rápido o no. Esto empieza a pagar su costo de configuración recién cuando el volumen sube lo suficiente como para que la memoria de nadie alcance, que es exactamente el punto en el que estaba la empresa del director de soporte cuando llegó a nosotros.
Preguntas frecuentes
¿Cuál es un buen SLA de primera respuesta para un equipo chico?
No hay un número universal, pero como referencia: por chat en vivo se esperan minutos, y por ticket o email, entre 2 y 8 horas hábiles es razonable. Más que copiar un número, fija una meta que puedas cumplir de forma consistente.
¿El SLA tiene que ser igual para todos los clientes?
No necesariamente, aunque en equipos chicos casi siempre conviene simplificarlo a una sola meta para todos. Diferenciar por cliente (por ejemplo, un SLA más estricto para las cuentas más grandes) tiene sentido cuando el volumen y la variedad lo justifican, pero mantener dos o tres SLAs distintos sin una herramienta que los automatice suele generar más errores de los que resuelve.
¿MelonHelp permite definir distintos SLA por prioridad de ticket?
Todavía no. El reporte de tiempos hoy se mide sobre una meta general que tú defines; si necesitas niveles de SLA por prioridad con reglas de escalamiento, otra herramienta te va a servir mejor por ahora.
¿Cómo sé si mi problema es de tiempos o de otra cosa?
Si el FRT es bueno pero los clientes igual se quejan, el problema probablemente no sea la velocidad sino la calidad de las respuestas: contestar rápido con algo que no resuelve nada genera más tickets, no menos. Medir el SLA te dice si respondes rápido, no si respondes bien; eso se evalúa aparte, revisando el contenido real de las conversaciones.
El director de soporte del ejemplo terminó armando esos números a mano para una sola reunión. Con MelonHelp quedan armados solos, listos para la próxima vez que alguien pregunte cómo va el soporte. Pruébalo 14 días gratis.
