ITIL 4 SRM cheat sheet

A service request is a user-initiated request for something the service provider already offers and has pre-approved: information, a standard change, access, a routine action, or a service delivery item.

Practice definition: Service Request Management supports the agreed quality of a service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner.

Decision rule: if the request is not pre-approved and requires assessment/authorization beyond the agreed authorization model, it is not a service request - route it to incident, change enablement, or problem management.

Key inputs: requestor identity and entitlement, request catalogue item definition, agreed service levels, and any prerequisite approvals defined in the catalogue entry.

Key outputs: fulfilled request, updated records (request, CMDB/asset, licence/entitlement), audit trail, and satisfaction/feedback data.

Service request vs incident: an incident is an unplanned interruption or degradation; a service request is planned and normal. A failed request fulfilment can, however, cause an incident.

Service request vs standard change: a standard change is a low-risk pre-authorized change; many service requests trigger a standard change, but the request itself is the user-facing demand.

Catalogue item anatomy: description, eligibility/entitlement, price or chargeback, fulfilment steps and owner, target times, approval rules, and escalation path.

Terminology: request model (a repeatable, pre-defined way to handle a type of request) versus request instance (a single ticket).

Reference value stream steps: engage (submit/acknowledge) → request logged and identified → entitlement and approval check → fulfilment (automated or human) → verification and closure → feedback and continual improvement.

Decision rule at triage: if the catalogue item exists and the requestor is entitled and no further approval is required, automate or route directly to fulfilment; otherwise route to approval or reject with a reason.

Workflow states typically include: submitted, logged, awaiting approval, in fulfilment, awaiting user, fulfilled, closed, cancelled, rejected.

Approval design rule: only include an approval step where a real control objective exists (cost threshold, risk, segregation of duties); every approval adds lead time.

Automation rule: automate high-volume, low-variation, low-risk items first; keep human handling for exceptions and judgement-based items.

Roles: requestor (submits and confirms), service desk agent (logs, triages, communicates), fulfilment group/technical team (performs the work), request approver (authorizes), service request manager/owner (designs models, owns catalogue quality and performance).

Competencies: catalogue and workflow design, automation/tooling skills, clear written communication, empathy for user experience, and data literacy for measuring flow.

Handling rule: if fulfilment cannot be completed within the agreed time, proactively communicate and escalate rather than silently letting the target lapse.

Closure rule: confirm the user received the outcome and capture feedback; unconfirmed closure hides failed fulfilment and corrupts satisfaction data.

Service Request Management sits in the ITIL 4 service value chain: it mainly supports Engage, Obtain/Build (catalogue and automation), and Deliver & Support, with Plan and Improve feeding design and measurement.

Relationship to the Service Desk practice: the service desk is the main capture and communication channel; Service Request Management defines what happens after capture.

Relationship to Service Catalogue Management: the catalogue defines what can be requested and under what terms; a request cannot exist without a published catalogue entry.

Relationship to Change Enablement: service requests that produce a change must be pre-authorized as standard changes; otherwise a normal change is required.

Relationship to Incident Management: misrouted or misclassified requests create incidents; a broken fulfilment process is often managed as an incident or problem.

Relationship to Service Level Management: request targets (response, fulfilment time) must align with agreed SLAs and OLAs with fulfilment teams.

Relationship to IT Asset Management and Service Configuration Management: fulfilment updates asset/CI records (e.g., issued hardware, granted access).

Governance: the governing body sets policy on authorization thresholds, risk appetite, and reporting; practice owners translate policy into catalogue rules and controls.

Relationship to Supplier Management: outsourced fulfilment requires agreed targets and responsibilities documented in contracts and OLAs.

Metric families: volume/demand, timeliness, quality/first-time-right, user experience/satisfaction, cost/efficiency, and compliance/control.

Timeliness metrics: mean and percentile fulfilment time (e.g., P90), percentage fulfilled within target, approval wait time versus actual work time.

Quality metrics: first-time-right rate, rework/reopen rate, cancellation rate, and percentage of requests completed without manual intervention (automation rate).

Experience metrics: satisfaction score per catalogue item, complaint rate, and effort score (how hard it was for the user to get the outcome).

Efficiency metrics: cost per request, agent handle time, self-service adoption rate, and deflection rate from assisted channels.

Control metrics: percentage of requests with evidence of entitlement/approval, audit exceptions, and unauthorized fulfilment count.

Analysis rule: segment metrics by catalogue item, channel, and fulfilment team; a single blended average hides the items driving poor performance.

Improvement rule: prioritize by volume × pain (time, rework, dissatisfaction); automate or redesign the top few items rather than many small fixes.

Continual improvement loop: measure → identify constraint or defect → change catalogue/workflow/automation → re-measure and confirm the effect.

Shift-left principle: move fulfilment capability closer to the user (self-service, automation, first-line resolution) and reserve specialist teams for exceptions.

Adoption rule: a new portal or automation fails if catalogue items are hard to find or slower than emailing the desk; measure adoption and abandon rate, not just deployment.

Role change: agents move from ticket takers to advisors and exception handlers; this requires training in catalogue knowledge and communication.

Capability building sequence: define catalogue and ownership → standardize workflows → automate → measure → optimize.

Stakeholder management: fulfilment teams resist catalogue targets unless OLAs are agreed with them and their workload is visible.

Change resistance sources: fear of measurement, loss of informal control over queues, and unclear ownership of catalogue items.

Training needs: request model design, tooling/workflow configuration, data analysis, and user-experience thinking for service desk staff.

Governance for change: use the ITIL 4 'organizations and people', 'information and technology', 'partners and suppliers', and 'value streams and processes' dimensions to plan capability changes.

Success indicator: falling assisted-channel volume with stable or improving satisfaction indicates genuine capability growth, not just channel shifting.

