# It Service Desk Triage > Triages inbound service desk contacts: separates incident from request from problem, sets priority from impact and urgency, routes to the right queue first time, and decides when to escalate or link tickets to a major incident. Use when a ticket arrives and needs classification, when a queue has backed up and needs prioritising, when reassignments keep bouncing a ticket between teams, or when several tickets look like one underlying fault. Trigger on 'triage this ticket', 'what priority is this', 'which team owns this', 'the queue is backed up', 'is this P1', 'ticket keeps bouncing'. Not for the periodic recertification of who should have access — that is it-access-review; not for scheduling the fix once it needs a controlled production change, which is it-change-management. - Skill: `alihusains/it-service-desk-triage` (Agent Skill) - Install (CLI): `npx skillmds@latest add alihusains/it-service-desk-triage` - Raw SKILL.md: https://api.skillmd.com/api/skills/alihusains/it-service-desk-triage/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: alihusains (https://skillmd.com/u/alihusains) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/alihusains/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).