WEBVTT

1.1
00:00:00.000 --> 00:00:09.600
<v Speaker 1>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.

1.2
00:00:09.600 --> 00:00:20.400
<v Speaker 2>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.

2.1
00:00:20.400 --> 00:00:31.600
<v Speaker 2>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.

2.2
00:00:31.600 --> 00:00:41.200
<v Speaker 1>The aim is speed and stability. We log the ticket, assign urgency and escalate if needed so employees can get back to work quickly.

3.1
00:00:41.200 --> 00:00:51.200
<v Speaker 1>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.

3.2
00:00:51.200 --> 00:01:00.800
<v Speaker 2>Because requests repeat often, we can automate many steps or let junior staff handle them. That frees up senior engineers to tackle actual incidents.

4.1
00:01:00.800 --> 00:01:12.800
<v Speaker 2>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.

4.2
00:01:12.800 --> 00:01:25.200
<v Speaker 1>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.