Puntos clave
- El incumplimiento de un SLA puede deberse a un trabajo lento del técnico, al tiempo de espera externo o a horas no laborables contabilizadas por error, y cada caso exige una solución distinta.
- Separar el tiempo de trabajo activo del tiempo de espera ayuda a los equipos de TI a distinguir los problemas de rendimiento del técnico de los retrasos causados por usuarios, aprobadores, proveedores o dependencias.
- Los pasos de aprobación deben registrarse dentro del ticket, con responsables designados, plazos y rutas de escalado, para que las decisiones estancadas sigan siendo visibles y atribuibles.
- Los contadores de SLA deben basarse en el horario de soporte configurado y en los calendarios de festivos para evitar incumplimientos falsos provocados por noches, fines de semana o diferencias de calendario entre regiones.
- Las alertas previas al incumplimiento dan a los equipos de soporte margen para reasignar o escalar los tickets antes de perder los objetivos de servicio.
- Revisar los tickets incumplidos según su causa raíz ayuda a los MSP y a los equipos de informática interna a mejorar la prestación del servicio sin culpar injustamente a la rapidez del técnico.
Abre el informe de incumplimientos de esta semana y verás dos tickets aparentemente idénticos: la misma bandera roja, el mismo objetivo perdido, la misma línea en el resumen mensual. Míralos de cerca y no tienen nada en común. Uno estuvo tres días en una cola porque nadie lo cogió. El otro se diagnosticó en veinte minutos y después esperó dos días al propietario de un dispositivo que nunca abrió el correo de aprobación. Un SLA es una promesa que se hace antes de que el ticket exista. No cumplirlo es mucho más que una métrica: te cuesta la confianza de un cliente, de un responsable de departamento o de un usuario final.
Si puedes dividir el Acuerdo de Nivel de Servicio (SLA) en tiempo de trabajo y tiempo de espera, podrás demostrar con mucha más claridad dónde cumples los SLA y dónde no. Y no hace falta medir nada nuevo. Cada uno de esos minutos ya está en el historial del ticket, como un cambio de estado con su marca de tiempo. Lo que falta es la separación: el tiempo de trabajo en un lado de la cuenta y el tiempo de espera en el otro. Sin esa distinción, «no estamos cumpliendo los SLA» suena a problema del técnico, incluso en las semanas en las que tu equipo fue la parte más rápida del proceso.
Divide el reloj en tiempo de trabajo y tiempo de espera
El tiempo transcurrido entre «abierto» y «resuelto» son en realidad dos cosas superpuestas. Una parte es un técnico trabajando activamente en el ticket. El resto es el ticket aparcado, esperando a un aprobador, a un proveedor o a un usuario final que no ha contestado.
Merece la pena corregir ambos, pero no con el mismo enfoque. El tiempo de trabajo depende del contexto. Un técnico que pierde los primeros quince minutos de cada ticket buscando el historial del dispositivo y los registros de activos antes incluso de empezar a diagnosticar no es lento: lo lento es la preparación. Dale ese contexto desde el principio y el ticket que antes requería una hora de búsqueda arranca con esa búsqueda ya hecha. Esa mejora corresponde por completo al lado del tiempo de trabajo.
Ninguna mejora en la rapidez del técnico afecta al tiempo de espera. Define un estado, o un pequeño conjunto de ellos, que signifique «esperando a alguien que no somos nosotros». Asegúrate de que tu objetivo de resolución se pause en ese estado o que informe aparte del tiempo pasado en él. Ese único cambio convierte una cifra agregada en dos cifras sobre las que puedes actuar.
La aprobación es un paso más que hay que registrar
La práctica de habilitación de cambios de ITIL deja claro que un cambio requiere la autorización de alguien que responda por el riesgo. Es casi seguro que ya tienes esa autorización, pero llega por un mensaje directo de Slack o un correo de una línea, casi siempre fuera del ticket. Para un cambio de configuración de un portátil, ese nivel de proceso es el adecuado.
Pero cuando gestionas una función de soporte, un correo de aprobación sin respuesta es invisible. El ticket aparece atascado, le preguntan a tu técnico por qué y la respuesta honesta es que alguien tiene que ordenar su bandeja de entrada. Para una auditoría, una aprobación que nadie registró no existió. Añade la aprobación como un paso explícito del ticket (un aprobador designado, un responsable, el propietario del dispositivo, un rol, una lista ad hoc) y deja de ser una dependencia difusa para convertirse en una atribuible. Verás exactamente quién te debe una decisión y desde cuándo. Dale también a ese paso de aprobación un tiempo límite y una ruta de escalado. Una espera acotada es un coste conocido; una espera indefinida es una caja negra.
Que el contador siga tu horario de soporte, no el reloj de pared
Un objetivo de resolución de ocho horas medido contra el reloj de pared se incumple cada viernes por la noche, puntualmente, haya hecho alguien algo mal o no. Lo mismo pasa en los festivos, y de forma desigual cuando tu equipo abarca regiones que no comparten calendario.
Los incumplimientos falsos cuestan más de lo que parece. Inflan tus cifras y, la primera vez que un técnico se da cuenta de que el informe cuenta horas que nadie trabajó, deja de confiar en él; y eso significa que los incumplimientos reales también dejan de recibir atención. Configura el horario de soporte y los calendarios de festivos, por organización o de forma global, y el contador empezará a medir algo sobre lo que vale la pena actuar.
Fija tu umbral de escalado antes del incumplimiento. Una alerta al 80 % del tiempo asignado te da margen para reasignar. Una alerta en el momento del incumplimiento solo te da un análisis a posteriori.
Y esto no es solo una cifra interna. Si eres un MSP, los tiempos de respuesta son un compromiso comercial que varía según el cliente y el nivel de servicio; y cuando el tiempo de espera no se registra, llegas a una renovación o a una conversación de facturación sin pruebas de a quién pertenecía realmente ese tiempo. Si en lugar de una cartera de clientes gestionas un help desk interno, lo que está en juego parece distinto, pero la exposición es la misma: nadie te va a facturar por un SLA incumplido en el despliegue de parches, pero el responsable de seguridad que pregunta por qué los mismos tres endpoints se quedaron sin su ventana de parcheo dos veces este trimestre está teniendo exactamente la misma conversación, solo que sin importe asociado.
Por dónde empezar
Saca los tickets incumplidos de los últimos 90 días y clasifícalos en tres montones: se trabajaron demasiado despacio, se esperó a una persona y nunca debieron contarse. El segundo y el tercer montón suelen ser mayores que el primero, y ninguno de los dos se arregla pidiéndole a nadie que trabaje más rápido.
NinjaOne Ticketing controla los objetivos de respuesta y resolución por prioridad según el horario de soporte que hayas configurado, y muestra el estado del SLA y el tiempo restante como columnas del tablero que puedes filtrar y ordenar, con alertas al 80 % del tiempo asignado y en el momento del incumplimiento. Los pasos de aprobación se dirigen a un responsable, al propietario del dispositivo, a un rol o a una lista ad hoc, se resuelven por correo electrónico y registran la decisión en el propio ticket. Empieza tu prueba gratuita.
