Incidents, problems and changes
A service desk that treats every call the same way drowns on its first busy Saturday. This lesson gives you the simple process most IT teams use: sort every ticket into the right kind, set its priority from impact and urgency, fix the cause once instead of fifty times, and change live systems with a plan to undo the change.
By the end you can
- Tell an incident, a service request, a problem and a change apart, and say why each has its own clock
- Set a ticket's priority from impact and urgency, and know which SLA timer it starts
- Write a ticket that the next person can act on without calling the store back
- Run your part of a major incident and turn repeat incidents into a problem with a known error
- Write a change request with a test plan, a schedule and a rollback plan that has a clear trigger
The everyday picture
Think of a hospital's emergency department. Patients arrive in any order, but the triage nurse does not treat them in that order. A man with chest pain goes in first; a child with a sprained wrist waits. The nurse decides in two minutes, from two questions: how bad is it, and how fast will it get worse?
The doctors on the ward have one job: stop the bleeding and get the patient stable. They do not stop to ask why so many people from the same street have stomach pains this week. That question goes to someone else, who finds the cause: a broken water pipe. Fixing the pipe is a planned job for the city, with a date, a crew and a plan for what happens if the new pipe leaks.
A service desk works the same way. The triage nurse is first line, the ward is incident handling, the investigator is problem management and the pipe repair is a change. Mixing them up is how a desk ends up rebooting the same router every Tuesday for a year.
Four kinds of ticket, four different clocks
Most IT teams follow some version of ITIL. You do not need the certificate to work this way; you need four words and the habit of using them correctly. Every ticket that reaches Mangrove's TechOps desk is one of these:
- An incident: something that worked has stopped working, or got worse. A till in store-0142 will not print receipts. The goal is to restore service as fast as possible, even with a workaround.
- A service request: someone wants something normal. A new staff member needs a till PIN and a scanner (the access part is in Accounts, SSO and MFA). Nothing is broken, so it follows a standard recipe and a calmer clock.
- A problem: the cause behind one or more incidents. Scanners in six stores have dropped off Wi-Fi nine times this month. Each incident was fixed by a reboot; the problem asks why they keep dropping.
- A change: a planned edit to a live system. Updating the print service on 320 store boxes, adding a firewall rule, replacing a certificate.
Each label brings a different owner, deadline and measure. A request for a new mouse logged as an incident pushes real breakages down the queue. A ninth scanner drop closed as "rebooted, fixed" means nobody is ever asked to find the cause.
Quick check
Ama, a store manager, asks the desk for a second label printer because her store has opened a bakery counter. What kind of ticket is this?
Nothing that worked has stopped working, so it is not an incident. A new printer from the standard catalogue is a service request with its own recipe. Installing it may involve a small standard change behind the scenes, but the ticket Ama opens is a request, and it should not compete with breakages for the incident clock.