Diagrama de flujo del proceso de soporte TI (help desk)
Diagrama del proceso de soporte TI: una única cola para incidencias y solicitudes de servicio, con registro, triaje, prioridad, resolución en primer nivel, escalado a nivel 2, entrega y cierre.
Cómo funciona
Renombra los carriles con vuestros roles reales
Sustituye Usuario, Servicio de soporte, Soporte nivel 2, Activos y compras, y Gestión de problemas por los equipos que tenéis. Las organizaciones pequeñas suelen fundir activos y compras dentro del carril de soporte, y la gestión de problemas puede ser una persona con nombre en lugar de un equipo. Mantén un carril por quien decide, no por individuo, para que el diagrama sobreviva a un cambio de puesto.
Escribe el criterio para distinguir incidencia de solicitud
La bifurcación «¿Incidencia o solicitud de servicio?» solo funciona si un agente puede aplicarla en segundos. Escribe la prueba junto a la decisión: ¿algo que debería funcionar está roto, o el usuario pide un trabajo estándar ya acordado? Enumera vuestros casos frontera reales, como un portátil lento frente a la petición de uno nuevo, e indica por dónde va cada uno.
Publica la matriz de prioridad
Adjunta vuestras definiciones de impacto y urgencia a «Asignar prioridad por impacto y urgencia», indicando qué significa cada nivel en número de usuarios afectados y consecuencia para el negocio. Publicar la matriz donde los usuarios puedan leerla es lo que convierte la prioridad en algo que se deduce en lugar de discutirse ticket a ticket.
Fija el límite del primer nivel y qué debe llevar un escalado
Define qué está autorizado y equipado a resolver el primer nivel, y qué tiene que contener un escalado para que el nivel 2 lo acepte: pasos ya probados, servicio afectado, evidencias y disponibilidad del usuario. Decide si además quieres un tope temporal que escale automáticamente un ticket sin avances, e indica quién es su dueño después del traspaso.
Decide qué necesita aprobación y qué está preaprobado
Marca como preaprobados los artículos de catálogo de bajo coste y bajo riesgo para que se salten por completo «¿El responsable aprueba la solicitud?», y reserva la puerta para el gasto, las licencias y todo lo que cambie a qué puede acceder una persona. Cuando la petición sea de acceso a un sistema, traspásala a vuestro proceso de solicitud de acceso en lugar de aprobarla aquí.
Acuerda cierre, reapertura y derivación a problema, y publica una sola versión
Indica qué cuenta como confirmación del usuario, cuánto espera un ticket resuelto antes de cerrarse automáticamente y con qué criterios «¿Problema recurrente o conocido?» abre un registro de problema. Después recorre el diagrama con cada carril, corrige los pasos que realmente ejecutan y publícalo como versión vigente con la aprobación registrada, para que todos lean la misma revisión.
Preguntas frecuentes
¿En qué se diferencia el proceso de soporte TI de la gestión de incidencias?
El proceso de soporte es el flujo operativo del propio servicio: todo contacto que llega, por cualquier canal, encaminado al tipo de tratamiento que le corresponde. La gestión de incidencias es solo una de sus ramas y se ocupa únicamente de las interrupciones no planificadas de un servicio. ITIL 4 trata service desk, gestión de incidencias, gestión de solicitudes y gestión de problemas como prácticas separadas justo por eso, aunque un equipo pequeño las ejecute todas desde una misma cola y con las mismas personas. Este diagrama es la vista de servicio que muestra cómo esas ramas comparten entrada y cierre, y deja el detalle profundo —incidencia grave, escalado por incumplimiento de SLA— al proceso de gestión de incidencias.
¿Cuál es la diferencia entre una incidencia y una solicitud de servicio?
Una incidencia es algo que debería funcionar y no funciona: un inicio de sesión fallido, una impresora caída, una aplicación que da errores. Una solicitud de servicio es un trabajo estándar ya acordado, sin avería de por medio: un software nuevo, una licencia, un equipo de sustitución, un buzón para alguien que se incorpora. La distinción importa porque cambia casi todo lo que viene después. Las incidencias reciben una prioridad por impacto y urgencia y se miden por el restablecimiento; las solicitudes reciben una aprobación y una vía de entrega y se miden por el plazo. Mezclarlas hace que las peticiones rutinarias corran con reloj de caída de servicio, o que las caídas reales esperen detrás de un pedido de portátiles.
¿Cuándo hay que escalar un ticket al nivel 2?
Cuando el trabajo supera el límite de conocimientos, herramientas o permisos del primer nivel: eso es un escalado funcional. Es distinto del escalado jerárquico, en el que se involucra a un responsable porque el impacto o el retraso se han convertido en un problema de negocio y no técnico. Muchos servicios añaden un tope temporal para que un ticket sin avances se escale automáticamente, algo útil como red de seguridad pero mala regla principal por sí sola. Sea cual sea el detonante, el traspaso tiene que llevar lo que ya se ha probado, o el nivel 2 dedicará su primera hora a repetir el trabajo del primero.
¿Se puede cerrar un ticket antes de que el usuario confirme la solución?
Resuelto y cerrado son dos estados distintos, y este diagrama los mantiene separados. El agente marca el ticket como resuelto cuando aplica la solución; se cierra solo cuando «¿El usuario confirma la solución?» devuelve un sí. Si el usuario dice que el problema sigue, el ticket se reabre hacia el primer nivel en lugar de abrirse uno nuevo, lo que mantiene juntos el historial y el reloj original. Como hay usuarios que nunca contestan, la mayoría de los servicios fijan un cierre automático de unos días laborables con un recordatorio previo, y publican ese plazo en la descripción del servicio para que el cierre no sorprenda a nadie.
¿Cómo encajan en el proceso las solicitudes que implican una compra?
Siguen la rama de entrega: aprobación cuando el catálogo la exige y después «¿Hay stock disponible?», que entrega desde el stock existente o emite una orden de compra antes de la entrega. El paso que la gente se salta es actualizar el inventario de activos, y por eso aquí vive en el mismo nodo que la entrega. Si el inventario no se actualiza en el momento de entregar, el recuento de licencias y la planificación de renovación de equipos se desactualizan en pocos meses. Para compras grandes o fuera de catálogo, el servicio plantea la necesidad y toma el relevo el proceso general de orden de compra, con su propio abastecimiento y su conciliación de facturas.