A service request is a user-initiated request for something the service provider already offers and has pre-approved: information, a standard change, access, a routine action, or a service delivery item.

Practice definition: Service Request Management supports the agreed quality of a service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner.

Decision rule: if the request is not pre-approved and requires assessment/authorization beyond the agreed authorization model, it is not a service request - route it to incident, change enablement, or problem management.

Key inputs: requestor identity and entitlement, request catalogue item definition, agreed service levels, and any prerequisite approvals defined in the catalogue entry.

Key outputs: fulfilled request, updated records (request, CMDB/asset, licence/entitlement), audit trail, and satisfaction/feedback data.

Service request vs incident: an incident is an unplanned interruption or degradation; a service request is planned and normal. A failed request fulfilment can, however, cause an incident.

Service request vs standard change: a standard change is a low-risk pre-authorized change; many service requests trigger a standard change, but the request itself is the user-facing demand.

Catalogue item anatomy: description, eligibility/entitlement, price or chargeback, fulfilment steps and owner, target times, approval rules, and escalation path.

Terminology: request model (a repeatable, pre-defined way to handle a type of request) versus request instance (a single ticket).

Reference value stream steps: engage (submit/acknowledge) → request logged and identified → entitlement and approval check → fulfilment (automated or human) → verification and closure → feedback and continual improvement.

Decision rule at triage: if the catalogue item exists and the requestor is entitled and no further approval is required, automate or route directly to fulfilment; otherwise route to approval or reject with a reason.

Workflow states typically include: submitted, logged, awaiting approval, in fulfilment, awaiting user, fulfilled, closed, cancelled, rejected.

Approval design rule: only include an approval step where a real control objective exists (cost threshold, risk, segregation of duties); every approval adds lead time.

Automation rule: automate high-volume, low-variation, low-risk items first; keep human handling for exceptions and judgement-based items.

Roles: requestor (submits and confirms), service desk agent (logs, triages, communicates), fulfilment group/technical team (performs the work), request approver (authorizes), service request manager/owner (designs models, owns catalogue quality and performance).

Competencies: catalogue and workflow design, automation/tooling skills, clear written communication, empathy for user experience, and data literacy for measuring flow.

Handling rule: if fulfilment cannot be completed within the agreed time, proactively communicate and escalate rather than silently letting the target lapse.

Closure rule: confirm the user received the outcome and capture feedback; unconfirmed closure hides failed fulfilment and corrupts satisfaction data.

Service Request Management sits in the ITIL 4 service value chain: it mainly supports Engage, Obtain/Build (catalogue and automation), and Deliver & Support, with Plan and Improve feeding design and measurement.

Relationship to the Service Desk practice: the service desk is the main capture and communication channel; Service Request Management defines what happens after capture.

Relationship to Service Catalogue Management: the catalogue defines what can be requested and under what terms; a request cannot exist without a published catalogue entry.

Relationship to Change Enablement: service requests that produce a change must be pre-authorized as standard changes; otherwise a normal change is required.

Relationship to Incident Management: misrouted or misclassified requests create incidents; a broken fulfilment process is often managed as an incident or problem.

Relationship to Service Level Management: request targets (response, fulfilment time) must align with agreed SLAs and OLAs with fulfilment teams.

Relationship to IT Asset Management and Service Configuration Management: fulfilment updates asset/CI records (e.g., issued hardware, granted access).

Governance: the governing body sets policy on authorization thresholds, risk appetite, and reporting; practice owners translate policy into catalogue rules and controls.

Relationship to Supplier Management: outsourced fulfilment requires agreed targets and responsibilities documented in contracts and OLAs.

Metric families: volume/demand, timeliness, quality/first-time-right, user experience/satisfaction, cost/efficiency, and compliance/control.

Timeliness metrics: mean and percentile fulfilment time (e.g., P90), percentage fulfilled within target, approval wait time versus actual work time.

Quality metrics: first-time-right rate, rework/reopen rate, cancellation rate, and percentage of requests completed without manual intervention (automation rate).

Experience metrics: satisfaction score per catalogue item, complaint rate, and effort score (how hard it was for the user to get the outcome).

Efficiency metrics: cost per request, agent handle time, self-service adoption rate, and deflection rate from assisted channels.

Control metrics: percentage of requests with evidence of entitlement/approval, audit exceptions, and unauthorized fulfilment count.

Analysis rule: segment metrics by catalogue item, channel, and fulfilment team; a single blended average hides the items driving poor performance.

Improvement rule: prioritize by volume × pain (time, rework, dissatisfaction); automate or redesign the top few items rather than many small fixes.

Continual improvement loop: measure → identify constraint or defect → change catalogue/workflow/automation → re-measure and confirm the effect.

Shift-left principle: move fulfilment capability closer to the user (self-service, automation, first-line resolution) and reserve specialist teams for exceptions.

Adoption rule: a new portal or automation fails if catalogue items are hard to find or slower than emailing the desk; measure adoption and abandon rate, not just deployment.

Role change: agents move from ticket takers to advisors and exception handlers; this requires training in catalogue knowledge and communication.

Capability building sequence: define catalogue and ownership → standardize workflows → automate → measure → optimize.

Stakeholder management: fulfilment teams resist catalogue targets unless OLAs are agreed with them and their workload is visible.

Change resistance sources: fear of measurement, loss of informal control over queues, and unclear ownership of catalogue items.

Training needs: request model design, tooling/workflow configuration, data analysis, and user-experience thinking for service desk staff.

Governance for change: use the ITIL 4 'organizations and people', 'information and technology', 'partners and suppliers', and 'value streams and processes' dimensions to plan capability changes.

Success indicator: falling assisted-channel volume with stable or improving satisfaction indicates genuine capability growth, not just channel shifting.