Overview
Learning outcome 7 carries 17 of the 40 marks from one assessment criterion, 7.1: explain the following practices in detail, excluding how they fit within the service value chain. The practices are continual improvement, including the continual improvement model; change enablement; incident management; problem management; service request management; service desk; and service level management.
This page splits criterion 7.1 into one topic per practice, because the questions are spread across all seven and each has its own detail. The exclusion matters: you are not asked how these practices map onto plan, engage or other value chain activities. Instead the questions test key concepts and activities inside each practice, such as the three types of change, how incidents are prioritized, the three phases of problem management, or the steps of the continual improvement model.
How it's tested
Questions describe a workplace situation and ask which statement about the practice is correct, what should happen next, or which concept applies. Each practice usually contributes two or three questions. Watch for qualifiers such as best, most and should, and for negative stems that ask which statement is not recommended.
-
Classify the case
A change, request or issue is described and you decide its type, such as a standard change, a service request or a problem.
-
Next step
A stage of the continual improvement model or problem management is described and you choose what should happen next.
-
Recommended practice
Four statements describe how a practice could operate, and only one reflects what ITIL recommends.
A stem says a team replaces a failed hard disk in a laptop using a documented, low-risk procedure that has been carried out hundreds of times. Which type of change is this? It is not urgent enough to be an emergency, and a normal change needs individual assessment and authorization. A low-risk, pre-authorized, well-understood and documented change is a standard change, which is the answer.
Practices in scope 7
Official practices in scope from the PeopleCert outline, in outline order.
7.1.1 Continual improvement, including the continual improvement modelHow continual improvement works as a practice and the seven steps of the model.
- What it means
- Continual improvement is everyone's responsibility, although many organizations also have a small dedicated team that leads and coordinates. The continual improvement model has seven steps: what is the vision; where are we now; where do we want to be; how do we get there; take action; did we get there; and how do we keep the momentum going. Improvement ideas are recorded and prioritized in a continual improvement register.
- What to understand
- The model is a guide, not a rigid procedure, and it can be applied to small improvements or large transformations. The vision step links to organizational direction, the current-state step uses objective measurement, and the target-state step sets measurable goals. Take action can be done in iterations, and checking whether the target was reached prevents assuming success. Key activities of the practice include encouraging improvement across the organization, securing time and budget, identifying and logging opportunities, assessing and prioritizing them, making business cases, planning and implementing improvements, measuring results and coordinating improvement work across the organization.
- How it shows up
- Which step of the model comes next, or which statement about responsibility and the improvement register is correct.
- Common confusion
- Thinking only a dedicated improvement team is responsible; ITIL says everyone contributes.
7.1.2 Change enablementStandard, normal and emergency changes, change authorities and the change schedule.
- What it means
- A standard change is low risk, pre-authorized, well understood and fully documented, and can be implemented without further authorization; it is often raised as a service request. A normal change must be scheduled, assessed and authorized following a process, and its change authority depends on its type and risk. An emergency change must be implemented as soon as possible, for example to resolve an incident or apply a security patch.
- What to understand
- Emergency changes still need assessment and authorization, but these are expedited, may use a separate change authority, and documentation can be completed after implementation. Testing may be reduced or skipped if the risk of not acting is greater. The change authority is the person or group that authorizes a change, and assigning the right authority for each type is essential; in high-velocity organizations authority is often decentralized, with peer review as the key control. The change schedule plans changes, helps communication, avoids conflicts and assigns resources, and also informs incident and problem management. A normal change can be low risk with a quick authority, while its risk assessment for a standard change happens when the procedure is created.
- How it shows up
- Classifying a described change, or choosing the correct statement about authorities, emergency changes or the change schedule.
- Common confusion
- Assuming emergency changes skip authorization entirely; they are authorized, but faster and sometimes by a different authority.
7.1.3 Incident managementPrioritization, separate procedures for major and security incidents, and who resolves incidents.
- What it means
- Incidents are prioritized using an agreed classification based on impact and urgency, so the highest-impact incidents are resolved first. Target resolution times must be agreed, documented and communicated so expectations are realistic. Major incidents and information security incidents usually need their own separate procedures.
- What to understand
- Incidents can be resolved by users through self-help, by the service desk, by support teams, by suppliers or partners, by temporary teams that swarm on a complex issue, or through disaster recovery plans for the most serious cases. Incident records should capture symptoms, business impact, affected configuration items, actions taken and links to problems and changes, which supports later diagnosis. Good collaboration tools and knowledge sharing improve the speed of resolution. Swarming, where many people work together until it becomes clear who is best placed to continue, is presented as useful for complex incidents.
- How it shows up
- Statements about prioritization, records, swarming or separate procedures, often with a scenario.
- Common confusion
- Prioritizing by the order incidents were logged or by who reports them, instead of impact and urgency.
7.1.4 Problem managementProblem identification, problem control and error control, plus workarounds and known errors.
- What it means
- Problem management has three phases. Problem identification finds problems through trend analysis of incidents, detection of duplicate and recurring issues, major incident handling, and information from suppliers, developers and testers. Problem control analyses problems and documents workarounds and known errors, prioritizing by risk. Error control manages known errors, identifies potential permanent solutions and regularly reassesses known errors that are not resolved.
- What to understand
- Problems relate to incidents but are distinct: incident management restores service, while problem management deals with causes. A workaround is a solution that reduces or eliminates the impact of an incident or problem for which a full resolution is not yet available; workarounds are documented in problem records and may be used repeatedly. Some problems are accepted as known errors without a permanent fix when the cost or risk outweighs the benefit. Implementing a permanent solution usually goes through change enablement. Problem management also links to risk management, knowledge management and continual improvement, because problem analysis can identify improvement opportunities.
- How it shows up
- Identifying the phase described in a scenario, or choosing correct statements about workarounds and known errors.
- Common confusion
- Placing workaround documentation in error control; documenting workarounds and known errors is part of problem control.
7.1.5 Service request managementTypes of service requests and the recommendations for handling them.
- What it means
- A service request is a request from a user or a user's representative that initiates a service action agreed as a normal part of service delivery. It is not a failure or degradation. Requests include service delivery actions such as replacing a toner cartridge, requests for information, provision of a resource or service such as a laptop, access to a resource, and feedback, compliments and complaints.
- What to understand
- Requests are predefined and pre-agreed, so they can be standardized and automated to the greatest possible degree. Policies should establish which requests can be fulfilled with limited or no extra approvals so fulfilment can be streamlined. User expectations about fulfilment times should be clearly set, based on what the organization can realistically deliver. Improvement opportunities should be identified and applied to produce faster fulfilment. Some requests are simple and fully automated; others are complex and need workflows that may involve several teams. Where possible, new request types should reuse existing workflows. Some requests are handled as standard changes.
- How it shows up
- Classifying an item as a service request, incident or change, or choosing correct handling guidance.
- Common confusion
- Classifying a password reset or new laptop as an incident because the user cannot work; these are predefined requests.
7.1.6 Service deskRole, channels, virtual desks, supporting technology and the skills that matter.
- What it means
- The service desk is the entry point and single point of contact for the service provider with all of its users. It captures demand for incident resolution and service requests. ITIL 4 emphasises understanding and empathy: the desk should understand the wider organization, the business processes and the users, and deliver a good experience rather than only logging tickets.
- What to understand
- Channels include phone, service portals and mobile apps, live chat and chatbots, email, walk-in desks, text and social media messaging, and discussion forums. A virtual service desk lets agents work from multiple locations, coordinated through supporting technology. Useful tools include intelligent telephony, workflow management and routing, knowledge bases, call recording, remote access, dashboards and monitoring, and configuration management systems. Key skills are customer service, empathy, incident analysis and prioritization, effective communication and emotional intelligence. Automation can handle routine work, freeing staff to focus on customer experience when personal contact is needed.
- How it shows up
- Statements about the desk's role, channels, virtual desks or the skills and tools it needs.
- Common confusion
- Assuming the service desk must resolve every incident itself; it captures demand and coordinates with support teams.
7.1.7 Service level managementBusiness-based service levels, SLA requirements, the watermelon effect and sources of information.
- What it means
- Service level management sets clear business-based targets for service levels and ensures delivery is assessed, monitored and managed against them. A service level agreement is a documented agreement between a provider and a customer that identifies services required and the expected level of service. ITIL lists requirements for successful SLAs: they relate to a defined service in the service catalogue, relate to defined outcomes rather than only operational metrics, reflect agreement between provider and consumer, and are simply written and easy to understand.
- What to understand
- SLAs based only on operational metrics can show green while customers are dissatisfied, the so-called watermelon effect, green on the outside and red on the inside. To avoid this, service level management gathers information from customer engagement, such as initial listening and discovery discussions, customer feedback through surveys and business-related measures, operational metrics, and business metrics tied to business activities. Skills needed include relationship management, business liaison, business analysis and commercial or supplier management. The practice provides end-to-end visibility of services.
- How it shows up
- Statements about SLA requirements, sources of information or the watermelon effect.
- Common confusion
- Treating an SLA as acceptable if all operational targets are met, regardless of customer experience.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Continual improvement model
Vision, where are we now, where do we want to be, how do we get there, take action, did we get there, keep momentum.
- Remember
- Seven steps, applied flexibly.
- Tested as
- Next-step questions.
- Trap
- Skipping the measurement of the current state.
-
Continual improvement register
A record used to track and manage improvement ideas from identification to action.
- Remember
- Ideas are captured, prioritized and managed there.
- Tested as
- Statements about tracking improvements.
- Trap
- Thinking only one central team may add ideas.
-
Standard change
Low risk, pre-authorized, well understood, fully documented.
- Remember
- Risk assessed when the procedure is created.
- Tested as
- Change classification.
- Trap
- Requiring authorization each time.
-
Normal change
Scheduled, assessed and authorized following a process.
- Remember
- Authority varies with the type and risk.
- Tested as
- Change classification.
- Trap
- Assuming every normal change goes to a board.
-
Emergency change
Must be implemented as soon as possible.
- Remember
- Expedited authorization, possibly reduced testing and deferred documentation.
- Tested as
- Change classification and handling.
- Trap
- Thinking authorization is skipped.
-
Change schedule
Plans changes, helps communication, avoids conflicts and assigns resources.
- Remember
- Also supports incident and problem management.
- Tested as
- Statements about change schedule use.
- Trap
- Thinking it only lists approved changes for audit.
-
Incident prioritization
Agreed classification based on impact and urgency.
- Remember
- Highest business impact first.
- Tested as
- Prioritization scenarios.
- Trap
- Using first come, first served.
-
Swarming
Many people collaborate on a complex incident until the right owner is clear.
- Remember
- Useful for complex or unclear incidents.
- Tested as
- Incident handling statements.
- Trap
- Thinking it replaces normal escalation for all incidents.
-
Problem phases
Problem identification, problem control, error control.
- Remember
- Workarounds and known errors are documented in problem control.
- Tested as
- Phase identification.
- Trap
- Assigning workaround documentation to error control.
-
Workaround
Reduces or eliminates the impact of an incident or problem without a full resolution.
- Remember
- Documented in problem records, can be reused.
- Tested as
- Problem management statements.
- Trap
- Treating a workaround as a permanent fix.
-
Service request
A user request for a predefined, agreed service action that is part of normal delivery.
- Remember
- Not a failure or degradation.
- Tested as
- Classify request versus incident.
- Trap
- Calling a new laptop request an incident.
-
Service desk channels
Phone, portals and apps, chat and chatbots, email, walk-in, text, social media, forums.
- Remember
- Many channels, one point of contact.
- Tested as
- Statements about service desk design.
- Trap
- Thinking a desk must be in one physical location.
-
Watermelon effect
SLAs show green metrics while customers are dissatisfied.
- Remember
- Avoid it with outcome-based measures and feedback.
- Tested as
- Service level management statements.
- Trap
- Trusting operational metrics alone.
-
SLA requirements
Related to a defined service, defined outcomes, real agreement, and simple language.
- Remember
- Outcomes, not just operational metrics.
- Tested as
- Choosing a correct SLA statement.
- Trap
- Writing SLAs in technical jargon.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Three types of change
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Standard | Low risk and pre-authorized | No individual authorization each time | Thought to need approval every time |
| Normal | Assessed and authorized through the process | Authority set by type and risk | Assumed always to need a board |
| Emergency | Must be done as soon as possible | Expedited assessment and authorization | Thought to skip authorization |
Three phases of problem management
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Problem identification | Finding problems from trends, recurrence and other sources | Discovering that a problem exists | Confused with logging incidents |
| Problem control | Analysing problems and documenting workarounds and known errors | Understanding the cause | Workarounds placed in error control |
| Error control | Managing known errors and potential permanent solutions | Moving toward a fix | Assumed always to end in a fix |
Incident, service request or change
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Incident | Unplanned interruption or reduced quality | Something has gone wrong | Calling a request an incident |
| Service request | Predefined user request that is part of normal delivery | Nothing has failed | Treating it as a failure |
| Standard change | Pre-authorized low-risk change, often raised as a request | Alters something that affects services | Thinking it needs separate approval |
SLA information sources
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Customer engagement | Listening and discovery discussions | Understanding needs early | Skipped in favour of metrics |
| Customer feedback | Surveys and business-related measures | Captures perceived experience | Treated as optional |
| Operational and business metrics | Technical measures and business activity measures | Need linking to outcomes | Relied on alone |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Emergency means no approval
- What candidates pick
- An option saying emergency changes need no authorization.
- Why it looks right
- Speed seems to rule out approval.
- Why it's wrong
- Emergency changes are still assessed and authorized, but the process is expedited and may use a separate change authority.
Clue to watch for Statements about authorization of urgent changes.
-
Everything to the board
- What candidates pick
- Sending every normal change to a central change board.
- Why it looks right
- Boards are familiar from older practice.
- Why it's wrong
- The change authority depends on type and risk, and low-risk normal changes can be authorized quickly or by peer review.
Clue to watch for Mentions of low-risk normal changes or decentralized authority.
-
First come, first served
- What candidates pick
- Resolving incidents in the order they are logged.
- Why it looks right
- It seems fair.
- Why it's wrong
- Incidents are prioritized using an agreed classification based on impact and urgency.
Clue to watch for Several incidents with different business impact.
-
Problem equals major incident
- What candidates pick
- Problem management for restoring a large outage quickly.
- Why it looks right
- Large incidents feel like problems.
- Why it's wrong
- Restoring service is incident management; problem management investigates causes to reduce future incidents.
Clue to watch for The focus is on getting service back now.
-
Request as incident
- What candidates pick
- Logging a request for software access as an incident.
- Why it looks right
- The user cannot do something they need.
- Why it's wrong
- A predefined, agreed request for access is a service request, not an interruption or degradation.
Clue to watch for Nothing is broken; the user wants something new.
-
Green SLA, happy customer
- What candidates pick
- An answer concluding a service is fine because every SLA target is met.
- Why it looks right
- Metrics look objective.
- Why it's wrong
- The watermelon effect shows metrics can be green while customers are unhappy; outcome-based measures and feedback are needed.
Clue to watch for Complaints despite met targets.
-
Improvement belongs to one team
- What candidates pick
- An option saying continual improvement is solely the job of a specialist team.
- Why it looks right
- Many organizations have such a team.
- Why it's wrong
- ITIL says continual improvement is everyone's responsibility, even if a team leads and coordinates.
Clue to watch for Statements about who is responsible.
Answer framework
Use this sequence for any scenario in this outcome, starting by identifying which of the seven practices the stem is really about.
- Name the practice: is the stem about improving, changing, restoring, investigating causes, fulfilling requests, user contact or service targets?
- Classify the item: incident or request, standard, normal or emergency change, or which problem phase or improvement model step applies.
- Recall the key guidance for that practice, such as impact and urgency for incidents or outcome-based measures for service levels.
- Check the qualifiers in the stem, such as best, first, should or not, and eliminate options that conflict with ITIL recommendations.
- Choose the option that reflects modern ITIL 4 thinking, such as decentralized change authority, empathy at the service desk and shared responsibility for improvement.
Practice question
Want more like this? The ITIL 4 Foundation practice test has questions for every domain.
Checklist
0 of 14
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Give this outcome at least a third of your total study time. Work through the seven practices one at a time, and for each build a single page with three sections: the key concepts, the recommended ways of working, and the traps listed on this page. Continual improvement, change enablement and problem management have the most structure, so learn their lists first: the seven model steps, three change types and three problem phases.
Then practise classification, which drives many questions. Write twenty short cases, such as a password reset, a disk failure, a vendor patch, a recurring error or a slow application, and decide for each whether it is an incident, a service request, a problem or a type of change. Explain each choice in one sentence.
Finally, do full sets of scenario questions on these practices only, about twenty at a time. When you miss one, note the guidance you forgot and add it to the practice page. Review the pages again in the final days before the exam.
FAQ
How much of the exam is Seven ITIL Practices in Detail?
Seven ITIL Practices in Detail, learning outcome 7, carries 17 of the 40 marks, which is 42.5%, the largest share of the paper.
Which seven practices are covered?
Continual improvement with the continual improvement model, change enablement, incident management, problem management, service request management, service desk and service level management.
Do I need to know how these practices fit the value chain?
No. The syllabus explicitly excludes how these practices fit within the service value chain from this learning outcome.
Do emergency changes need authorization?
Yes. Emergency changes are still assessed and authorized, but in an expedited way, sometimes by a separate change authority, and documentation may be completed afterwards.
What is the difference between a workaround and a known error?
A workaround reduces or removes the impact of an incident or problem without a full fix. A known error is a problem that has been analysed but not resolved, and it often has a documented workaround.
What is the watermelon effect?
It describes SLAs whose metrics are all green while customers are unhappy. Service level management avoids it by using outcome-based measures and customer feedback alongside operational metrics.
How should I split study time across the seven practices?
Give extra time to change enablement, problem management and continual improvement because they have the most structured content, but do not skip the service desk or service request management, which yield easy marks.
Other Enterprise Architecture & IT Governance certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 7 knowledge
Practise scenario questions across all seven practices, especially change types, problem phases and the continual improvement model, under timed conditions.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the ITIL 4 Foundation AI tutor Get any concept explained your way