It Service Desk Triage

Service desk triage

Purpose

Triage errors are expensive in a way that is invisible in the queue metrics: a misclassified ticket sits in the wrong team's backlog for days, a priority set from the reporter's tone rather than actual impact starves a genuine outage of attention, and forty tickets about one broken component get worked forty times. This skill sets the classification rules, the priority matrix, and the routing decision so the first assignment is usually the right one.

Prerequisites

• Inputs: the reported symptom in the user's words; who is affected and how many; when it started and whether it is ongoing; what changed recently for that user or that service; the service the symptom belongs to.
• Access: the ticket system, the service catalogue and its ownership map, the current major incident list, and the recent change log.

If the ticket does not say what the user was trying to do and what happened instead, ask before classifying. Triage on an ambiguous symptom is guesswork, and the resulting misroute costs more than the question.

Procedure

1. Classify the contact type. This decides everything downstream.

   Type	Definition	Goal
   Incident	Something that worked, or should work, is not working	Restore service, fastest safe path
   Service request	A pre-defined, catalogued thing the user is entitled to ask for (access, install, hardware, account)	Fulfil against the standard procedure
   Problem	The underlying cause behind one or more incidents	Eliminate recurrence — not the same queue, not the same clock
   Information	A question answerable from documentation	Answer and link the doc; repeated questions are a documentation defect

   The common error is working a problem as an incident: the symptom gets restored repeatedly and the cause is never owned. When the same incident recurs a third time, raise a problem record and link the incidents to it.

2. Check for an existing major incident before anything else. If the symptom matches an open major incident, link the ticket as an affected user and stop — do not investigate. Independent investigation of duplicate symptoms is the single biggest waste during an outage, and the linked count is what tells the incident team the real blast radius.

3. Set priority from impact and urgency, not from who is asking. Impact is how much of the organisation is affected. Urgency is how fast the damage grows.

   	Urgency: high (growing/deadline-bound)	Urgency: medium	Urgency: low
   Impact: organisation-wide or revenue-stopping	P1	P2	P3
   Impact: a department or a critical role	P2	P3	P3
   Impact: a single user, workaround exists	P3	P4	P4

   Overrides that legitimately raise priority: an external commitment with a fixed deadline, a regulatory or safety consequence, a security exposure, or a revenue-generating function fully blocked. Seniority of the reporter is not on that list. If someone insists, record the override, who authorised it, and the reason — priority inflation that leaves an audit trail self-corrects; silent inflation does not.

4. Apply a P1 test before declaring one. A P1 should satisfy: multiple users or a critical business function completely blocked, no workaround, and ongoing. If a workaround exists and is being used, it is a P2 with a workaround, and it should be recorded as such — mislabelled P1s destroy the credibility of the escalation path.

5. Route on the service, not on the symptom's technology. The user reports "the report won't open"; the technology looks like a browser problem; the service is the reporting platform and its owner is the right first assignee. Routing on guessed technology is the main cause of ticket bouncing.

6. Apply the reassignment rule: two bounces and it escalates. If a ticket is reassigned twice without work being done, it stops being a routing question and becomes an ownership question — escalate to the service desk lead to assign an owner. Owner means accountable for the outcome, including coordinating other teams; it does not mean solely responsible for the fix.

7. Correlate before you investigate. Three or more tickets with a similar symptom in a short window, or any spike after a recent change, is a candidate major incident. Check the change log for that service first: recent change is the highest-yield hypothesis in triage, and confirming or excluding it is usually a minute's work.

8. Write the ticket so the next person does not have to re-interview the user. Required before handoff: exact symptom and error text, who and how many are affected, first occurrence, whether it is reproducible and how, what has been ruled out, and the workaround if one exists. A ticket that only contains the user's original sentence has not been triaged.

9. Close with the resolution and the cause, separately. "Restarted the service" is the resolution; why it needed restarting is the cause, and if it is unknown, say unknown and count it — repeated unknown-cause closures on one service are how a problem record earns its existence.

Failure modes this skill exists to prevent

• Priority by volume of complaint. The loudest reporter gets P1 and a genuine multi-user outage waits. The matrix, applied consistently, is the defence.
• Duplicate investigation during an outage. Prevented by step 2, which must come before diagnosis, not after.
• Perpetual restart. The same incident is resolved by restart weekly and no problem record ever exists. Trigger the problem at the third occurrence.
• Silent SLA gaming. A ticket is closed and immediately reopened, or split, to reset the clock. Track reopen rate alongside resolution time; either metric alone can be gamed, the pair is much harder to.

Data handling

Classification: Internal, with ticket contents frequently containing personal data — a user's name, contact details, sometimes screenshots holding customer records. Attach evidence by reference where possible, redact customer identifiers and account numbers from screenshots before attaching, and never record credentials in a ticket. If a user has supplied a password in the ticket, treat it as exposed: it must be reset, and the ticket comment removed. If someone pastes customer personal data or financial positions into the conversation, flag it and do not proceed until it is removed.

Boundaries

• The request is a periodic review of who should hold access, not a single grant — it-access-review.
• The fix requires a controlled production window or board approval — it-change-management.
• A resolved major incident needs a written review — engineering-incident-postmortem.
• The ticket is a feature request for a product rather than an IT service — route to the product backlog; service desk triage will otherwise absorb work it cannot complete.

Hand-offs

• Receives from: it-change-management (post-change ticket spikes worth correlating).
• Routes to: it-access-review (records access grants that the next recertification will validate); it-change-management (fixes needing a change window); engineering-incident-postmortem (major incidents once resolved).