An incident is an unplanned disruption to a service that was working, and the goal is to restore it as fast as possible. A service request is a routine, pre-approved ask for something standard, such as access, a device, or a password reset, and the goal is to fulfil it correctly. Incidents fix what is broken; service requests deliver what is asked for. That single distinction drives how each ticket is prioritized, routed, measured, and staffed.
Last updated: July 2026.
Service desks that skip this classification end up with one undifferentiated queue where a laptop request and a payment gateway outage sit next to each other, sorted by arrival time. Everything then gets the same urgency, which in practice means the loud tickets get worked and the important ones wait. Splitting the two is the cheapest structural improvement most support operations can make.
What is the difference between an incident and a service request?
In ITIL terms, an incident is an unplanned interruption to a service or a reduction in its quality. Something that used to work has stopped working, or has degraded: a full outage, an error that blocks a workflow, a page that now takes 30 seconds to load. The response is corrective. You are trying to get back to normal service, and speed matters more than elegance, which is why a documented workaround is a legitimate incident resolution.
A service request is a formal request from a user for something they are entitled to and that the organization has already decided how to deliver. Nothing is broken. There is a known procedure, often an approval step, and a predictable amount of work. The response is fulfilment rather than repair, and quality and accuracy matter more than raw speed.
ITIL 4 keeps that distinction but frames it around value streams rather than process silos, and it pushes classification toward business impact rather than technical category. The practical effect is the same: unplanned disruption on one side, planned fulfilment on the other.
Incident vs service request: side by side
| Dimension | Incident | Service request |
|---|---|---|
| Trigger | Something working has broken or degraded | A user needs something standard |
| Goal | Restore normal service | Fulfil the request correctly |
| Planned? | No, always unplanned | Yes, a known and repeatable procedure |
| Typical scope | Can affect one user or the whole company | Usually one user or a small team |
| Approval needed? | Rarely, restore first | Often, especially for access or spend |
| Priority driver | Impact and urgency | Request type and complexity |
| Typical target | Hours for critical, same day for most | Days, set per catalogue item |
| Success measure | Time to restore, reopen rate | Fulfilment within target, accuracy |
Incident vs service request examples
The abstract definitions are easy to agree with and surprisingly hard to apply at 9am on a Monday. These are the calls that come up most often.
Incidents: the billing portal returns a 500 error for all customers; a single user cannot log in to a system they used yesterday; invoices are generating with the wrong tax rate; the phone queue is dropping calls; a report that ran every morning has stopped arriving; the checkout is slow enough that customers are abandoning it.
Service requests: a new starter needs an account and a laptop; a manager wants read access to a dashboard; a team asks for extra storage; someone wants software installed; a customer asks you to change the email address on their billing contact; a department requests a new shared mailbox.
Two tests settle almost every ambiguous case. First, was it working before? If yes, and it is not now, it is an incident. Second, is there an existing, approved procedure for delivering this? If yes, and nothing is broken, it is a request.
Is a password reset an incident or a service request?
A standard password reset is a service request. Nothing has broken, the user simply needs something routine delivered through a known procedure, and it is one of the most common catalogue items on any service desk. The account is working as designed; the user has forgotten a credential.
It becomes an incident when the reset fails or the cause is a fault. If the authentication service is rejecting valid passwords, if a user is locked out because a directory sync broke, or if resets are failing for everyone, that is an unplanned disruption to a working service and it should be handled as an incident, with the impact assessed across all affected users rather than one.
Incident vs service request vs problem vs change request
Four ticket types cover almost all service desk work, and the two people usually confuse with incidents are problems and changes.
| Type | What it is | Question it answers | Example |
|---|---|---|---|
| Incident | Unplanned disruption to a service | How do we restore this now? | Payment page returning errors |
| Service request | Routine ask with a known procedure | How do we deliver this correctly? | Access to a reporting tool |
| Problem | The underlying cause of one or more incidents | Why does this keep happening? | A memory leak causing weekly outages |
| Change request | A planned modification to a service | How do we make this change safely? | Upgrading the payment provider |
The relationship runs in a chain. Repeated incidents justify raising a problem record. Fixing the problem permanently usually requires a change. The mistake to avoid is doing root cause analysis inside an incident ticket while customers are still down, because it delays restoration and buries the analysis in a record that gets closed the moment service returns.
Why the classification changes your SLAs and routing
Once the two are separated, you can give them the targets they actually deserve. Incidents are graded on impact and urgency, so a critical outage carries a target measured in hours while a single-user annoyance can run to the end of the next business day. Service requests are graded per catalogue item, so a password reset might target 30 minutes while a new hardware build sensibly targets five working days. Applying one blanket target to both produces numbers that are meaningless in either direction.
Routing changes too. Incidents need to reach whoever can restore the service, sometimes immediately and out of hours, which is what an escalation matrix exists to define. Requests need to reach whoever owns the fulfilment step and whoever approves it, which is usually a different person and rarely urgent. Most desks lose more time to tickets sitting with the wrong owner than to the work itself, and the fix is a set of rules that route each ticket to the person who can actually close it based on its type, rather than leaving triage to whoever opens the queue first.
The measurement side follows the same split. Incidents belong to resolution time and reopen rate; requests belong to fulfilment within target and accuracy. Reporting them together produces an average that describes nothing real, which is also why the difference between response time and resolution time needs to be settled before you publish any targets at all.
How to categorize at intake
Classification is cheapest at the front door and expensive everywhere after it. Three things make it stick.
Give users two clear paths rather than one box. A request catalogue with named items ("request access", "order equipment") captures requests before they arrive as free text, while a separate "report a problem" path collects incidents. Users classify themselves reasonably well when the choices are concrete.
Let agents reclassify without friction. Some tickets will arrive wrong, and if changing the type resets the clock or loses the history, agents will leave them misfiled. Reclassification should be one action, logged, with the original intake reason preserved.
Review misclassifications monthly. A pattern of requests arriving as incidents usually means a missing catalogue item, and a pattern of incidents arriving as requests usually means users have stopped believing the incident path gets a faster answer. Both are fixable, and both are invisible unless someone looks. The same review typically surfaces the repeat questions that belong in a knowledge base instead of a queue.
Frequently asked questions about incidents and service requests
Is a service request an incident? No. A service request is a routine ask for something standard, delivered through an existing procedure, and nothing is broken. An incident is an unplanned disruption to a service that was working. They share a queue and a ticketing tool, but they have different goals, different targets, and usually different owners.
Can a service request become an incident? Yes, and it happens regularly. If fulfilling a request fails because something is broken, such as a provisioning system that will not create accounts, the underlying fault is an incident and should be raised as one. The request stays open and blocked, the incident tracks the restoration, and both close when the user finally has what they asked for.
What is the difference between an incident and a problem? An incident is a single disruption and the goal is restoring service quickly, even with a temporary workaround. A problem is the underlying cause behind one or more incidents, and the goal is a permanent fix. You close incidents in hours and problems in weeks, and closing a problem should stop future incidents from being raised at all.
Who decides whether a ticket is an incident or a service request? The service desk does, at triage, using the impact of the ticket rather than how the user described it. Users are not expected to know the categories. A good intake form guides them toward the right path, but the agent picking the ticket up owns the final classification and should be able to change it without penalty.
Getting these two categories right is the foundation everything else on a service desk sits on: sensible SLA targets, honest reporting, and a queue that reflects real priority. If you are still deciding how to structure the desk itself, our comparison of a help desk and a service desk covers where each model fits.