ITIL 4 SRM common mistakes
ITIL 4 SRM · Understand the traps and how to avoid them.
Treating Service Request Management as a synonym for Incident Management and answering questions about 'restoring service quickly' as if they belong to the request practice.
The two practices share a front door (the service desk) and both use the same tooling, so candidates carry over incident reflexes and miss the defining distinction: a request is a user-initiated, pre-approved, normal part of service delivery, while an incident is an unplanned interruption or degradation.
What to do instead
Before answering, classify the scenario: is something broken or degraded (incident), or is the user asking for something that is a standard, pre-agreed part of service delivery (request)? Memorise the definitional contrast and the 'pre-approved / no additional approval needed' test, then check whether the question hinges on restoration versus fulfilment.
Assuming every service request must go through a formal approval step, and selecting an approval workflow for a request that is already a standard, pre-authorised offering.
Candidates generalise from change management, where authorisation is central, and from the few request types that do need financial or line-manager approval (e.g. a high-value purchase). They then apply authorisation to catalogue items that are deliberately pre-approved so they can be fulfilled without friction.
What to do instead
Learn that pre-approval is baked into the definition of a standard service request; approval is the exception, triggered by cost, risk, or policy thresholds. When a question mentions a catalogue item with a fixed price and a defined fulfilment workflow, default to 'no additional approval' unless the stem introduces a threshold or an exception.
Describing the request fulfilment value stream as a single 'log and resolve' step, omitting the design-time activities that make fulfilment possible (catalogue design, request model definition, workflow automation, and periodic review).
Exam questions often show only the run-time flow, so candidates memorise 'submit, approve, fulfil, close' and forget that the practice also owns building and maintaining the request models and catalogue entries that the run-time flow consumes.
What to do instead
Build a two-layer mental model: a design/maintain layer (define request models, publish catalogue items, automate workflows, review usage) and a run-time layer (submit, validate, authorise if needed, fulfil, confirm, close). When a question asks where a practice activity sits in the value chain, check both layers before choosing.
Skipping the confirmation and closure step in scenario questions, treating 'fulfilled' as the end of the request, and missing questions about user confirmation, feedback capture, and updating records.
Fulfilment feels like the natural finish line, and in real desks closure is often automated or rushed, so candidates do not associate value with the final step. They then fail items that test whether the user's need was actually met and whether the record was completed.
What to do instead
Treat closure as a distinct activity with its own purpose: confirm the outcome meets the user's need, capture feedback, update the request record and knowledge, and close. In any scenario asking 'what should happen next' after delivery, consider confirmation and closure before considering escalation.
Confusing the roles of the service desk agent, the request fulfiller, and the request approver, and assigning all three accountabilities to one person in role-based questions.
In small organisations one person really does all three, so candidates answer from personal experience rather than from the practice's role model. Exam stems often deliberately describe a separation of duties to test whether the candidate can distinguish who does what.
What to do instead
Learn the roles by their output: the service desk captures and validates the request and keeps the user informed; the fulfiller performs the work and records the outcome; the approver authorises only where policy requires. Where the stem shows separation, map each actor to the output they produce, not to the job title.
Ignoring the competencies the practice needs beyond technical skill, such as empathy, clear communication, and the ability to script and maintain request models, and choosing 'technical expertise' as the answer to every people-related question.
Candidates equate service quality with technical capability, and the practice's people dimension is under-studied relative to its process steps. Questions on user experience, handling vulnerable users, or writing self-service content then feel unfamiliar.
What to do instead
Prepare a short list of practice competencies: customer empathy and communication, request model and workflow design, catalogue and knowledge authoring, data analysis for demand patterns, and automation literacy. Match the competency to the scenario's demand (a frustrated user needs empathy; a rising request volume needs analysis and automation).
Treating Service Request Management in isolation and failing to link it to the practices it depends on, such as Service Catalogue Management, Service Level Management, Knowledge Management, and Service Desk.
The exam's framework domain asks relationship questions, but candidates revise each practice as a standalone chapter and cannot answer 'which practice must be in place for this to work'. They then pick a plausible-sounding but unrelated practice.
What to do instead
For each dependency, memorise a one-line contract: Service Catalogue Management defines what can be requested; Service Level Management sets expectations and targets; Knowledge Management supplies the articles and scripts; Service Desk is the primary capture channel; Change Enablement governs changes needed to build or alter request models. Answer relationship questions by asking which practice supplies the missing input.
Answering governance questions by placing accountability for service requests with the service desk manager or the practice owner, rather than with the governing body that sets direction and the accountabilities that authorise the practice.
Operational experience makes the desk manager feel like the owner of everything request-related, and the distinction between governance (direction, oversight, accountability) and management (execution) is easy to blur under exam pressure.
What to do instead
Separate the two: governance sets policy, risk appetite, and the boundaries within which requests are pre-approved; management runs the practice within those boundaries. When a stem asks who authorises a policy change, a new catalogue category, or an exception to approval thresholds, look upward to the governing body, not sideways to the desk.
Choosing volume-based metrics alone (number of requests logged, average handling time) as evidence of practice success, and rejecting outcome or experience measures in metric-selection questions.
Volume and speed are the easiest numbers to obtain from a ticketing tool, so candidates default to them. They miss that the practice's purpose is fulfilled user needs, so measures of first-time-right, user satisfaction, and catalogue coverage matter more.
What to do instead
Classify candidate metrics before choosing: demand (volume, mix), efficiency (handling time, automation rate), effectiveness (first-time-right, fulfilment within target), and experience (satisfaction, feedback). When a question asks what best demonstrates value, prefer effectiveness and experience measures over raw volume, and be ready to pair a leading indicator with a lagging one.
Treating continual improvement as a periodic review project and missing the day-to-day improvement loop, such as analysing request trends, retiring low-value catalogue items, and automating high-volume requests.
Improvement is taught as a formal lifecycle stage, so candidates picture a quarterly review and overlook that the practice improves continuously through demand analysis and incremental automation of the request portfolio.
What to do instead
Frame improvement as a routine: review request data for patterns, identify candidates for self-service or automation, simplify or retire catalogue items nobody uses, and feed findings into the improvement register. In questions about reducing demand or cost, prefer structural changes to the request portfolio over working faster on the same requests.
Underestimating the organisational change side of adopting the practice, and answering transformation questions with tooling or process redesign alone while ignoring communication, training, and resistance management.
Candidates associate capability development with implementing a tool and publishing a catalogue, because those are visible deliverables. The people side, including changing user behaviour toward self-service and upskilling desk staff, is less concrete and therefore under-weighted.
What to do instead
For any adoption or capability question, check three fronts: process and tooling, people (skills, roles, incentives), and stakeholders (communication, sponsorship, user habits). If the stem describes low self-service uptake or staff resistance, choose the answer that addresses behaviour and capability, not the one that adds features.