Diagrama de flujo del proceso de gestión de incidencias

Cómo funciona

1. Renombra los carriles con tus roles reales

   Sustituye usuario que reporta, mesa de servicio, gestor de incidencias y soporte nivel 2 / 3 por los roles que existen en tu organización. Los equipos pequeños suelen fundir el gestor de incidencias dentro del carril de la mesa de servicio; los que tienen un centro de monitorización añaden un carril propio encima del usuario.

2. Define tu matriz de prioridad

   Adjunta tus definiciones de impacto y urgencia al paso «Clasificar y asignar prioridad». Escribe qué significan P1 a P4 en número de usuarios afectados e impacto de negocio, para que la prioridad se deduzca y no se negocie ticket a ticket.

3. Fija el disparador de incidencia grave

   Decide qué convierte la decisión «¿Incidencia grave?» en un Sí: un servicio que afecta a los ingresos, un sistema crítico concreto, un número de clientes afectados. Indica quién puede declararla y qué ocurre inmediatamente después, por ejemplo abrir una sala de crisis y arrancar un ritmo fijo de actualizaciones.

4. Introduce tus objetivos de SLA y el escalado por incumplimiento

   Pon tus objetivos de respuesta y resolución en la decisión «¿Resolución dentro del objetivo de SLA?» e indica a quién se avisa en la rama de incumplimiento y con cuánta antelación respecto al plazo. Esa rama existe para avisar a tiempo, no para informar cuando ya no hay remedio.

5. Acuerda las reglas de cierre y de gestión de problemas

   Define qué cuenta como confirmado por el usuario, cuánto tiempo permanece un ticket en resuelto antes del cierre automático y qué criterios de «¿Causa raíz aún desconocida?» empujan una incidencia hacia gestión de problemas. Los síntomas recurrentes y toda incidencia grave son los disparadores habituales.

6. Recórrelo con cada carril y publica una versión con control de cambios

   Revisa el diagrama con las personas de cada carril y corrige los pasos que realmente ejecutan. Una vez acordado, publícalo como versión vigente con su aprobación, para que quien lo lea meses después sepa qué revisión estaba en vigor.

Preguntas frecuentes

¿Cuál es la diferencia entre gestión de incidencias y gestión de problemas?

La gestión de incidencias restablece el servicio. La gestión de problemas elimina la causa para que la incidencia deje de repetirse. Corren con relojes distintos: una incidencia se mide contra un SLA en minutos u horas, mientras que un registro de problema puede seguir abierto semanas de investigación. En este diagrama ambas se conectan en el cierre, donde «¿Causa raíz aún desconocida?» abre un registro de problema sin mantener la incidencia abierta. Mezclarlas es el fallo más común y se nota en tickets que siguen abiertos mucho después de que el usuario haya vuelto a trabajar.

¿Cuándo hay que declarar una incidencia grave?

Cuando el impacto justifica romper la cola normal: un servicio crítico para el negocio no está disponible, un grupo grande de usuarios está bloqueado, o hay exposición de seguridad, económica o reputacional. El disparador debe estar escrito antes de necesitarlo y ser lo bastante objetivo como para que un agente de primer nivel pueda aplicarlo a las dos de la madrugada. Una vez declarada, el proceso cambia de forma y no solo de velocidad: un gestor de incidencias con nombre asume la propiedad, se abre una sala de crisis y las actualizaciones a los interesados salen a hora fija haya o no novedades.

¿Qué pasa cuando una incidencia va a incumplir su SLA?

La rama de incumplimiento es un escalado jerárquico, no técnico. El trabajo continúa, pero se incorpora al gestor de incidencias para reajustar expectativas con el cliente, reasignar recursos si hace falta y dejar constancia de por qué se está incumpliendo el objetivo. El detalle importante es el momento: la rama debe dispararse antes de que venza el plazo, con un umbral del tipo 75 por ciento del tiempo restante, para que la conversación con el cliente sea previa al incumplimiento y no una disculpa posterior.

¿Quién cierra la incidencia y qué cuenta como resuelta?

Resolución y cierre son dos estados distintos. Un técnico marca la incidencia como resuelta cuando aplica la solución y el servicio vuelve. Solo se cierra cuando quien la reportó confirma que el servicio le funciona, y por eso este diagrama pasa por «Confirmar que el servicio funciona» en el carril del usuario y por la decisión «¿El usuario confirma la resolución?» antes del cierre. Si el usuario dice que el problema sigue, el ticket se reabre hacia el diagnóstico inicial en lugar de abrir uno nuevo. La mayoría de los equipos fija además una ventana de cierre automático, normalmente de tres a cinco días laborables sin respuesta.