it-service-desk-triagelisted

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