Incident vs Request Fulfilment ============================== Slide 1: Incident vs Request Fulfilment 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. On-screen text Incident vs Request Fulfilment How to tell a break/fix from a routine ask Slide 2: When is it an incident? 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. On-screen text When is it an incident? - Service is down or degraded - Unplanned interruption - Needs rapid restoration Slide 3: What is a service request? 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. On-screen text What is a service request? - Pre-approved standard action - Examples: new account or equipment - Follows a defined workflow Slide 4: Why the distinction matters 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. On-screen text 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.