Ticket triage: deciding what gets answered first

Ticket triage is the few minutes spent deciding what each incoming request is, how urgent it is and who owns it — before anybody starts solving anything. Teams that skip it work in arrival order, which sounds fair and means a password reset can sit ahead of an outage. The decision is being made either way; triage only makes it deliberate.

What ticket triage decides

• What kind of request it is, from a short list rather than from the subject line.
• Priority, which should combine how badly it hurts with how many people it affects — not how insistently it was reported.
• Who owns it, by name, since an unassigned item in a shared queue is owned by nobody.
• Whether it is actually one request or three, because bundled tickets stall on their hardest part.
• Whether anything is missing, so the first reply asks for it instead of the fourth.
• Whether it is a duplicate of something already in progress, which is the cheapest saving available.

Why first-in-first-out fails

Because urgency is not evenly distributed and arrival order carries no information about it. Worse, pure queue order rewards whoever reports most often and punishes the person who waited politely — and the loudest requester is rarely the one with the most expensive problem. The other failure is subtler: without triage, the easy tickets get picked off by people wanting a quick win, and the difficult one ages at the bottom of the queue until it becomes a complaint.

Priority must mean something operationally or it is decoration. If high priority does not change who looks at it, in what order, or how quickly somebody is told, then every requester will learn to mark everything high — and they will be right to.

Running triage so it holds

1. Do it at fixed times rather than continuously, so triage does not become its own interruption.
2. Give it to one named person per day on rotation; a shared responsibility produces untriaged queues by mid-morning.
3. Keep priorities to three levels, because four means arguments and five means everything lands in the middle.
4. Write a one-line definition of each level and the response it earns, then apply it to the requester who disagrees.
5. Acknowledge everything at triage even when nothing can be done yet — most dissatisfaction is about silence rather than speed.
6. Review the oldest items weekly, since they are the ones triage has repeatedly deprioritised and they turn into escalations.

What to measure

Time to first response, and the age of the oldest open item. The first is what people actually experience, and the second is the one that catches the quiet failure — a queue can look healthy on averages while three requests have been sitting for a month. Volume and closure counts describe how busy the team was rather than how well the queue was run, which is why they dominate most support reports.

Ettex Board suits triage directly: a column for untriaged, a priority on the card and a named owner, so the queue state is visible rather than reconstructed. Where a request needs to leave the team entirely, the escalation matrix decides who it goes to rather than the triage decision.