Back to lesson

Incident vs Request Fulfilment

Slide 1: Incident vs Request Fulfilment

On-screen

Incident vs Request Fulfilment

How to tell a break/fix from a routine ask

Narration

Anna: Let's untangle two concepts that often trip up new support staff: incidents and service requests. They sound similar but lead to very different workflows.
Greg: Picture a computer that suddenly refuses to boot. That's an incident. Now imagine a user politely asking for a new mouse—that's a request. Different problems, different playbooks.

Slide 2: When is it an incident?

On-screen

When is it an incident?

  • Service is down or degraded
  • Unplanned interruption
  • Needs rapid restoration

Narration

Greg: An incident is any unplanned disruption or reduction in the quality of a service. When the payroll system crashes, we drop everything and focus on restoring normal operations.
Anna: The aim is speed and stability. We log the ticket, assign urgency and escalate if needed so employees can get back to work quickly.

Slide 3: What is a service request?

On-screen

What is a service request?

  • Pre-approved standard action
  • Examples: new account or equipment
  • Follows a defined workflow

Narration

Anna: A service request is different. It's a predefined, low-risk action like provisioning an account or ordering approved hardware. No firefighting here—just following a standard procedure.
Greg: Because requests repeat often, we can automate many steps or let junior staff handle them. That frees up senior engineers to tackle actual incidents.

Slide 4: Why the distinction matters

On-screen

Why the distinction matters

  • Incidents drive MTTR metrics
  • Requests track user satisfaction
  • Clear separation keeps teams efficient
Is service degraded or unavailable?
yes →
IncidentRestore service fast; track MTTR
no ↓
Is it a standard, pre-approved ask?
yes →
Service requestCatalog item; workflow + approvals
no ↓
Hunting for an underlying cause?
yes →
ProblemFind the cause; prevent recurrence
no ↓
Otherwise: plan it properly
ChangeRisk review; implementation window
One question at a time routes new work into the right ITIL practice.

Narration

Greg: Keeping incidents and requests separate means we measure the right things. Incident metrics show how fast we recover from outages, while request stats reveal how well we serve everyday needs.
Anna: So the next time something goes wrong, check whether you're fixing a broken service or just helping with a routine task. Getting it right keeps support queues manageable and customers happy.