Monitor, Support and Fulfil
What this domain tests
The Monitor, Support and Fulfil domain tests how ITIL 4 practices convert signals and user contacts into restored or delivered services. Questions target the service desk, incident management, service request management, problem management, service level management, and monitoring and event management, plus how these practices interact inside value streams.
Core rules and concepts
- Monitoring observes services and components and generates events; an event is a meaningful change of state. Not every event is an incident, so correlation, filtering, and thresholds matter.
- An incident is an unplanned interruption or degradation of a service. Priority combines impact and urgency; severity describes the technical effect, not business priority.
- A service request is a predefined, low-risk request such as access, information, or a standard change. It follows request models, not incident workflows.
- A problem is the underlying cause of one or more incidents. A workaround restores service; a known error records a documented root cause and workaround.
- The service desk is the single point of contact, owning logging, classification, first-line resolution, and user communication.
- Service level management sets customer agreements; OLAs and underpinning contracts support them, and measurement should be end-to-end.
Worked example
Payroll users cannot log in after an overnight patch. The service desk logs an incident; impact is high because of the payroll cut-off and urgency is high, so priority is P1. Monitoring shows an authentication error spike and the event is correlated to the incident. First-line applies a documented workaround, service is restored, and the incident is closed after user confirmation. When 30 users report the same issue, a problem record is raised; root cause is a patch conflict, a known error is created, and a change is scheduled. SLM reports the outage against the availability target.
Traps that cost marks
- Treating a service request as an incident, or the reverse.
- Setting priority from severity alone instead of impact and urgency.
- Closing on technical fix without user confirmation.
- Raising a problem for every incident rather than when cause is unknown and impact justifies it.
- Ignoring alert noise and event correlation.
- Quoting SLM targets without the OLAs and contracts that underpin them.