Service Request Management in the context of the ITIL 4 framework (other practices and governance)
Domain 3: SRM in the ITIL 4 framework
This domain tests how service request management interfaces with other practices and with governance, and where accountability sits.
Core rules
- The service desk is the single point of contact; it often captures, validates, and coordinates requests, but fulfilment may sit elsewhere.
- Incident management handles unplanned interruptions; service request management handles planned, pre-defined requests. Keep the workflows distinct even if one tool supports both.
- Change enablement governs changes; standard changes are pre-authorized, so a request for a standard change can flow through a request model, while normal changes need change authority approval.
- Service catalogue management supplies the catalogue and request catalogue; service level management sets targets; knowledge management supplies guidance; service configuration management supplies accurate asset and configuration data.
- Information security and supplier management matter for access requests and third-party fulfilment.
- Governance sets approval matrices, segregation of duties, audit trails, risk appetite, financial delegation, and compliance. The practice owner is accountable for the practice; service owners are accountable for catalogue items and their models.
Worked example
A user requests software that is not in the request catalogue. The service desk must not fulfil it informally. The request is assessed; if it is a normal change, change enablement authorizes it. If approved and repeatable, the service owner adds it to the catalogue with a request model, approval rules, and target time. Governance is maintained because the exception was routed, recorded, and used to improve the catalogue rather than bypassing it.
Traps that cost marks
- Letting the service desk approve normal changes.
- Treating a standard change as a normal change, adding unnecessary delay.
- Bypassing information security for access requests.
- Assuming the service desk must fulfil everything it captures.
- Ignoring catalogue and configuration data quality; poor data breaks fulfilment.