A service desk gets two kinds of tickets named as incidents and service requests. An incident is something that is broken. A service request is something a user wants. If both are going into the same queue, then a new laptop request will be sitting next to a payroll system that is down, and the payroll one should not be waiting behind anything.
So incident vs service request comes down to one question. An incident is an unplanned interruption to an IT service, and it has to be restored. A service request is a planned ask from a user for something new, standard, or already approved. Simply put, if something is broken, then it should be logged as an incident, and if something is needed, then it is a service request.
Most tickets can be sorted out with that. Some cannot, and those are usually the ones that get misrouted. This guide has the definitions for both, a comparison table, examples that look like tickets you would actually see, where the ITIL split came from, and a framework for the ones that are not obvious.
What is an Incident?
As per ITIL, an incident is an unplanned interruption to a service, also it covers the reduction in the quality of one. So a service that is up but crawling counts, it does not have to be fully down.
Incidents are urgent as they are unplanned, and work gets stopped, so the SLA on an incident should be between minutes and hours.
The size of them varies a lot. It can be one person who cannot get into a single application, and it can also be the whole company with no email for two hours. Both run through the same incident management lifecycle, the difference is in the priority each one is given and how fast the response has to be.
Some incident vs service request examples help here, and these are the incident side of it:
- Payroll system not loading on payday morning
- Sales team cannot access the CRM
- Email delivery delayed by over two hours across the company
- Office Wi-Fi down on floor 3
- VPN dropping every five minutes for the remote engineers
What is a Service Request?
A service request can be referred to as a formal request for something to be provided, approved, set up or changed. For example, a new joiner requesting access to hardware, software, or a permission change that your team has already agreed to provide, and the only real question is how quickly it gets done.
In summary, a service request is planned, low-risk, predictable, and repeatable, which is why it is the best use case for automation and self-service. You can publish the service catalogue, template it, route it, and it can be fulfilled without or with minimal human involvement needed.
The service catalogue is where that happens. It is the list of things your team formally offers, with the fields, approvals, and owners already attached to each one, so the user picks an option instead of describing a problem in free text.
Here is what a typical week of service requests looks like:
- New hire setup: A new starter needs a MacBook and the standard software stack ready before day one.
- Tool access: Marketing needs seats in the Figma org so a new designer can start work.
- Software install: Someone needs Adobe Acrobat Pro on a managed laptop, which triggers a licence check first.
- SSO password reset: A user is locked out of single sign-on and needs their password reset.
- Storage increase: A team needs another 100 GB on a shared drive after a project outgrew its allocation.
Every service request is often a normal, expected task that your team could fulfil the same way every time.
Incident vs Service Request: The Key Differences at a Glance
The fastest way to settle service requests vs incidents is to put them side by side. Every row below changes how the ticket is handled, measured, and staffed.
The difference between incident and service request is pressure to get things done. An incident is evaluated on how quickly you restore something that is already costing the business money or time. A service request is evaluated on whether the same thing arrives the same way every time, for everyone who asks.
Therefore, incident management vs service request management is an operational split rather than a naming exercise. ITIL keeps them as two separate practices for exactly this reason, and the ITIL service request vs incident distinction shows up in how you staff the queue and what you hold the team to.
The ITIL View: Where the Distinction Comes From
The ITIL framework versions set the differences between them. ITIL 2 mentioned everything into incident management, so a laptop request and the server not working pass through the same queue and are handled the same way. ITIL v3 changed that by breaking request fulfillment out as its own process.
ITIL 4 reframed both as practices instead of processes, which is where the current names come from: incident management and service request management.
There are multiple reasons supporting this split. A mixed queue impacts your SLAs, because routine requests inflate your average resolution time and make the desk look slower than it actually is. Also, urgent work gets buried under volume that was never urgent in the first place. So when teams search for ITIL incident vs service request, the problem they are usually trying to fix is a queue problem.
So, the service request vs incident ITIL split exists to protect the queue. Separate the two, and each one finally gets a target it can be measured against.
How to Decide: A Quick Classification Framework
Here is how you can decide which ones fall under incident and service request:
- Was it working before, and is it now broken or degraded? That is an incident.
- Is the user asking for access, hardware, software, information, or a standard change? That is a service request.
- If both look true, classify by what restores the user. Take "I can't log in because I forgot my password". If a self-service reset solves it, log it as a service request. If the auth system is down and nobody can get in, it is an incident.
- If the work involves a non-standard change or carries real risk, it belongs in neither queue. Route it as a change request.
Step three is where most desks lose time, so it is worth being blunt about it. The trigger does not decide the type. The action that puts the user back to work does.
Here are the incident vs service request examples that actually cause arguments:
- Slow VPN: When nothing is fully, it might feel like a complaint. It is an incident, as degradation also counts as broken.
- Password reset, user locked out or system locked out: A user who forgot their password is a service request, because the standard reset path fulfills it. An SSO provider outage that locks out everyone is an incident, even though the ticket text reads identically.
- Software licence, new or broken: A licence for a new starter is a service request. An existing licence that stops validating mid-project is an incident, because something that was working has stopped.
You will still get some wrong. When that happens, convert the ticket type instead of closing it and raising a new one, so the SLA history and the original timestamps stay intact.
So, when the service request vs incident call is genuinely close, ask what was true an hour ago. If the user had it and lost it, you are looking at an incident. If they never had it, it is a request.
What You Gain by Separating Service Requests vs Incidents
Setting the incident and request services differently should not be an admin exercise. You should have set the practices to set the difference between requests vs incidents at intake:
- Routing and SLA fairness: Incidents need to be fixed swiftly, because it is affecting the work. On the other hand, service requests can move through standard fulfilment on their own timeline.
- Reporting honesty: Mixed metrics hide the problems. For instance, resolving a hundred password reset requests might bring down the average resolution time. Separate them, and you finally see real MTTR alongside real request volume, and your downtime trend stops being diluted by routine work.
- Automation payoff: Service requests are repeatable and pre-approved, which makes them the obvious candidates for self-service and workflow automation. Incidents rarely automate fully, because each one needs judgement about cause and impact. So if you are hunting for the place where automation actually returns something, it is almost always sitting in the request queue.
- Agent Focus: When classification is right at intake, your senior engineers spend the day on incidents. Laptop orders and access grants get handled by the path built for them, or by nobody at all once you have automated them properly.
So, the split pays for itself twice. Once in numbers you can trust, and once in the hours your best people stop losing to routine work.
Routing Both Ticket Types in Practice
Classification only works if it happens at intake. If the ticket gets typed after triage, your first response time has already been recorded against the wrong clock, and every report built on top of it inherits that error. So the useful question is whether your intake step forces a choice before any work starts. Most do not.
This matters more now that teams field both types in Slack or Teams as much as through a portal. A portal at least asks a structured question before the ticket exists. A chat channel asks nothing. Someone types "can you sort my VPN" and the type gets decided by whoever picks it up, which is exactly how a degraded service ends up logged as a routine request. So the tooling has to carry the discipline the channel will never enforce by itself.
Suptask handles both incident and service request workflows inside Slack, keeping each type on its own routing path and its own SLA clock, so the user raises and follows the ticket without leaving the channel.
Two other ticket types will surface once the split is working. Problems are recurring incidents with a root cause sitting underneath them, and it helps to recognise when an incident becomes a problem before the same outage arrives for the fourth time. Change requests cover non-standard work that needs review before anyone touches production. Most ITSM software models all four types, though how cleanly it keeps them apart varies a lot.
So, get the type right at the door. Everything downstream, including your SLAs and your automation, rests on that one decision.
Frequently Asked Questions
Is a password reset an incident or a service request?
A password reset is normally a service request. The user has forgotten their credentials and the standard reset path fulfills it, so nothing has actually failed. It becomes an incident when the reset itself cannot run because the identity provider or directory service is down, since that blocks everyone trying to authenticate.
What is the difference between an incident and a change request?
An incident is an unplanned interruption you are working to resolve. A change request is planned work that alters a service and needs review before it goes ahead, because it carries risk to something currently running. The simplest test is intent. An incident puts a service back to how it was, while a change request sets out to make it different.
What are P1, P2, P3, and P4 incidents?
P1 to P4 are priority levels, set by combining how badly a service is affected with how many people it affects. A P1 is a critical outage hitting the whole business with no workaround, and a P4 is a minor issue affecting one person who can still get their work done. Most desks define the thresholds themselves, so the labels only mean something once your own matrix is written down. There is more on how priorities fit the wider process in our guide to the incident management lifecycle.
Can a service request become an incident?
Yes. A request turns into an incident when fulfilling it breaks something live, such as a storage expansion that takes a shared drive offline partway through. The reverse happens too, where an incident turns out to need nothing more than a standard, pre-approved fix and belongs in the request queue. Reclassify the existing ticket either way, so one timeline covers the whole story.
How do I know if a ticket is an incident or a service request?
Ask whether the user had the thing and lost it. If a service that was working has stopped or degraded, it is an incident. If the user is asking for something they never had, such as access, hardware, software, or a licence, it is a service request. Anything involving non-standard or risky work is a change request instead.
Get Incident and Service Request Routing Right at Intake
The distinction is simple in theory and slippery on a live queue at nine in the morning. Getting it right at the point the ticket is raised is what keeps your metrics honest and keeps your senior engineers on the work that genuinely needs them.
Still Sorting Ticket Types by Hand?
Suptask lets your team raise and resolve both incidents and service requests inside Slack, each on its own routing path and its own SLA clock. Your users never have to learn a separate portal.
