Without structured Service Management Practices, your company loses 20% of employee productivity every time a critical system goes down, because no one knows how to report the issue, who fixes it, or whether it is a one-time glitch or a recurring disaster. This chapter explains the three essential practices — Incident, Service Request, and Problem Management — that IT professionals use to restore services fast, grant routine requests efficiently, and stop problems from ever happening again.
Jump to a section
A simple way to picture Service Management Practices (Part 1): Incident, Service Request, and Problem Management
3 seconds. That is the average time a person in your office will wait before walking away from a broken coffee machine. Now imagine 200 people in a 9-storey building with one working coffee machine. That is 200 separate 'Incidents' timed to the second — each person reporting the same issue to the facilities team. This is the exact problem Incident, Service Request, and Problem Management solve in IT.
The facilities team logs every report as an 'Incident' (an unplanned interruption to the coffee service). They then 'diagnose' each report — is it the bean hopper (the software), the water line (the network), or the power supply (the electricity to the server room)? They apply a 'workaround' (restart the machine or tell everyone to use a different floor's machine) to restore service quickly. Meanwhile, the 'Problem Management' team investigates why the machine keeps failing. They find the real 'root cause' (the water filter is clogged, causing the pump to overheat — a known defect in this model). They submit a 'known error record' (the official documentation of this defect) and arrange a permanent 'resolution' (install a new filter type).
The 'Service Request' is different entirely: someone asks for a new type of coffee bean to be stocked, or a spare cup dispenser to be installed. This is a standard pre-approved change, not an emergency. The facilities team fulfils it via a standard 'service request fulfilment workflow' — a predictable, low-risk process. The key insight: one report is an incident. One hundred reports from the same root cause is still one problem. The goal is to fix the filter, not to keep restarting the machine.
Service Management Practices are the playbooks that IT teams follow to keep technology working. For the ITIL 4 Foundation exam, you must understand three specific practices: Incident Management, Service Request Management, and Problem Management. They are often confused by beginners, but they handle very different situations.
Incident Management is the practice of minimising the negative impact of unplanned interruptions or quality reductions in an IT service and restoring normal service as quickly as possible. The key word is 'restore'. An Incident is any event that is not part of the standard operation of a service and that causes, or may cause, an interruption to or a reduction in the quality of that service.
Examples of Incidents: a user cannot log in to their email; the company website is returning a 500 error; a printer is jammed; a laptop blue-screens; an entire data centre loses power. Incidents can be reported by users (via a phone call, email, or portal) or detected automatically by monitoring tools (for example, a server alerts the IT team that its hard drive is 99% full).
The goal of Incident Management is NOT to fix the underlying cause forever. The goal is to get the service working again — even if that means using a 'workaround' (a temporary fix that restores service but does not address the root cause). For example, if a user's email breaks because their password expired, a workaround is to reset the password. The root cause (the password expiry policy is too short) is not fixed, but the user can send emails again. That is a success for Incident Management.
Service Request Management handles a completely different type of work. A Service Request is a formal request from a user for something to be provided — for example, access to a new application, a new laptop, information about a service, or a standard change (like resetting a password). Key distinction: a Service Request is a pre-defined, standard, low-risk request that follows a 'self-service' or 'standard fulfilment' process. It is NOT an emergency and it is NOT a response to a failure.
The purpose of Service Request Management is to fulfil these requests efficiently and consistently, often through an automated portal or catalogue. Examples: 'I need a new VPN access for my new hire', 'I want to request a software licence for Microsoft Project', 'What is the cost of upgrading my monitor?', 'Please reset my password because I forgot it'. Notice that a password reset can be either an incident (if the system is broken and won't let the user reset it themselves) or a service request (if the user simply forgot and needs a standard reset). The difference is whether the request is a response to a failure (incident) or a standard request for something (service request).
Problem Management is the practice of reducing the likelihood and impact of incidents by identifying actual and potential causes of incidents, and managing workarounds and known errors. The key word is 'cause'. Problem Management asks 'why did this happen?' instead of 'how do I fix it quickly?'.
A Problem is the cause of one or more incidents. When multiple users report the same issue (for example, 'I can't connect to the Wi-Fi in the conference room'), each report is a separate incident. But the underlying cause — a faulty Wi-Fi access point — is the Problem. Problem Management investigates that cause, identifies the 'root cause' (the fundamental reason the access point failed, e.g., its firmware is outdated), and then implements a permanent fix to prevent future incidents.
Problem Management has two sub-practices. - Reactive Problem Management: triggered after incidents have occurred. For example, after three separate incidents of the company's payment system freezing during peak hours, the Problem team investigates and finds that the database query timing is wrong. - Proactive Problem Management: actively looking for potential problems before they cause incidents. For example, the IT team reviews system logs weekly and notices that a server's error rate is increasing. They take preventive action (upgrading memory) before it crashes.
Key terms you must remember for the exam:
Workaround: a temporary solution that reduces or eliminates the impact of an incident or problem, but does not fix the root cause.
Known Error: a problem that has been analysed but not yet resolved. It has a documented root cause and a workaround.
Root Cause: the fundamental reason that caused one or more incidents.
Incident vs Problem: an incident is a single event; a problem is the underlying cause of one or more incidents. You do not fix a problem by restarting a server. You fix it by replacing the faulty hard drive that made the server crash.
The flow in a real IT team works like this:
A user calls the Service Desk: 'My computer is slow.' This is logged as an Incident.
The Service Desk technician applies a known workaround (clear the cache) and the computer speeds up. Incident is closed.
The Problem Manager sees that 50 similar 'slow computer' incidents have been logged this week. They create a Problem record.
The Problem team investigates and finds the root cause: a recent Windows update is causing a memory leak.
They document this as a Known Error: 'Windows update KB1234 causes memory leak on Dell XPS models. Workaround: roll back the update.'
They then plan a permanent resolution: uninstall the update from all affected machines and block it from being installed again.
The problem is resolved when the permanent fix is deployed.
Why does this matter for an ITIL4F exam? The exam will test your ability to distinguish between these three practices. You will be asked to identify which practice is best suited for a given scenario. They love to trick you with service requests that look like incidents (e.g., 'user forgot password' is a service request unless the system is broken).
Incident Logging
The first step when a user reports a problem (e.g., 'I cannot access my email'). The service desk creates an incident record in the ITSM tool, capturing details like the user's identity, description of the issue, time of report, and any error messages. This ensures the issue is not lost and can be tracked.
Incident Categorisation and Prioritisation
The service desk assigns a category (e.g., 'Email', 'Network', 'Hardware') and sets priority based on impact (how many users are affected) and urgency (how quickly it needs a fix). A priority of 1 (critical) might mean the entire company is offline; priority 4 might be a single user's slow mouse.
Incident Diagnosis and Resolution
The support team investigates the incident. They may ask the user questions, check system logs, or apply known workarounds from the knowledge base. If a workaround exists, they apply it and restore service. If not, they may escalate to a specialist team.
Problem Identification
When multiple similar incidents occur, or a single incident indicates a serious underlying issue, a problem record is created. This is a separate record that links back to the related incidents. The goal is to analyse the root cause, not just fix the symptom.
Root Cause Analysis (RCA) and Known Error Recording
The problem team investigates deeply using techniques like 5 Whys, fishbone diagrams, or log analysis. Once the root cause is found, it is documented as a Known Error. A workaround is also documented so that future incidents of the same kind can be resolved quickly by the service desk.
Permanent Resolution and Problem Closure
The problem team implements a permanent fix (e.g., applying a vendor patch, replacing a faulty component, changing a configuration). After the fix is verified, the problem record is closed. The known error is updated to reflect that the issue is resolved, and the workaround may be retired.
Service Request Fulfilment
For a service request (e.g., 'I need access to a shared drive'), the service desk follows a standard operating procedure. They validate the request (checking authorisation), fulfil it (e.g., by adding the user to an access group), and close the request. No diagnosis or root cause analysis is needed.
An IT professional working in a mid-sized company (500 employees) uses these three practices every single day. Let us walk through a realistic morning.
8:30 AM: The IT Support Analyst, Sarah, logs into the IT Service Management (ITSM) tool (like ServiceNow, Jira Service Management, or Freshservice). She sees a queue of open tickets.
First ticket: 'User Jane says her monitor is flickering.' This is an Incident. Sarah checks the known error database. There is a known error for 'Dell U2419H monitor flickering at 60Hz refresh rate' with a workaround: change the refresh rate to 59Hz. Sarah applies the workaround via a remote support tool. The monitor stops flickering. She updates the ticket: 'Workaround applied. Monitor stable. Ticket resolved.' She adds a note to the problem management team that another instance of this known error has occurred. Time taken: 4 minutes.
Second ticket: 'New hire Mike needs access to Salesforce and the internal document repository.' This is a Service Request. Mike's manager has pre-approved the request via an online form. Sarah does not need to diagnose anything. She follows the 'New User Account Setup' standard operating procedure (SOP).
Actions take:
Create a user account in Microsoft Entra ID (the identity management system).
Assign the Microsoft Entra ID group membership for 'Salesforce Users'.
Assign the group membership for 'Document Repository - Internal'.
Send an automated welcome email with login instructions from a template.
She runs a script that automates the provisioning. The entire process takes 2 minutes. The ticket is auto-closed.
Third ticket: 'User Bob reports that the accounting software crashes every time he tries to generate an end-of-month report. This is the third time this week.' This is an Incident (a crash), but because of the recurrence, Sarah escalates it to the Problem Management team. She creates a Problem record linked to the three related incidents.
The Problem Manager, David, takes over. He analyses the crash logs and finds a pattern: the crash happens only when generating reports for months with more than 30 days. He traces the root cause to a bug in the software's date handling library. He cannot fix it himself because the software is vendor-supplied. So he creates a Known Error record: 'Accounting App v3.1 — crash on month-end report generation when month has 31 days. Root cause: date library bug. Workaround: generate the report for the first 30 days separately, then manually add the last day's data.' David communicates the workaround to all affected users and logs a support request with the vendor. The problem is not resolved yet, but the impact is now managed.
Later that week, David also performs proactive problem management. He reviews system logs and notices that the company's email server memory usage has been steadily increasing over 6 weeks. He creates a potential problem record, schedules a memory upgrade for the next maintenance window, and prevents a future incident where the server would have run out of memory and crashed.
The key tools an IT professional uses for these practices include:
IT Service Management (ITSM) tool to log, track, and manage tickets.
Knowledge base (like a wiki or Confluence) to store known errors and workarounds.
Monitoring dashboards (like Nagios, Grafana, or Azure Monitor) to proactively detect issues.
Automation scripts (PowerShell, Python) to fulfil service requests automatically.
Communication channels (Slack, email) to inform users of workarounds and status updates.
The real-world impact: Sarah's fast incident resolution keeps Jane productive. David's problem management stops the accounting crash from becoming a monthly disaster. The automated service request fulfilment means Mike can start work on day one. Without these practices, the company would see 40% more downtime, frustrated employees, and a helpdesk overwhelmed by routine password resets.
The ITIL 4 Foundation exam tests your ability to distinguish between Incident Management, Service Request Management, and Problem Management. You will not be asked to memorise process steps in detail, but you MUST know each practice's purpose, key activities, and the exact definition of core terms.
What they love to test:
Purpose statements: The exam will give you a purpose statement and ask you to match it to the correct practice. For example: 'Which practice aims to restore normal service operation as quickly as possible?' Answer: Incident Management. Or: 'Which practice aims to minimise the impact of incidents by identifying their underlying causes?' Answer: Problem Management.
Incident vs Problem: This is the most common trap. A scenario will describe recurring crashes and ask: 'Is this an incident, a problem, or a service request?' Common trap: they describe a single crash and call it a 'problem' or describe a recurring issue and call it an 'incident'. Correct answer: a single event is an incident; the underlying cause of multiple incidents is a problem.
Service Request vs Incident: Another frequent trap. A user reports 'I cannot print' — this is an incident (unplanned interruption). A user asks 'I need a new printer' — this is a service request (standard request for provision). The trap: users often say 'I have a problem' but the context determines the practice.
Known Error vs Problem vs Incident: They love to ask about the difference between a known error and a problem. A known error is a problem that has been analysed and has a documented workaround. It is not yet resolved. A problem is the initial investigation record. An incident is the event.
Key activities: You need to know typical activities of each practice. For example:
Incident Management includes: incident logging, categorisation, prioritisation, diagnosis, resolution and recovery, closure.
Service Request Management includes: request fulfilment, standard change approval (if needed), delivery, closure.
Problem Management includes: problem identification, logging, categorisation, root cause analysis (RCA), workaround creation, known error recording, resolution.
Prioritisation concepts: They may ask about 'priority' in incident management (based on impact and urgency). This is less common but appears.
Common traps the exam sets: - They give a long scenario describing a user reporting an issue. After the user reports it, the service desk creates a 'problem record'. Incorrect — it should be an incident record first. The problem comes later. - They describe a password reset as an incident. Incorrect if the user simply forgot — it is a service request (unless the system is broken and cannot reset). - They describe proactive problem management as 'preventing incidents'. This is true. Reactive problem management is 'analysing incidents after they occur'. Both are valid. - They say 'problem management resolves incidents'. No, problem management resolves the root cause to prevent future incidents. Incident management resolves the immediate issue.
Key definitions to memorise (you will see these exact phrases in the exam): - Incident: An unplanned interruption to a service, or a reduction in the quality of a service. - Service Request: A formal request from a user for something to be provided (information, access, a standard change). - Problem: A cause of one or more incidents. - Known Error: A problem that has been analysed but not yet resolved. - Workaround: A temporary solution that reduces or eliminates the impact of an incident or problem, but does not address the root cause.
Exam question style: - Multiple-choice: 'Which of the following is a service request?' Options: a) user cannot log in, b) user needs new laptop, c) server is down, d) printer jam. Answer: b. - Scenario: 'A user reports that a software application crashes every time they try to open a specific file. The service desk restores access by copying the file to a different format. Later, the problem team finds that the original file format is corrupted due to a bug. Which statement is correct?' Options: The crash is a problem, the workaround is a known error, etc. Correct answer: the workaround (copying to a different format) is a workaround applied during incident management.
Pro tip: In the exam, if a scenario mentions 'the same issue keeps happening', that is a clue for Problem Management. If it mentions 'restore service quickly', that is Incident Management. If it mentions 'standard request', that is Service Request Management.
The purpose of Incident Management is to restore normal service operation as quickly as possible, using a workaround if necessary.
The purpose of Service Request Management is to fulfil standard, pre-approved user requests efficiently through a defined workflow.
The purpose of Problem Management is to identify the root cause of incidents and prevent recurrence, using reactive or proactive approaches.
An incident is a single event; a problem is the cause of one or more incidents.
A known error is a problem that has been analysed and has a documented workaround, but has not yet been permanently resolved.
Service requests are NOT incidents — they are standard requests for provision of something, not responses to a failure.
Reactive problem management investigates incidents after they occur; proactive problem management seeks potential problems before they cause incidents.
A workaround is a temporary fix that restores service but does not address the root cause.
Incident management is time-sensitive and prioritised by impact and urgency; service request fulfilment follows a standard timeline based on the request type.
These come up on the exam all the time. Here's how to tell them apart.
Incident Management
Focus is on restoring service quickly after an unplanned interruption.
Uses workarounds to minimise immediate impact.
Record is closed once service is restored, even if root cause remains.
Triggered by a single event (user report or monitoring alert).
Problem Management
Focus is on identifying the root cause to prevent recurrence.
Investigates multiple similar incidents or proactive signals.
Record is closed only after a permanent fix is implemented.
Triggered by patterns of incidents or proactive analysis.
Service Request
A standard, pre-approved request for something to be provided.
Does not involve a failure or interruption of a service.
Fulfilled via a standard workflow (often automated).
Examples: 'I need a new laptop', 'Please reset my password'.
Incident
An unplanned event that causes or could cause service interruption.
Involves a failure or quality reduction of a service.
Requires diagnosis, prioritisation, and often a workaround.
Examples: 'I cannot log in', 'The server is down'.
Known Error
A problem that has been analysed and has a documented workaround.
Is a sub-state of a problem record (it is still a problem, but with known info).
Used by the service desk to quickly resolve future incidents with the same cause.
May remain open indefinitely if the permanent fix requires a vendor update.
Problem
A cause of one or more incidents, not yet fully analysed.
Initial record created for investigation.
Does not yet have a known workaround or confirmed root cause.
Aims to become a known error after analysis.
Reactive Problem Management
Triggered after incidents have occurred.
Analyses root causes of existing incidents to prevent recurrence.
Often deals with high-impact or frequent incidents first.
Example: Investigating why the same server crashed three times this month.
Proactive Problem Management
Actively seeks potential problems before any incidents occur.
Uses trend analysis, log reviews, and risk assessments.
Focuses on preventing future incidents altogether.
Example: Noticing increasing CPU usage on a server and upgrading it before it fails.
Mistake
An incident and a problem are the same thing, just different words.
Correct
An incident is a single event (e.g., a user cannot print). A problem is the underlying cause of one or more incidents (e.g., the print server driver is corrupted). They are separate records with different purposes and lifecycles.
Beginners hear 'there is a problem with the server' and think the word 'problem' is interchangeable with 'incident'. In ITIL, they are distinct technical terms with specific definitions.
Mistake
Service requests are always incidents that are less urgent.
Correct
Service requests are not incidents at all. They are pre-defined, standard requests for something to be provided (like a new laptop or access to an app). Incidents are unplanned interruptions to a service. A forgotten password is a service request (if the system works), not an incident.
People naturally think any request for help is a 'problem' or 'issue'. ITIL separates them so that routine tasks can be automated and prioritised differently from emergencies.
Mistake
Once a workaround is applied, the problem is solved.
Correct
A workaround restores service temporarily but does not fix the root cause. The problem remains until a permanent resolution is implemented. The workaround is documented as part of the known error, but the problem record stays open.
Non-IT people (and many beginners) assume 'if the user can work again, the job is done'. ITIL teaches that the problem must be resolved to prevent recurrence.
Mistake
Problem management only deals with technical issues in software.
Correct
Problem management can be applied to any cause of incidents, including process failures, human errors, or supplier issues. For example, if multiple incidents occur because the onboarding process is unclear (causing users to submit wrong requests), that is a process problem that problem management can investigate.
People associate 'problem' with 'IT bug'. In reality, the root cause can be procedural, cultural, or even a vendor's lack of support.
Mistake
The service desk handles incidents, but only senior engineers handle problems.
Correct
The service desk (first line) typically logs incidents and applies known workarounds. Problem management is a separate, often more senior team. But junior staff can contribute to problem identification by escalating recurring incidents. The roles are distinct but collaborative.
Beginners think 'problem' sounds more important and therefore must be done by senior people. The distinction is about the activity, not seniority.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An incident is a single unplanned event (like a user cannot log in). A problem is the underlying cause of one or more incidents (like the authentication server has a memory leak causing the login failure). You fix an incident with a workaround; you fix a problem with a permanent resolution.
If a user simply forgot their password and the system allows standard password reset, it is a service request (a routine request for access). If the password reset function itself is broken or the user cannot reset due to a system error, it is an incident (an unplanned interruption to the service).
Yes, in proactive problem management. The team may identify a potential weakness (e.g., a server log showing increasing error rates) before it causes any incidents. They create a problem record to investigate and prevent future incidents.
A workaround is a temporary fix that reduces or eliminates the impact of an incident or problem without permanently resolving the root cause. For example, restarting a server to make it work again is a workaround if the underlying issue (e.g., a memory leak) is not fixed.
The service desk (first-line support) typically handles incident management — logging, diagnosing, and applying workarounds. Problem management is usually handled by a separate team or senior specialists who perform root cause analysis and implement permanent fixes.
Separation allows different workflows. Incidents are urgent and need fast restoration; service requests are routine and can be automated and fulfilled on a schedule. This prevents high volumes of password resets from delaying critical incident responses.
You've finished Service Management Practices (Part 1): Incident, Service Request, and Problem Management. Continue through the ITIL4F study guide to build a complete picture of the exam.
Done with this chapter?