Incident vs request vs problem vs change in ITSM: a practical sorting guide

Most small IT teams start with one kind of ticket: “something someone emailed us about.” That works until a client asks why the same printer queue broke four times this quarter, or a Friday-afternoon firewall tweak takes down a branch office. Those are the moments the incident vs request vs problem vs change distinction in ITSM stops being jargon and starts being useful.

This guide skips the framework theory. It gives you a four-question test for sorting any ticket, worked examples, and the specific mistakes that come from collapsing everything into one bucket. The names match the practices listed in ITIL (incident management, service request management, problem management, and change enablement, per the ITIL overview on Wikipedia), but you don’t need certification to use the idea.

The one-sentence versions

• Incident: something that was working is broken or degraded, and someone needs it restored.
• Request: someone wants something that is normally available, such as access, a new laptop, or a password reset.
• Problem: the underlying cause behind one or more incidents, tracked so it can be fixed for good.
• Change: a planned modification to your environment that carries risk and should be reviewed before it happens.

The key insight: these aren’t four sizes of the same thing. They answer four different questions: restore it, provide it, understand why it keeps happening, and alter it safely.

The four-question sorting test

Run any new ticket through these in order. Stop at the first “yes.”

1. Is something that used to work now broken or slow? Yes means incident. The goal is service restored, not root cause.
2. Is the person asking for something that is a normal, pre-approved part of what you offer? Yes means request. Think onboarding, software installs, mailbox access.
3. Is this the third time you’ve fixed the same thing, or did you just restore service without knowing why it broke? Yes means open a problem, linked to the incidents behind it.
4. Does fixing it, or preventing it, require modifying production systems in a way that could cause an outage? Yes means change.

A single event often produces more than one record. That’s correct, not bureaucratic, and we’ll walk through it below.

Incidents: restore first, explain later

An incident is measured by how fast service comes back. The technician’s job on an incident is to get the user working, even with a workaround, and then record what they did.

Examples: the VPN won’t connect for a whole site; email is bouncing; a user’s laptop can’t reach the file share; the phone system is down.

What good incident handling looks like:

• A clear priority (who is affected, and how badly) rather than “first come, first served.”
• A response and resolution target tied to that priority. If you’re building those, our guide to affordable help desk software with real SLA tracking covers what to check.
• A resolution note that says what was done, because that note is raw material for problem management later.

Common mistake: spending two hours finding the root cause while the user is still down. Restore first. If the cause is interesting, open a problem and chase it after the user is working.

Requests: boring on purpose

A request isn’t a failure. Nothing is broken; someone needs a thing. Requests should be predictable, which means they can usually be templated: the form asks for the right details, the right person approves, and a checklist drives the work.

Examples: new-hire account setup; shared mailbox access; a software license; moving a desk.

What good request handling looks like:

• A short catalog of common requests with fixed fields, so you stop asking “which department?” by email every time.
• Approval only where it matters (spend, privileged access), not on every item.
• A lower urgency profile than incidents. Mixing them in one queue means a monitor request outranks a down server, or the reverse.

Common mistake: logging requests as incidents because the ticket form only has one type. Your incident metrics then fill with “new keyboard,” and your mean time to resolve looks fine for the wrong reasons.

Problems: the ticket most small teams never open

A problem record exists to answer “why does this keep happening?” It’s linked to the incidents it explains, and it lives longer than any of them. Incidents get closed in hours; a problem may stay open for weeks while you test a fix.

Example: four incidents in a month, each “Wi-Fi drops in the conference room.” Each was closed by rebooting the access point. The problem record says: access point firmware has a known fault under load; replace or patch. The fix then goes through change (see below), and when it lands, all four incidents are explained by one closed problem.

When to open one:

• The same symptom appears three or more times.
• You restored service with a workaround and don’t know the cause.
• A client asks for a post-incident explanation.
• A single incident was severe enough that you need to prevent a repeat.

What a problem record holds: the linked incidents, a root-cause hypothesis, the workaround (so techs can resolve repeats quickly), and the permanent fix once known. The workaround field is underrated. It turns the next 2 a.m. incident into a thirty-second lookup.

Common mistake: treating problem management as an enterprise luxury. For a small MSP it’s closer to a profit lever: every recurring incident you eliminate is unbilled or low-margin work you stop doing.

Changes: where outages are born

A change is any deliberate modification that could affect service: patching a server, altering firewall rules, migrating mail, replacing a switch. The change record exists so that someone other than the person doing the work has looked at the risk.

You don’t need a heavy committee. A workable small-team model has three paths:

• Routine (pre-approved): low-risk, repeatable, documented. Example: monthly patching of workstations. Approve the procedure once, then log each run.
• Normal: needs a quick review. A second technician or the owner reads the plan, rollback, and window, and approves.
• Emergency: needed now to stop an active outage. Do it, then record it and review it afterward.

What a useful change record contains:

1. What’s changing and why
2. Which systems or clients are affected
3. The scheduled window
4. The rollback plan (the field people skip, and the one that matters)
5. Who approved it and when

Common mistake: doing the change without a record because “it’s just a quick tweak.” The next outage investigation starts with “what changed?” and you have no answer.

Worked example: one event, four records

A client’s accounting software can’t reach its database on Monday morning.

1. Incident: “Accounting app down for 6 users.” A tech finds the database service stopped, restarts it, and service is restored in 20 minutes. Resolution note: “Service crashed; restarted.”
2. Problem: it’s the second crash this month. A problem is opened, linked to both incidents. Investigation shows the disk is 98% full from unrotated logs.
3. Change: the permanent fix is to add log rotation and expand the volume. That’s a production change, so it gets a record with a window (Saturday night), a rollback plan, and approval from the owner.
4. Request: while talking to the client, they ask for two more user accounts on the accounting app. That’s a separate request, not a comment buried on the incident.

Four records, four different owners of the outcome, and a clean history if the client later asks “what happened in October?”

How to keep the model from becoming paperwork

The usual objection from small teams is “we’ll drown in process.” A few rules keep it light:

• Default new tickets to incident or request, and only promote to problem or change when the test says so.
• Don’t open a problem for every incident. Use the three-repeats rule or severity.
• Keep change approval proportional. A routine change should take one minute to log.
• Link, don’t copy. An incident that points to a problem should not duplicate the root-cause analysis.
• Review weekly for ten minutes: open problems, upcoming changes, incidents that repeated.

What to look for in a tool

Whatever you use, check that it supports these distinctions natively rather than through a custom field you have to remember:

• Separate ticket types with their own forms and fields
• Linking between records (incidents to a problem, a problem to a change)
• Approval on changes
• Reporting that can filter by type, so incident metrics aren’t polluted by requests
• A CMDB so changes and incidents attach to real assets; see help desk software with a CMDB.

If you’re still on a shared inbox where all of this lives in people’s heads, our walkthrough on moving from a shared inbox to a help desk covers getting started, and the small-MSP help desk checklist covers why these ticket types matter when you serve multiple clients.

How ITSM handles it

ITSM treats incidents, requests, problems, and changes as native ticket types, alongside a knowledge base, CMDB, and SLA tracking, so linking an incident to a problem or attaching a change to an affected asset doesn’t need workarounds. You can try it on the free tier at /register and sort a week of your real tickets to see whether the model fits your team.

ITSM is a small product with a free tier, so test it against your own tickets before relying on it.