Why the words matter
People new to IT support often hear a handful of terms used as though everyone knows them: incident, problem, request, change. They sound alike, and in everyday speech they are. Inside service management they mean different things, and the difference decides how work is handled, who does it and how it is measured.
This article defines the main processes and shows how they differ. It does not cover every practice in a service management framework, only the ones a newcomer meets first.
One example to follow
Suppose an office shares an email system. On Monday morning, nobody can send messages. That is the running example.
Incidents
An incident is an unplanned interruption to a service, or a drop in its quality. The email stopping on Monday is an incident. The aim of incident handling is to restore normal service as quickly as possible. It does not necessarily find out why it happened.
Typical steps are to record the incident, categorize it, decide how urgent it is, investigate, fix or work around it, confirm with the user and close it. Prioritization usually looks at two things: how many people are affected and how serious the effect is. A fault stopping the whole company from working is treated differently from one affecting a single person’s screensaver.
A workaround is a temporary way to keep going without a real fix. If the team restarts the mail server and email returns, that is a fix of the symptom. If they route messages through a backup system while the server is repaired, that is a workaround.
Problems
A problem is the underlying cause of one or more incidents. Suppose the email stopped because a disk on the server filled up, and the same thing happened last month. The recurring cause, a disk filling with no warning, is the problem.
Problem management looks for root causes and tries to prevent repeat incidents. The work is slower and less urgent than incident handling. It usually involves analysis of past tickets, investigation of the cause and a proposal to fix it permanently, often through a change. A known cause that has no permanent fix yet is sometimes recorded as a “known error” along with its workaround, so that support staff can resolve repeats quickly.
The distinction matters because a team that only closes incidents may deal with the same fault again and again, while a team that treats everything as a deep investigation may leave users waiting. Both processes are needed, and they run on different time scales.
Service requests
A service request is a user’s request for something routine and anticipated: a new account, access to a folder, a software installation, a replacement keyboard. Nothing is broken. The user simply wants a standard service delivered.
Because requests are predictable, they are normally handled through set procedures, often with a form, an approval step where one is needed and a defined delivery process. Listing them in an internal service catalog lets users see what they can ask for. Requests that involve access, such as joiner, mover and leaver activity, may need approval from a manager or system owner.
Mixing requests with incidents causes confusion. A broken laptop is an incident. A new laptop for a new starter is a request. Treating them in the same queue, with the same urgency rules, tends to distort priorities and makes statistics misleading.
Changes
A change is an addition, modification or removal of something that could affect services. Upgrading the mail server is a change. Changes are assessed, approved and scheduled to reduce the risk that they cause new incidents. The process is described in more detail in the article on IT change control. Our email example might lead to a change that adds disk monitoring and extra storage.
How the pieces connect in the example:
| Item | What it is in the example |
|---|---|
| Incident | Email stopped on Monday |
| Workaround | Messages routed through a backup system |
| Problem | The disk fills with no warning and has done so before |
| Change | Add storage and monitoring |
| Request | A new starter asks for a mailbox |
Other processes you will hear about
- Service desk. Not a process but a function: the point of contact that receives incidents and requests and often handles the first stage of each.
- Knowledge management. Keeping useful information so that issues are solved faster and users can help themselves.
- Asset and configuration management. Tracking what exists and how it relates, as with IT asset management.
- Service level management. Agreeing and monitoring the response and resolution times a service should meet. These targets are sometimes called internal service levels when set within an organization.
How the processes work together
An incident may lead to a problem record if it repeats. A problem may lead to a change. A change, if poorly made, may cause new incidents. Requests run alongside, using their own routes. A shared tool with consistent records lets the team see these links, which is one reason organizations use a single ticketing system rather than several.
What good looks like, and its limits
Newcomers sometimes picture service management as a rigid system of forms. In practice, the aim is to give support work a shape that people understand, and the amount of formality should match the organization. A small business might manage with a shared inbox and a notes page, while a large one needs structured workflows.
Established frameworks such as ITIL set out these processes in more depth and give common terms. You do not need to adopt a whole framework to benefit from the ideas. For unfamiliar vocabulary, an ITSM terminology reference helps, and the wider picture of running these processes centrally is in the pillar article on IT service management.
Finally, be wary of relying on numbers alone. Counting tickets closed says little if incidents are miscategorized or requests are counted as faults. Clear definitions, applied consistently, come first.