Jira Service Management: un ticket bien hecho, de principio a fin

Qué vas a conseguir

Tickets que cualquiera del equipo puede retomar sin llamarte, tiempos de respuesta dentro del SLA, y una cola que al final del día dice la verdad. Suena a poco; es lo que diferencia a un técnico de soporte bueno en la primera semana.

Antes de empezar

• Tu proyecto de servicio en Jira (por ejemplo SD) y los tipos de solicitud que tiene: incidencia, petición de servicio, pregunta, cambio.
• La matriz de prioridad de tu empresa: impacto (cuántos usuarios o qué servicio) por urgencia (si pueden trabajar o no). Si no existe por escrito, pídela.
• Los SLA del proyecto (tiempo de primera respuesta y de resolución por prioridad). Se ven en cada ticket, en el panel de la derecha.

1. Al recibirlo: clasifica en dos minutos

Antes de tocar nada, deja el ticket bien puesto. Es lo que permite que los informes y las colas de los demás funcionen.

• Incidencia es algo que funcionaba y ha dejado de funcionar. Petición de servicio es algo nuevo (un acceso, una licencia, un equipo). No las mezcles: tienen SLA y flujos distintos.
• El resumen dice el síntoma y el contexto en una línea. "Outlook" no sirve; "Outlook no abre tras la actualización de esta mañana" sí.
• La prioridad sale de la matriz, no de lo nervioso que esté el usuario. Un usuario sin trabajar es urgencia alta; un director que quiere un fondo de pantalla, baja.

2. La primera respuesta

El SLA de primera respuesta se cumple con un comentario al cliente, no con un comentario interno ni con cambiar el estado. Que sea corto, concreto y con una pregunta si falta información:

He visto el ticket. Para localizar el fallo necesito que me digas: ¿sale algún mensaje de error al abrir Outlook? ¿Puedes entrar en el correo desde el navegador (outlook.office.com)? Mientras, lo estoy revisando desde aquí.

Con eso paras el reloj de primera respuesta y el usuario sabe que alguien está con ello.

3. Trabajar el ticket: escribe para el siguiente

Cada paso que das va en un comentario interno con lo que probaste y el resultado. No para tu jefe: para el compañero que lo retoma a las 17:00 cuando tú te vas.

Un comentario así tiene cuatro cosas: qué probaste, qué pasó, qué descartas y cuál es el siguiente paso. Si el ticket queda En espera del cliente o En espera del proveedor, el reloj del SLA se para (si el flujo está configurado así; compruébalo en tu proyecto) y queda claro de quién depende.

4. Escalar

Escalas cuando el siguiente paso necesita permisos o conocimiento que no tienes, no cuando llevas mucho tiempo. Al escalar, el ticket pasa al grupo correspondiente (Asignado a el equipo, o un ticket enlazado en su proyecto) con un resumen de lo que ya está descartado. Un ticket escalado con "no funciona, mirad" vuelve a los diez minutos.

5. Cerrar

• La solución va en un comentario al cliente, en lenguaje de usuario: "Era un complemento de Outlook incompatible con la última actualización. Lo he desactivado y he pedido al proveedor la versión nueva. Si vuelve a pasar, responde a este correo".
• El campo Resolución se rellena con honestidad: Resuelto, Solución alternativa (si lo has parcheado y queda un ticket de problema abierto), No se puede reproducir, Duplicado (enlazado al original).
• Si el usuario no contesta a "¿lo puedes comprobar?", el flujo lo cierra solo a los pocos días. No lo cierres a mano en el minuto uno: el que reabre un ticket cerrado a la fuerza nunca vuelve contento.

6. Las búsquedas JQL de cada día

# Mi cola, lo más urgente primero›project = SD AND assignee = currentUser() AND statusCategory != Done ORDER BY priority DESC, created ASC# Tickets sin asignar que van a incumplir el SLA en la próxima hora›project = SD AND assignee IS EMPTY AND "Time to first response" < remaining("1h")# Todo lo que ha abierto este usuario (para ver si es recurrente)›project = SD AND reporter = "laura.prado@contoso.com" ORDER BY created DESC# Lo que lleva más de 5 días esperando al proveedor›project = SD AND status = "Waiting for vendor" AND updated < -5d

Guarda las dos primeras como filtros y ponlas en tu tablero: la cola deja de ser una lista y pasa a ser un plan.

Siguientes pasos

• Cuando veas el mismo ticket tres veces, abre un problema enlazado: ahí vive la causa raíz, y los incidentes solo se enlazan.
• Aprende a escribir un artículo de la base de conocimiento desde el ticket: Jira lo sugiere al usuario antes de que abra el siguiente.
• En el Nivel 2 verás Confluence y, en el 4, cómo se administran los flujos, los SLA y las automatizaciones del proyecto.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.