El ciclo de vida de un ticket de incidencia tiene cinco fases: registro, asignación, seguimiento, resolución y cierre. En cada una, el ticket cambia de estado y queda constancia de quién lo gestiona, qué se ha hecho y cuánto tiempo ha pasado. Ese recorrido garantiza que ninguna petición se quede sin responsable, que se cumplan los plazos acordados y que la solución quede registrada para la próxima vez. A continuación se explica qué ocurre en cada fase, con un ejemplo práctico de principio a fin.
- ¿Qué es un ticket de incidencia?
- ¿Cuáles son las fases del ciclo de vida de un ticket?
- ¿Qué estados debe tener un ticket de soporte?
- ¿Cómo evitar que un ticket se quede sin responsable?
- ¿Qué aporta registrar todo el recorrido del ticket?
- ¿Qué diferencia a ServiceTonic en la gestión del ciclo de un ticket?
- Preguntas frecuentes
- Conclusión
¿Qué es un ticket de incidencia?
Un ticket de incidencia es el registro que se crea cuando un usuario comunica un problema que interrumpe o degrada un servicio: un equipo que no arranca, una aplicación que no responde, un acceso que falla. El ticket reúne en un solo lugar toda la información del caso (quién lo comunica, qué ocurre, a quién afecta, quién lo atiende y qué se ha hecho), desde que se abre hasta que se cierra. Es la unidad de trabajo de la gestión de incidencias.
¿Cuáles son las fases del ciclo de vida de un ticket?
| Fase | Qué ocurre | Estado del ticket | Quién actúa |
|---|---|---|---|
| 1. Registro | Se crea el ticket con sus datos y su prioridad | Abierto | Usuario o técnico de primer nivel |
| 2. Asignación | Se asigna a un grupo o técnico responsable | Asignado | Reglas automáticas o supervisor |
| 3. Seguimiento | Se diagnostica, se comunica con el usuario y, si hace falta, se escala | En curso/ Pendiente del usuario/ Escalado | Técnico asignado |
| 4. Resolución | Se aplica y se documenta la solución | Resuelto | Técnico asignado |
| 5. Cierre | Se confirma la solución y se cierra el ticket | Cerrado | Usuario o cierre |
1. Registro: ¿qué datos debe tener un ticket al abrirse?
El ciclo empieza cuando la incidencia entra por cualquier canal (portal de usuario, correo, teléfono, chat o WhatsApp) y se convierte en un ticket con un identificador único. En el registro conviene recoger:
- Usuario afectado y forma de contacto.
- Categoría y subcategoría: por ejemplo, Hardware > Portátil.
- Descripción del problema y, si es posible, una captura o un adjunto.
- Impacto y urgencia, que determinan la prioridad.
- Activo afectado, si el equipo está registrado en el inventario.
Con la prioridad ya calculada, el ticket queda sujeto a su SLA, que marca los plazos de primera respuesta y de resolución. En el tutorial prioridad basada en impacto y urgencia se explica cómo se configura este cálculo en ServiceTonic.
2. Asignación: ¿cómo llega el ticket al técnico adecuado?
La asignación consiste en decidir qué grupo o técnico se hace responsable del ticket. Puede ser manual, cuando un supervisor reparte el trabajo, o automática, mediante reglas que asignan según la categoría, la prioridad, la ubicación o la carga de cada técnico. La asignación automática reduce el tiempo que el ticket pasa sin responsable y evita que dependa de que alguien revise la cola.
Desde ese momento, el responsable es visible para todo el equipo y para el usuario, que sabe quién atiende su petición. Para decidir en qué orden atender los tickets asignados, conviene consultar la mejor forma de ordenar los tickets de soporte.
3. Seguimiento: ¿qué pasa mientras se trabaja en el ticket?
Durante el seguimiento, el técnico diagnostica el problema y registra cada acción en el historial del ticket. En esta fase el ticket puede pasar por varios estados:
- En curso: el técnico está trabajando en él.
- Pendiente del usuario: se necesita información o una prueba por su parte.
- Escalado: el primer nivel no puede resolverlo y pasa a un grupo especializado, con todo el historial.
El usuario recibe notificaciones cuando cambia el estado, y el sistema avisa si el ticket se acerca al vencimiento de su SLA. Gracias al historial, quien recibe un ticket escalado no tiene que volver a preguntar lo que ya se sabe.
4. Resolución: ¿qué hay que registrar al resolver un ticket?
Un ticket se marca como resuelto cuando se ha aplicado una solución que restablece el servicio. Además de la solución en sí, conviene registrar la causa (si se conoce) y los pasos seguidos. Si el problema puede repetirse, la solución debería pasar a la base de conocimiento: así, la próxima vez la resolverá antes el primer nivel o el propio usuario desde el portal.
5. Cierre: ¿cuándo se cierra definitivamente un ticket?
El ticket se cierra cuando el usuario confirma que el problema está resuelto o, si no responde, de forma automática tras un plazo definido. El cierre suele ir acompañado de una encuesta de satisfacción breve. Si el problema reaparece antes del cierre, el usuario puede reabrir el ticket y el ciclo continúa con todo el historial.
Ejemplo práctico: un ticket de principio a fin
Una empleada del departamento comercial no puede conectarse a la VPN desde casa y abre una petición desde el portal.
| Momento | Qué ocurre | Estado |
|---|---|---|
| 09:05 | Abre el ticket desde el portal: categoría «Accesos > VPN», impacto bajo (afecta a una persona) y urgencia alta (no puede trabajar). La prioridad resultante es media. | Abierto |
| 09:05 | Una regla asigna el ticket al grupo de Redes, porque la categoría es «Accesos > VPN». | Asignado |
| 09:20 | El técnico responde y le pide una captura del error. | Pendiente del usuario |
| 09:35 | La empleada envía la captura. El técnico detecta que su certificado ha caducado y lo renueva. | En curso |
| 09:50 | La empleada se conecta con normalidad. El técnico documenta la solución y la añade a la base de conocimiento. | Resuelto |
| 10:00 | La empleada confirma la solución y responde la encuesta de satisfacción. | Cerrado |
Todo el recorrido queda en el historial del ticket: quién intervino, cuánto tardó cada fase y cómo se resolvió.
¿Qué estados debe tener un ticket de soporte?
Un ticket de soporte debe tener, como mínimo, estos estados: abierto, asignado, en curso, pendiente del usuario, resuelto y cerrado. Muchas organizaciones añaden «escalado» o «pendiente de proveedor» para distinguir los tickets que esperan a un tercero. Lo importante es que cada estado indique con claridad quién tiene que actuar a continuación. Si un estado no responde a esa pregunta, probablemente sobra.
¿Cómo evitar que un ticket se quede sin responsable?
La forma más eficaz es la asignación automática: reglas que asignan cada ticket a un grupo en cuanto se registra, según su categoría o su origen. Además, conviene:
- Configurar un SLA de primera respuesta con aviso al supervisor si se supera.
- Tener una vista con los tickets sin asignar, revisada a diario.
- Evitar que los tickets se queden en un buzón de correo personal en lugar de en la cola común.
¿Qué aporta registrar todo el recorrido del ticket?
Además de resolver cada caso, el registro completo del ciclo genera información para decidir:
- Tiempos reales de respuesta y resolución por categoría, grupo o técnico.
- Incidencias recurrentes, que pueden indicar un problema de fondo.
- Carga de trabajo de cada equipo, para dimensionar recursos.
- Historial por activo: si el ticket está vinculado a un equipo, se ve cuántas veces ha fallado.
- Cumplimiento de los SLA acordados con usuarios o clientes.
¿Qué diferencia a ServiceTonic en la gestión del ciclo de un ticket?
ServiceTonic es un software de ticketing en el que estados, formularios, categorías y reglas de asignación y escalado se configuran sin programar, así que el ciclo del ticket se adapta a los procesos de cada organización y no al revés. Los tickets llegan desde la web, el correo, el teléfono, el chat o WhatsApp a una misma cola. Pueden vincularse a los activos de la CMDB y a los contratos de servicio, y el control de SLA avisa antes de que venza cada plazo. Todo ello, alineado con las buenas prácticas de ITIL.
Preguntas frecuentes
¿Cuál es la diferencia entre un ticket resuelto y uno cerrado?
Un ticket resuelto es aquel en el que el técnico ya ha aplicado una solución; uno cerrado es aquel en el que esa solución se ha confirmado y el caso se da por terminado. Entre ambos estados, el usuario puede comprobar la solución y reabrir el ticket si el problema continúa.
¿Quién decide la prioridad de un ticket?
Lo habitual es que se calcule automáticamente a partir del impacto (a cuántos usuarios o servicios afecta) y la urgencia (cuánto puede esperar). Así se evita que la prioridad dependa de quién comunica la incidencia o de cómo la describe.
¿Qué pasa si un ticket supera su SLA?
El sistema avisa al responsable y, según la configuración, escala el ticket a un supervisor o a otro grupo. El incumplimiento queda registrado y se refleja en los indicadores de cumplimiento de SLA.
¿Se puede reabrir un ticket cerrado?
Depende de cómo se configure. Lo habitual es permitir reabrirlo durante un plazo tras la resolución. Pasado ese plazo, si el problema reaparece, se abre un ticket nuevo vinculado al anterior.
¿Qué diferencia hay entre una incidencia y una petición de servicio?
Una incidencia es una interrupción o degradación de un servicio, como un equipo que no arranca. Una petición de servicio es una solicitud de algo nuevo, como un alta de usuario o un acceso. Ambas se gestionan con tickets, pero suelen tener flujos y SLA distintos.
Conclusión
Cada cambio de estado de un ticket responde a una pregunta: quién tiene que actuar ahora. Cuando el ciclo está bien definido, esa respuesta es siempre evidente, y los tickets no se pierden entre buzones, turnos o niveles de soporte. Por eso, antes de añadir estados o automatismos, conviene revisar si cada fase deja claro el siguiente responsable. Si es así, los plazos se cumplen casi por sí solos; si no, ningún SLA lo compensa.
¿Quiere ver el ciclo completo de un ticket en ServiceTonic? Solicite una demo y compruebe cómo se registran, asignan y resuelven las incidencias con sus propios procesos.