Configuración de módulos
SLA
Compromisos de tiempo en tickets y tareas — mide, monitoriza y escala cuando los plazos amenazan con incumplirse.
Actualizado el 23 ene 2026
Configuration · Modules · 4.4
Un SLA (Service Level Agreement) es un compromiso de tiempo sobre un ticket o una tarea. El módulo SLA recoge lo que prometes, a qué casos aplica y registra si cumples el compromiso — con un cronómetro que solo corre durante el horario laboral.
Por qué esto importa al negocio
«Promesas no medibles»
Tiempo hasta primera respuesta y tiempo hasta resolución, explícitos — reportables por mes.
«Esperar al cliente cuenta»
Las condiciones pausan el cronómetro en estados concretos — medición justa.
«El reloj sigue corriendo fuera de horario»
El calendario se vincula al SLA → el cronómetro solo corre en horario laboral.
«Escalado demasiado tarde»
Secuencia de notificaciones según el porcentaje de SLA → recordatorio, manager, comité de seguimiento automáticamente.
Cuatro aspectos de cada SLA
| Aspecto | Qué define |
|---|---|
| Clase | Tiempo hasta primera respuesta o tiempo hasta resolución. Dos estrategias de medición distintas. |
| Criterios | Cuándo aplica el SLA: organización, clasificación, prioridad, tipo (ticket/tarea), plantilla, modalidad. |
| Tiempo objetivo | Plazo máximo permitido en horas/minutos + el calendario que define el horario laboral. |
| Condiciones | Cuándo arranca, se pausa o se detiene el cronómetro (p. ej., el estado «Esperando al cliente» pausa). |
La combinación clase + criterios es única — crear exactamente la misma configuración dos veces lanza un error.
Dos clases de SLA
Tiempo hasta primera respuesta
¿Con qué rapidez responde alguien al ticket? Se detiene en cuanto se da la primera respuesta.
Tiempo hasta resolución
¿Con qué rapidez se resuelve? Se detiene en el estado final.
Comportamiento ante cambios
Cuando algo cambia en un ticket (organización, prioridad, clasificación), Gfacility vuelve a comprobar si encaja algún SLA. Un nuevo SLA se activa, o uno existente se oculta si ya no encaja ningún criterio.
Cuando cambia la propia configuración del SLA, los SLA ya activos permanecen intactos — el antiguo sigue contando hasta que se cierre el ticket. Solo cuando cambie algo en el ticket Gfacility lo reevaluará.
¿Qué decisiones vas a tomar?
¿Qué bandas de prioridad?
Crítica · alta · normal · baja — cada una con su objetivo. Demasiadas bandas = complejidad innecesaria.
¿Horario laboral o 24/7?
¿Qué calendario vinculas? Un calendario por equipo de servicio suele bastar.
¿Qué estados pausan?
«Esperando al cliente», «En espera» — si no, las esperas externas siguen contando y rompes injustamente el SLA.
¿SLA en ticket o en tarea?
Ambos son posibles, pero elige según el caso de uso — si no, reportas dos veces.