Incident vs Service Request: The Difference and Why It Matters

The difference between an incident and a service request: an incident is something that should work and doesn't — an unplanned interruption, like a laptop that won't boot or email that's down — while a service request asks for something standard from a working service, like folder access, a new monitor or a password reset. Incidents are about restoring service fast; service requests about fulfilling a known process reliably. They need different targets and workflows, but requesters shouldn't have to know which is which.

Definitions, in plain words

IT service management practice — ITIL is the best-known framework — distinguishes several kinds of work that arrive at a service desk:

Type	What it is	Example	Goal
Incident	Unplanned interruption or reduction in quality of a service	"The VPN disconnects every 10 minutes"	Restore service quickly
Service request	A request for something standard: information, access, a pre-approved change, equipment	"I need access to the finance dashboard"	Fulfil a known process reliably
Problem	The underlying cause of one or more incidents	"Why does the VPN keep dropping for everyone on floor 3?"	Find and remove the root cause
Change	Adding, modifying or removing something that could affect services	"Upgrade the VPN gateway firmware"	Make changes safely

Most internal desks see mostly service requests and incidents. Problems and changes matter once the same incidents keep recurring or changes keep causing them.

How to tell them apart

Ask one question: was this working before, and is it supposed to be working now?

• Yes → incident. "My laptop won't turn on." "The printer on floor 3 is jammed." "I can't log in to payroll."
• No, I'm asking for something new or standard → service request. "Please set up a laptop for our new starter." "Can I get Figma access?" "What's the Wi-Fi password for guests?"

Edge cases:

• Password reset: usually treated as a service request (a standard, repeatable procedure), even though the user is blocked.
• "How do I…?" questions: service requests for information — and prime candidates for self-service articles.
• A request that reveals a fault: "Please give me access" → "you already have access, but the permission sync is broken" → it became an incident. Reclassify it and note why.

Why the distinction matters

Different targets

Incidents are measured by how fast service is restored, and severity drives urgency: a company-wide outage needs minutes, one person's slow laptop needs hours. Service requests are measured by fulfilment against a known duration: access within one business day, equipment within five. Mixing them into one target makes both meaningless — "resolve everything in 24 hours" is too slow for an outage and impossible for a hardware order. Per-type targets are covered in the SLA tracking guide.

Different workflows

• Incidents: diagnose, work around, fix, confirm with the user. Often unpredictable. Major incidents need a coordinated response — one owner, one communication channel, a written review afterwards.
• Service requests: a repeatable procedure, often with an approval step (a manager approves access) and a checklist. Predictable — and therefore automatable.

Different improvement strategies

• Reduce incidents by fixing root causes (problem management). Ten incidents with the same cause are one problem.
• Reduce the effort of service requests by standardizing, automating and offering self-service. The fastest access request is one approved and provisioned without anyone typing.

Different reports

Incident trends show reliability: is the VPN getting better or worse? Service request trends show demand: how many laptops will we order next quarter? One blended "tickets per month" number answers neither.

Don't make requesters classify

Here's the catch: requesters don't know or care about the difference. Asking "Is this an incident or a service request?" on a form produces random answers. Instead:

• Ask what they need in their own words, with a team picker written as problems ("Something is broken" / "I need access or equipment" / "I have a question").
• Map categories to types behind the scenes. Categories like "Hardware fault" and "Outage" are incidents; "Access", "Equipment" and "How-to" are service requests. The type follows from the category.
• Let triage correct it. The triage owner confirms category — and therefore type — in seconds.
• Use AI suggestions carefully. A model can suggest the category from free text; apply it automatically only when confident. See AI request classification with structured output.

Priority works differently for each

For incidents, priority comes from impact and urgency — how many people are affected and how fast it gets worse. For service requests, priority is usually fixed by type (a new starter's laptop before their start date is urgent by definition; a second monitor isn't) with occasional exceptions. The matrix approach is explained in managing request priorities without chaos.

Major incidents

When an incident affects many people — nobody can sign in, the network is down — treat it differently:

1. One incident owner coordinates; others investigate.
2. One place for the responders to talk — a dedicated team room rather than scattered messages.
3. One public status, updated regularly, so the desk isn't flooded with "is it down?" requests. Link duplicates to the main incident instead of working each one.
4. A written review afterwards: timeline, cause, what changes. That review usually opens a problem record.

Setting it up in a request desk

You don't need a separate tool for each type. One desk can handle both if the data model carries the distinction:

• Each category has a type — incident or service_request — set by an admin once. Requesters never see the word.
• Each category has its own targets. "Outage" might be 15 minutes to first response; "Equipment" one business day to first response and five to fulfilment.
• Service-request categories can carry a checklist template and an approver. "Software access" gets "manager approves → licence assigned → confirmed with user".
• Incident categories can be linked to a parent. When twenty people report the same outage, link their incidents to one parent; resolving the parent resolves the children and notifies everyone.
• Reports split by type. Incident volume and restore time on one chart; service-request volume and fulfilment time on another.

Common mistakes

• Calling every ticket an "incident". It inflates incident numbers and hides whether reliability is improving.
• Handling standard requests like investigations. If "new laptop" takes three back-and-forth messages every time, it needs a template, not a smarter agent.
• No link between repeat incidents. Twenty separate tickets for one outage mean twenty separate replies and a queue nobody can read.
• Closing incidents without problems. Restoring service is the first job; stopping it happening again is the second, and it's easy to skip.

A worked example

Monday, 09:05: twelve people report that they can't reach the shared drive.

• Each report is an incident. Triage links them to one major incident owned by the infrastructure lead.
• 09:40: service is restored by restarting a file server. Incidents resolved.
• The same thing happened last month. A problem is opened: why does the file server hang?
• Root cause: a backup job saturates disk I/O at 09:00. The fix — moving the backup to 02:00 — is a change, scheduled and approved.
• Meanwhile, a new starter's service request for shared-drive access, filed at 09:10, waited in the normal queue with its normal one-day target. It wasn't mixed into the outage.

Four kinds of work, each handled on its own terms.

FAQ

What is the difference between an incident and a service request?

An incident is an unplanned interruption or degradation of something that should work. A service request is a request for something standard — access, equipment, information — from a service that's working as designed.

Is a password reset an incident or a service request?

Usually a service request: it's a standard, repeatable procedure. Many teams reduce them with self-service reset.

Should users choose whether their ticket is an incident?

No. Ask what they need in plain words, map categories to types behind the scenes, and let triage confirm.

What's the difference between an incident and a problem?

An incident is a single interruption to restore. A problem is the underlying cause of one or more incidents, investigated so they stop recurring.

Sources

• Atlassian — Incident management
• Atlassian — Problem management
• Wikipedia — Incident management
• Axelos — ITIL service management