Jira Service Management: a well-made ticket, from start to finish

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.

Jira Service Management · SD-4821

ResumenOutlook no abre tras la actualización de esta mañana

Tipo de solicitudIncidencia

PrioridadMedia (impacto: 1 usuario · urgencia: alta, no puede trabajar)

ComponenteCorreo y Outlook

Elemento afectadoLAPTOP-7F2K9Q

Asignado aIñigo

SLA · Tiempo de primera respuesta00:42 restantes

Responder al cliente

Comentario interno

Transición: En curso

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.

Jira Service Management · SD-4821 · comentario interno

Probado: outlook.office.com abre bien → el buzón está OK, es el cliente de Outlook.

Probado: Outlook en modo seguro (outlook.exe /safe) abre → es un complemento o el perfil.

Deshabilitado el complemento de la app de firmas → Outlook abre con normalidad.

Siguiente: pedir al proveedor de la app de firmas la versión compatible con la build 2410. Ticket con ellos: PRV-118.

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

Jira · JQL

# 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.

What you'll get

Tickets anyone on the team can pick up without calling you, response times inside the SLA, and a queue that tells the truth at the end of the day. It sounds small; it is what sets a good support technician apart in the first week.

Before you start

Your service project in Jira (say SD) and the request types it has: incident, service request, question, change.
Your company's priority matrix: impact (how many users or which service) by urgency (whether they can work or not). If it is not written down, ask for it.
The project's SLAs (first response and resolution time per priority). They show on every ticket, in the right-hand panel.

1. On arrival: classify in two minutes

Before touching anything, set the ticket up properly. That is what lets reports and everyone else's queues work.

Jira Service Management · SD-4821

SummaryOutlook won't open after this morning's update

Request typeIncident

PriorityMedium (impact: 1 user · urgency: high, cannot work)

ComponentEmail and Outlook

Affected itemLAPTOP-7F2K9Q

AssigneeIñigo

SLA · Time to first response00:42 remaining

Reply to customer

Internal comment

Transition: In progress

An incident is something that worked and has stopped working. A service request is something new (an access, a licence, a device). Don't mix them: they have different SLAs and workflows.
The summary states the symptom and the context in one line. "Outlook" is useless; "Outlook won't open after this morning's update" works.
Priority comes from the matrix, not from how nervous the user is. A user unable to work is high urgency; a director who wants a wallpaper is low.

2. The first response

The first-response SLA is met with a comment to the customer, not with an internal comment or a status change. Keep it short, concrete and with a question if information is missing:

I've seen the ticket. To locate the fault I need to know: does any error message appear when opening Outlook? Can you get into your email from the browser (outlook.office.com)? Meanwhile I'm checking from here.

That stops the first-response clock and the user knows someone is on it.

3. Working the ticket: write for the next person

Every step you take goes into an internal comment with what you tried and the result. Not for your manager: for the colleague who picks it up at 17:00 when you leave.

Jira Service Management · SD-4821 · internal comment

Tried: outlook.office.com opens fine → the mailbox is OK, it's the Outlook client.

Tried: Outlook in safe mode (outlook.exe /safe) opens → it's an add-in or the profile.

Disabled the signature app's add-in → Outlook opens normally.

Next: ask the signature app vendor for the version compatible with build 2410. Ticket with them: PRV-118.

A comment like that has four things: what you tried, what happened, what you rule out and what the next step is. If the ticket goes to Waiting for customer or Waiting for vendor, the SLA clock pauses (if the workflow is set up that way; check your project) and it is clear who it depends on.

4. Escalating

You escalate when the next step needs permissions or knowledge you don't have, not when it has taken a long time. When escalating, the ticket moves to the right group (Assignee set to the team, or a linked ticket in their project) with a summary of what is already ruled out. A ticket escalated with "doesn't work, have a look" comes back in ten minutes.

5. Closing

The solution goes in a comment to the customer, in user language: "It was an Outlook add-in incompatible with the latest update. I've disabled it and asked the vendor for the new version. If it happens again, reply to this email".
The Resolution field is filled in honestly: *Done*, *Workaround* (if you patched it and a problem ticket stays open), *Cannot reproduce*, *Duplicate* (linked to the original).
If the user does not answer "can you check?", the workflow closes it on its own after a few days. Don't close it by hand in minute one: whoever reopens a force-closed ticket never comes back happy.

6. The everyday JQL searches