Service Request vs Incident: How to Tell Them Apart
Treating every ticket the same way sends outages to the back of a queue and sends routine requests to the on-call phone. Four labels prevent both.
Support queues mix very different kinds of work. The simplest way to sort them is by asking what the person wants and whether anything is broken.
The four labels
- Service request: the person wants something that is standard and expected, and nothing is broken. A new account, access to a folder, a replacement keyboard, a question about how to do something. It follows a defined procedure and is not a failure of the service.
- Incident: something that should work does not, or works badly. A user cannot sign in, a page returns errors, email is delayed. The goal is to restore service.
- Problem: the cause behind one or more incidents. Sign-in fails for different people every Monday. The goal is to find and address the cause.
- Change: a modification to a service or system, requested or planned. An upgrade, a new integration, a configuration change. It follows the change process.
Examples that look similar
- "I need access to the finance folder": a request. "I could open the finance folder yesterday and now I cannot": an incident, because something that worked has stopped.
- "Can you add a field to this form?": a change request. "The form will not submit": an incident.
- Five people report that the same page is slow: one incident, not five tickets. Link them.
- The slow page returns every month: a problem, opened after the second occurrence.
Why the distinction matters
- Priority: incidents are prioritised by impact and urgency, and requests by the agreed schedule. Mixing them lets a routine request outrank an outage.
- Routing: incidents may page on-call. Requests should never wake anyone.
- Measures: time to resolve an incident and time to fulfil a request are different measures with different targets.
- Learning: incidents lead to reviews and problems. Requests lead to better forms and articles.
Routing in practice
At intake, ask the requester a question that sorts the ticket: is something not working, or do you need something? Triage can then confirm or correct the label. In Atlas, requests arrive as tasks through forms or email and are triaged one at a time, while an incident is declared in Incident Management with a severity, which can page the on-call responder. When several requests turn out to describe one outage, declare an incident and link the requests to it.