Procedimiento de gestión y documentación ticket y autoticket
Procedimiento de Gestión y Documentación de Tickets de Soporte
Fecha: 11 de marzo de 2026
Elaboró: Coordinación de Soporte Técnico
1. Objetivo
2. Alcance
3. Definiciones
| Término | Definición |
|---|---|
| Autoticket | Ticket generado por un miembro del equipo de soporte (no por el usuario) |
| Diagnóstico | Descripción de las pruebas y observaciones técnicas realizadas |
| Acciones | Checklist detallado de actividades ejecutadas |
| Solución | Resolución final aplicada y validación del usuario |
| Cerrar | Acción de cerrar ticket al momento de solucionarlo |
4. Principio Fundamental
No se trata de "ahorrarnos pasos", sino de garantizar que la información esté completa.
5. Políticas Generales
5.1. Responsabilidad de la información
| Quién levanta el ticket | Responsabilidad de documentar |
|---|---|
| Usuario | Usuario documenta problema + Soporte documenta diagnóstico, acciones y solución |
| Soporte (autoticket) | Soporte documenta TODO: problema (desde la perspectiva del usuario) + diagnóstico + acciones + solución |
5.2. El ticket debe ser iniciado por el usuario (regla general)
5.3. En autoticket, el soporte documenta "el problema del usuario"
"El usuario reporta que [describir el problema con sus palabras]"
5.4. Un ticket por incidente, no por interacción
5.5. Estructura obligatoria del ticket
| Campo | Contenido mínimo |
|---|---|
| Diagnóstico | • Lo que el usuario reporta (si aplica) • Pruebas realizadas por soporte • Observaciones técnicas • Evidencias (fotos, pantallas) |
| Acciones | • Checklist detallado de actividades (configuraciones, cambios, validaciones) |
| Solución | • Resolución final aplicada y documentada en el campo "Solución" en SysAid • Validación del usuario |
5.6. Cierre formal de tickets
5.7. Priorización
6. Flujo de Gestión de Tickets
Escenario A: El usuario levanta el ticket
Escenario B: El soporte levanta autoticket
Diferencia clave: En el Escenario B, el soporte asume la documentación de la perspectiva del usuario además de su propia gestión.
7. Ejemplos Prácticos
✅ Ejemplo 1: Ticket levantado por USUARIO
Reporta: "Mi equipo no enciende"
| Campo | Contenido documentado por SOPORTE |
|---|---|
| Diagnóstico | Se recibió equipo. Se probó con cargador original - no enciende. Se probó con batería retirada - no enciende. Se probó con fuente de poder de otro equipo - no enciende. No hay luces LED, no hay sonido. Se sospecha falla en tarjeta madre. |
| Acciones | 1. Prueba con cargador original 2. Prueba con batería retirada 3. Prueba con fuente externa 4. Validación visual de componentes |
| Solución | Se confirma falla en tarjeta madre. Se programa cambio de equipo. Usuario informado y de acuerdo. |
✅ Ejemplo 2: AUTOTICKET levantado por soporte
el compañero documenta en autoticket:
| Campo | Contenido |
|---|---|
| Diagnóstico | Usuario reporta que: "No puedo acceder al portal, me marca error". Al revisar, se verifica conexión a internet funcionando. Se prueba con otro usuario y funciona. Se identifica que el usuario no tiene permisos para el portal. |
| Acciones | 1. Se asignan permisos en consola de administración 2. Se validó acceso con credenciales 3. Se probó navegación completa |
| Solución | Acceso restablecido correctamente. Usuario validó y confirmó funcionamiento. |
Observación: Nótese que José Carlos documentó lo que el usuario le reportó antes de su diagnóstico técnico.
❌ Ejemplo INCORRECTO (Brecha que debemos cerrar)
| Campo | Contenido INCORRECTO |
|---|---|
| Diagnóstico | Se revisó impresora. |
| Acciones | Se configuró. |
| Solución | Quedó funcionando. |
8. Excepciones y Casos Especiales
8.1. Días atípicos (migraciones, eventos)
Ejemplo: Migración Schiller (Iván, 09-11/03) — Se priorizó atención a usuarios y solicitudes de Dirección. La documentación se regularizó al finalizar.
8.2. Tickets preventivos
"Pendiente de atención".Ejemplo: Víctor con ticket de Jessica Jazmín (evento 13/03).
9. Lista de Verificación (Checklist)
10. Métricas y Seguimiento
| Métrica | Propósito | Frecuencia |
|---|---|---|
| % autotickets con "reporte del usuario" documentado | Calidad en autotickets | Semanal |
| % tickets con diagnóstico completo | Calidad de documentación | Semanal |
| Tiempo promedio de resolución | SLA real vs esperado | Semanal |
| % tickets cerrados | Retroalimentación de usuarios | Semanal |
11. Responsabilidades
| Rol | Responsabilidad |
|---|---|
| Soporte | Documentar tickets conforme a este procedimiento, incluyendo la perspectiva del usuario en autotickets |
| Soporte | Validar que el usuario cierre el ticket o cerrarlo de acuerdo al SLA |
| Gerente de TI | Supervisar calidad de documentación, especialmente en autotickets |
| Gerente de TI | Proveer retroalimentación y ajustes al procedimiento |
En TODOS los casos, debe documentarse la causal en el ticket.
📢 Mensaje Clave para el Equipo
"Cuando levantamos un autoticket, no nos saltamos pasos. Simplemente asumimos la responsabilidad de documentar lo que el usuario habría documentado. El ticket debe contar la historia completa: qué reportó el usuario, qué encontramos, qué hicimos y cómo lo resolvimos."
Modificado en 2026-03-11 20:44:39