Cómo automatizar los recordatorios de SLA antes de que se conviertan en incumplimientos
Los recordatorios automatizados de SLA deben mostrar un ticket mientras aún haya tiempo para actuar y, después, hacer que un ticket vencido sea inconfundible. La configuración adecuada depende de la mesa de ayuda. Algunas plataformas ofrecen alertas nativas de próximo vencimiento e incumplimiento, mientras que un flujo de trabajo personalizado puede necesitar comprobaciones programadas y pasos de escalamiento explícitos.
Empieza por el reloj, no por la notificación:
- Define objetivos independientes para la primera respuesta y la resolución.
- Decide si los objetivos utilizan tiempo natural u horas laborables.
- Elige qué estados del ticket pausan el reloj de resolución.
Consejo profesional: Prueba cada estado del SLA con tickets de muestra antes de depender de las alertas activas. Incluye casos próximos al vencimiento, incumplidos, pausados, reasignados y ya completados.
Puntos clave
Los recordatorios fiables comienzan con plazos precisos. El momento de las alertas, los destinatarios y los procedimientos de escalamiento vienen después de que la propia política sea correcta.
| Punto | Detalles |
|---|---|
| Define ambos relojes | Realiza un seguimiento independiente de la primera respuesta y la resolución porque finalizan con eventos diferentes. |
| Respeta el tiempo laborable | Utiliza un calendario laboral cuando las noches y los fines de semana no deban consumir el objetivo. |
| Configura los estados de pausa | Pausa el objetivo de resolución mientras el ticket espera al cliente o a otra parte externa. |
| Elige cuidadosamente a los destinatarios | Asegúrate de que las alertas de próximo vencimiento e incumplimiento lleguen a alguien que pueda actuar sobre el ticket. |
| Prueba antes del lanzamiento | Verifica los plazos, el comportamiento de pausa y la entrega de notificaciones con tickets controlados. |
| Utiliza primero las funciones nativas de SLA | Una mesa de ayuda con políticas, calendarios laborales, alertas, filtros e informes integrados evita un flujo de trabajo de sondeo independiente. |
Documentación autorizada y guías prácticas que puedes consultar a continuación
Para ver un ejemplo específico de una plataforma, consulta la documentación de seguimiento automatizado de Jira. Describe tanto las reglas programadas como un enfoque basado en umbrales de SLA, incluida la recomendación de probar primero con un ámbito de consulta reducido antes de ampliarlo.
Tabla de contenidos
- Cómo crear una automatización de recordatorios de SLA paso a paso
- Cómo elegir umbrales que no provoquen fatiga de alertas
- Qué deben decir las alertas de SLA y adónde deben enviarse
- Cómo mantener precisos los temporizadores de SLA con estados de pausa
- Pruebas y ajustes antes de confiar en la automatización
- Cómo gestiona Deskhero estos procesos automatizados
- Qué debes supervisar una vez activadas las alertas
- Cómo gestionar SLA superpuestos sin colisiones de alertas
- Cómo estar preparado para auditorías cuando los SLA funcionan automáticamente
- Cómo redactar mensajes de SLA para usuarios, responsables y clientes
- Cómo conectar la automatización de SLA con las herramientas que ya utilizas
- Perspectiva editorial: la alerta no es lo importante, sino la acción
- Pon en marcha tus recordatorios de SLA sin un proyecto de migración
- Fuentes
- Preguntas frecuentes
Cómo crear una automatización de recordatorios de SLA paso a paso
Anota exactamente qué mide cada SLA antes de configurar una alerta. Un objetivo de primera respuesta y un objetivo de resolución son relojes diferentes. Decide qué evento del ticket inicia cada reloj, qué evento lo completa y si el plazo sigue el tiempo natural o un calendario laboral.
Después, configura la ruta del recordatorio.
- Define la política. Asigna grupos y prioridades a objetivos de primera respuesta y resolución. Incluye una política general para los tickets que no coincidan con una regla más específica.
- Configura el calendario laboral. Añade el horario de operación y la zona horaria aplicables al objetivo. Si el compromiso funciona de forma continua, utiliza tiempo natural.
- Configura el comportamiento de pausa. Selecciona los estados que detienen el reloj de resolución mientras el equipo espera información. Confirma si el reloj de primera respuesta puede pausarse, ya que muchos sistemas lo tratan de forma diferente.
- Activa las notificaciones. Decide quién recibe los estados de próximo vencimiento e incumplimiento y qué canales compatibles utilizará la mesa de ayuda.
- Añade una respuesta operativa. Documenta qué debe hacer el destinatario, como responder, cambiar la prioridad, reasignar el ticket o involucrar a un responsable. La notificación y la acción correctiva no tienen que ser la misma regla técnica.
Si la mesa de ayuda no dispone de umbrales de SLA nativos, un flujo de trabajo programado puede inspeccionar los tickets abiertos y comparar sus plazos con la hora actual. LOW/CODE documenta un ejemplo de sondeo cada 15 minutos, pero el intervalo adecuado depende del objetivo más corto, los límites de la API, el horario laboral y el retraso que el equipo pueda tolerar. Guarda el estado de la alerta para que las ejecuciones posteriores no vuelvan a enviar la misma notificación.
Cómo elegir umbrales que no provoquen fatiga de alertas
Una advertencia útil deja tiempo suficiente para que el destinatario responda. Un umbral porcentual puede funcionar en un sistema personalizado, pero una ventana de advertencia fija suele ser más fácil de entender entre políticas con distintas duraciones.
- A tiempo con margen: Mantén el ticket visible en las vistas normales de la cola sin enviar una advertencia.
- Próximo al vencimiento: Notifica al Usuario o grupo responsable mientras aún sea posible cumplir el objetivo.
- Incumplido: Marca el ticket como vencido y sigue el proceso de escalamiento documentado del equipo.
No copies un umbral universal del 80 % sin comprobar los objetivos subyacentes. En un objetivo de una hora deja 12 minutos, mientras que en uno de tres días deja más de medio día. Mide cuánto tiempo de acción necesita realmente el equipo.
Los recordatorios repetidos generan ruido rápidamente. Las alertas nativas de la mesa de ayuda deben notificar cuando se produce una transición de estado, no en cada actualización de pantalla. Un flujo de trabajo de sondeo personalizado debe registrar que envió el aviso de próximo vencimiento o incumplimiento y restablecer ese estado únicamente cuando la política se reinicie de verdad.
Qué deben decir las alertas de SLA y adónde deben enviarse
Una alerta debe identificar el ticket, mostrar el plazo y dejar clara la respuesta esperada. Evita añadir datos del cliente que el destinatario no necesite.
- ID y enlace del ticket para que el destinatario pueda abrir la conversación correcta.
- Tipo de objetivo, como primera respuesta o resolución.
- Plazo o duración del vencimiento en una zona horaria inequívoca.
- Estado actual, prioridad, grupo y asignado cuando esos campos afecten a la responsabilidad.
- Un siguiente paso, como responder, reasignar el ticket o pedir a un responsable que lo revise.
Utiliza los canales que el equipo de soporte ya supervisa. Las notificaciones dentro de la aplicación y por correo electrónico suelen ser suficientes cuando llegan de forma fiable al asignado o al grupo responsable. Si se necesita un sistema independiente de paging o mensajería, confirma que la mesa de ayuda admite la integración antes de diseñar el proceso en torno a ella.
Consejo profesional: Muestra un plazo o una cuenta atrás precisos. Una hora concreta es más fácil de priorizar que una advertencia vaga.
Cómo mantener precisos los temporizadores de SLA con estados de pausa
Un recordatorio solo es tan fiable como su reloj. Los objetivos de resolución suelen pausarse mientras un ticket espera al cliente, pero los estados exactos deben coincidir con el flujo de trabajo real del equipo.
- Selecciona estados de pausa explícitos y documenta por qué cada uno detiene el reloj.
- Reanuda el reloj cuando el ticket abandone un estado de pausa.
- Prueba tickets que entren y salgan de un estado de pausa más de una vez.
- Confirma si los objetivos de primera respuesta y resolución siguen las mismas reglas de pausa.
Los calendarios laborales resuelven un problema diferente. Excluyen las horas de cierre del propio objetivo, mientras que los estados de pausa excluyen tiempo según el estado del ticket. Configura y prueba ambos. Un fin de semana no debe consumir un objetivo basado en horas laborables, y un ticket de un día laborable que espera al cliente debe permanecer pausado aunque el equipo esté disponible.
Pruebas y ajustes antes de confiar en la automatización
Utiliza tickets controlados para probar todo el ciclo de vida. Los datos históricos pueden ayudar a identificar objetivos realistas, pero una prueba con estados activos es mejor para verificar la entrega de notificaciones y los cambios de plazo.
- Cubre todas las políticas. Crea un ticket de prueba para cada combinación de grupo y prioridad que pueda seleccionar una política de SLA diferente.
- Utiliza objetivos temporales cortos. Confirma los estados de próximo vencimiento e incumplimiento sin esperar horas o días y, después, restaura los valores reales.
- Prueba los estados de pausa. Pausa y reanuda el reloj de resolución y verifica que el plazo cambie según lo esperado.
- Comprueba los destinatarios. Prueba un ticket asignado y otro sin asignar para que las personas correctas reciban cada notificación.
- Inspecciona el registro. Confirma que el ticket muestre qué política se aplicó y cuándo se cumplió o no cada reloj.
Después del lanzamiento, revisa las advertencias falsas y las transferencias omitidas. Si las alertas son precisas pero aun así se ignoran, el problema puede estar en la responsabilidad o la dotación de personal, no en el momento del umbral.
Cómo gestiona Deskhero estos procesos automatizados
Deskhero cuenta con políticas de SLA específicas. Estas son independientes de sus reglas generales de automatización, que no están programadas ni se basan en el tiempo.
- Los propietarios y administradores pueden ordenar políticas de SLA que coincidan con los grupos y las prioridades de los tickets. La primera política coincidente establece los objetivos de primera respuesta y resolución.
- Cada política puede utilizar un calendario laboral semanal con nombre y su propia zona horaria, o contabilizar el tiempo natural.
- El reloj de resolución se pausa en los estados seleccionados en el espacio de trabajo. El reloj de primera respuesta no se pausa.
- Deskhero marca un ticket como en riesgo durante los 60 minutos finales antes de su próximo plazo y lo marca como incumplido una vez transcurrido el plazo.
- Se ejecuta una comprobación en segundo plano cada cinco minutos y se envían notificaciones dentro de la aplicación, además de un resumen por correo electrónico, al asignado o a los miembros del grupo cuando el ticket no está asignado. Los usuarios pueden controlar los canales de notificación de SLA por grupo.
La lista de tickets incluye una columna de SLA y filtros de SLA, el panel destaca los tickets en riesgo e incumplidos y la cronología del ticket registra los eventos de política y del reloj. Estadísticas proporciona vistas de cumplimiento de SLA una vez activo el flujo de trabajo.
Qué debes supervisar una vez activadas las alertas
La primera pregunta es si los recordatorios están evitando incumplimientos. Compara los tickets en riesgo con el número que posteriormente no cumple el objetivo y, después, investiga los casos que las advertencias no lograron recuperar.
Realiza un seguimiento independiente del cumplimiento de la primera respuesta y de la resolución. También revisa el número de tickets cuyo vencimiento se producirá dentro de la ventana de advertencia, el número de tickets ya incumplidos y qué políticas o combinaciones de grupo y prioridad generan más incumplimientos.
Relaciona los porcentajes con el contexto operativo. Un porcentaje general sólido puede ocultar una cola que incumple repetidamente. Una caída repentina puede reflejar un cambio en el calendario laboral, una prioridad recién añadida o una carencia de responsables, en lugar de un trabajo más lento.
Cómo gestionar SLA superpuestos sin colisiones de alertas
Un ticket puede tener un objetivo de primera respuesta y otro de resolución. Trátalos como relojes separados porque una respuesta solo completa el primero. El objetivo de resolución continúa hasta que el ticket alcanza el evento que lo satisface.
La interfaz del ticket debe mostrar cuál es el próximo plazo pendiente y conservar los detalles de ambos objetivos. Los filtros y los informes también deben distinguir entre primera respuesta y resolución para que una métrica saludable no oculte problemas en la otra.
Cuando los clientes tienen compromisos diferentes, utiliza políticas independientes que coincidan con campos estables del ticket, como el grupo y la prioridad. Ordena las políticas específicas antes de la política general y, después, prueba un ticket con cada combinación relevante. Evita inventar niveles de contrato ocultos que los Usuarios no puedan ver ni verificar en el ticket.
Cómo estar preparado para auditorías cuando los SLA funcionan automáticamente
Conserva un registro de la política aplicada, los plazos calculados y el momento en que se cumplió o no cada reloj. Si un cambio de grupo, prioridad o calendario provoca el recálculo de un plazo, ese cambio también debe poder rastrearse.
Documenta los cambios de política fuera de la bandeja de entrada de notificaciones. Registra quién aprobó el cambio, cuándo entró en vigor y si se aplica a los tickets existentes. Esto facilita responder a las preguntas posteriores de los clientes y evita cambios silenciosos en el significado de un informe de SLA.
Para las revisiones contractuales, confirma el comportamiento de la plataforma en lugar de asumir que cada evento visible es un registro de auditoría. La cronología de tickets de Deskhero registra la aplicación de la política de SLA y los resultados de los relojes, mientras que su área Estadísticas informa sobre el cumplimiento. Las organizaciones con requisitos formales de conservación deben verificar que estos registros satisfagan sus propias obligaciones.
Cómo redactar mensajes de SLA para usuarios, responsables y clientes
Las alertas internas y las actualizaciones para clientes tienen objetivos diferentes. Mantén cada una centrada en lo que su lector puede hacer a continuación.
Las alertas dirigidas a Usuarios deben comenzar con el enlace del ticket, el tipo de objetivo, el plazo y la acción inmediata. Evita un párrafo de contexto sobre la política cuando el Usuario necesita trabajar en el ticket.
Las revisiones dirigidas a responsables deben mostrar patrones en un grupo, una prioridad o una política. Un ticket incumplido requiere una acción, mientras que los incumplimientos repetidos requieren una decisión sobre personal o procesos.
La comunicación dirigida al cliente debe ser precisa y específica. Si el equipo prevé un retraso, una actualización revisada por una persona puede establecer un momento realista para el próximo contacto. No expongas etiquetas de alertas internas ni prometas un tiempo de resolución que el equipo no pueda cumplir.
Cómo conectar la automatización de SLA con las herramientas que ya utilizas
Empieza con las funciones nativas de SLA cuando cubran las políticas, los calendarios, los estados de pausa, las alertas, los filtros y los informes necesarios. Los plazos nativos suelen mantenerse alineados con los cambios de los tickets de forma más fiable que una hoja de cálculo paralela.
Cuando la compatibilidad nativa sea limitada, los equipos han utilizado plugins de la comunidad y soluciones alternativas documentadas en foros. Revisa el estado de mantenimiento y la compatibilidad de versiones antes de depender de este enfoque.
Un flujo de trabajo independiente puede ser adecuado cuando varios sistemas deben alimentar un único canal de escalamiento. Define primero la fuente de verdad. Los cálculos duplicados de SLA en una mesa de ayuda y una capa de integración pueden desviarse, especialmente con las zonas horarias, las horas laborables, los estados de pausa y las reasignaciones.
Perspectiva editorial: la alerta no es lo importante, sino la acción
Una notificación de próximo vencimiento solo es útil cuando la responsabilidad está clara. El destinatario necesita permiso, contexto y tiempo para hacer avanzar el ticket.
La precisión del temporizador es lo primero. Un calendario laboral o una configuración de pausa incorrectos producen alertas seguras de sí mismas, pero engañosas. Corrige el cálculo del plazo antes de ajustar el texto del mensaje o añadir canales.
Construye el proceso en este orden: objetivos de la política, calendarios laborales, comportamiento de pausa, destinatarios de las notificaciones, respuesta operativa e informes. Esta secuencia mantiene el recordatorio vinculado a un plazo que todos entienden.
Pon en marcha tus recordatorios de SLA sin un proyecto de migración
Deskhero se conecta con Gmail o Microsoft 365 mediante sincronización bidireccional, de modo que los equipos pueden conservar su dirección de soporte actual mientras añaden una gestión compartida de tickets y políticas de SLA.
Configura objetivos de primera respuesta y resolución por grupo y prioridad, añade un calendario laboral semanal cuando sea necesario y elige qué estados pausan la resolución. Deskhero muestra entonces el próximo plazo, destaca los tickets cuyo vencimiento se producirá en una hora, notifica a los Usuarios responsables y registra los resultados del SLA.
La prueba gratuita de 30 días no requiere tarjeta de crédito. Conecta un buzón, configura un conjunto reducido de políticas y prueba todo el ciclo de vida del SLA antes de ampliar la configuración a más grupos.
Fuentes
- Automatiza seguimientos en Jira Service Management Cloud | Atlassian Support
- Crea alertas de incumplimiento de SLA sin programar | LOW/CODE
Preguntas frecuentes
¿Cuál es la diferencia entre un SLA, un SLO y un SLI?
Un SLA es un compromiso de servicio entre partes. Un SLO es un objetivo de rendimiento de un servicio, que suele utilizarse internamente para mantenerse dentro de ese compromiso. Un SLI es el valor medido que se utiliza para evaluar el objetivo.
¿Qué se considera una alerta de incumplimiento de SLA?
Una alerta de incumplimiento indica que ha pasado un plazo pendiente de primera respuesta o resolución. Una alerta de próximo vencimiento es diferente porque el equipo aún tiene tiempo para cumplir el objetivo.
¿Qué significa un SLA de 4 horas?
Significa que la acción indicada por la política, como la primera respuesta o la resolución, debe realizarse en un plazo de cuatro horas según el cálculo de esa política. El reloj puede utilizar tiempo natural o un calendario laboral.
¿En qué se diferencia un SLA de un KPI?
Un SLA establece un compromiso de servicio. Un KPI mide el rendimiento y puede utilizarse para supervisar muchos objetivos que no son plazos contractuales.
¿Puede Deskhero automatizar recordatorios de SLA sin código personalizado?
Sí. Deskhero cuenta con políticas de SLA integradas, una ventana fija de advertencia de próximo vencimiento, detección de incumplimientos, notificaciones dentro de la aplicación y por correo electrónico, filtros de tickets, vistas del panel e informes de SLA. Estas funciones son independientes de sus reglas generales de automatización.