Service Request Management practice fundamentals and key concepts
Domain 1: Service Request Management fundamentals and key concepts
This domain tests whether you can define a service request, separate it from an incident, and explain the catalogue and request-model mechanics that make fulfilment repeatable.
Core rules
- A service request is a user-initiated request for something that is agreed as a normal part of service delivery-for example information, access, advice, a standard service, or a pre-authorized standard change.
- The practice purpose is to support agreed service quality by handling pre-defined, user-initiated requests effectively and in a user-friendly way.
- A service catalogue describes available services; a request catalogue is the requestable subset, with items, options, approvals, and fulfilment details.
- A request model defines who may request, what information is needed, approval and authorization rules, fulfilment steps, target times, and escalation.
- Standard changes are pre-authorized, low-risk changes; a request for one still follows the request model and change enablement rules.
- Requests are planned; incidents are unplanned interruptions or degradation. A failed fulfilment can create an incident, but that does not make the original request an incident.
Worked example
An employee asks for access to a finance application. It is planned, repeatable, and offered as a catalogue item, so it is a request. The request model requires line-manager approval and application-owner approval, then fulfilment by the identity team. Because the access grant is pre-authorized and low risk, it is not treated as a normal change. If the application is down and the employee cannot work, that is an incident; the access request remains a request.
Traps that cost marks
- Calling every ticket an incident, or every request a change.
- Confusing the request catalogue with the full service catalogue.
- Skipping approval because fulfilment is “simple”.
- Forgetting that requests must be agreed as normal service delivery, not ad hoc favours.
- Assuming a request model is only a workflow diagram; it also covers authorization, targets, and escalation.