Read a few help desk postings and a strange vocabulary starts repeating: incident management, service requests, SLA compliance, change control. Nobody defines the terms, because inside the industry they are as basic as “ticket.” They all come from one place, a framework called ITIL, and you can learn the working core of it in one sitting. This is that sitting.
A playbook, but mostly a vocabulary
ITIL is a set of practices for running IT departments, developed decades ago and revised ever since. Consultants will happily sell you its philosophy for a week. A new tech needs something smaller: the realization that your ticketing system’s categories, priorities, and timers are all ITIL ideas wearing software, and that the words mean specific things.
Four of those words do most of the work, so here they are, with the distinctions that matter.
Incident versus request, firefighting versus fulfillment
An incident is something that was working and now is not. Printer dead, account locked, Wi-Fi down, spreadsheet quietly eating itself. The clock matters, someone is blocked, and the goal is restoration.
A service request is someone asking for something new. Access to a shared drive, or a laptop for a new hire. Nothing is broken. It is fulfillment work with an expected turnaround rather than an emergency timer.
The distinction sounds bureaucratic and is not. Desks staff, prioritize, and measure the two streams differently, and filing one as the other causes real friction: a request logged as an incident screams for urgency it does not deserve, and an incident logged as a request quietly rots in a fulfillment queue while a user sits blocked. Categorizing correctly is one of the first things a new tech is actually trusted to do.
Problems and changes, the two behind-the-scenes words
A problem, in ITIL’s usage, is the underlying cause behind repeating incidents. Twelve tickets about the same crash are twelve incidents and one problem. Tier 1 closes the incidents; someone above works the problem so incident thirteen never arrives. When your notes spot the pattern, “third one this week, same update each time,” you are feeding problem management, and it is the most senior-looking thing a junior tech can put in a ticket.
A change is any deliberate modification to a production system, and change management is the approval ritual around it. This is why IT cannot “just quickly” swap a server setting on a Tuesday afternoon, and why so many fixes land during scheduled windows at awful hours. After you watch one unreviewed quick fix take down a whole department, the paperwork stops looking silly.
The SLA, or why the queue has a clock
A service level agreement is IT’s promise about speed: a ticket of priority X gets a first response within so many hours and a resolution within so many more. High priority might mean an hour; low priority, a few days. The pairing that decides priority is impact and urgency, how many people are hurt and how badly.
For you on the desk, the SLA is the physics of the queue. It is why you answer the fresh high-priority ticket before the comfortable old low one, why a ticket “breaching” gets sudden attention from your lead, and why updating a waiting ticket matters even when there is no news, since response clocks care that the user was not abandoned. Desks are measured on SLA numbers, so learn early which clocks your desk fears the most and let those clocks order your morning. That habit alone reads as six months of experience.
One adjacent oddity worth knowing: “resolved” and “closed” are usually separate states. Resolved means the fix is in and the user can confirm; closed means the story is over. Confirm before you close and the bounce-backs stop following you.
Do you need the certificate
Eventually, maybe. The ITIL Foundation certification is a modest exam that large companies and MSPs like seeing, and it is a reasonable pickup once you are working. For getting hired at tier 1, the vocabulary above is the actual requirement, and interviewers test it conversationally: describe a busy queue and see whether the candidate reaches for impact, urgency, and escalation like they have lived them.
Living them is arrangeable. The ServiceDesk Simulator runs a queue where priorities compete and the triage is yours to get wrong cheaply, which is how the vocabulary stops being vocabulary. Say “I worked the higher-impact ticket first and kept the other user updated” in an interview and you are not reciting ITIL, you are describing last Tuesday.