ITIL 4 SRM key terms

A user's request for something to be provided, such as information, advice, a standard change, access to a service, or a routine service action. It is normally handled through a predefined, low-risk workflow rather than full incident or change management.

A predefined template describing the steps, approvals, roles, and target times needed to fulfil a particular type of service request. Models make routine fulfilment repeatable, auditable, and consistent across users and locations.

The ITIL 4 practice that supports the agreed quality of a service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner. It owns request models, fulfilment coordination, and request-related reporting.

A single entry in the request catalogue describing something a user may request, including what it is, who may request it, what it costs, and how long fulfilment normally takes. Each item is backed by one or more request models.

The user-facing collection of requestable items published from the service catalogue, presented in business language with eligibility, pricing, and expected lead times. It hides internal fulfilment complexity and supports self-service ordering.

A structured view of services offered to consumers, showing what each service does, who it serves, and how to obtain it. It is the authoritative source from which requestable items and service request models are derived.

A low-risk, pre-authorised change with a documented procedure that is repeated routinely. Many standard changes are delivered as service requests, which is why request models and change enablement must agree on where the boundary lies.

The defined sequence of activities, decision points, and handoffs that moves a request from submission to closure. Good workflows automate approvals and routing so that fulfilments proceed without manual chasing.

A formal decision by an authorised person or group that a request may proceed, often based on cost, risk, or policy. Approvals should be embedded in the request model so that they are triggered automatically rather than requested ad hoc.

Permission given to a role or team to approve certain requests without escalating to higher management, bounded by value or risk thresholds. Clear delegation removes bottlenecks while keeping spending and risk within governance limits.

The end-to-end activity of delivering what a service request asks for, including any provisioning, configuration, procurement, or scheduling work. Fulfilment is often performed by specialist teams rather than the service desk itself.

The group with the technical or administrative capability to deliver a specific request type, such as identity administrators, workplace engineers, or procurement staff. Request models must name the fulfilment team and the handoff conditions for each item.

The single point of contact between users and the service provider for incidents, service requests, and communication. For request management it acts as the entry point, triage function, and owner of the user experience throughout fulfilment.

A channel or team through which users raise all contact with the provider, avoiding the need to hunt for the right department. It simplifies request intake but requires reliable routing and visibility into fulfilment progress.

A user-facing interface where people browse the request catalogue, submit requests, track status, and receive results. Effective portals reduce contact volume and errors, but only if the catalogue is understandable and the workflows behind it work.

An approach where users contact the provider through any channel they prefer while the request record and history remain consistent across all channels. It prevents duplicated requests and lost context when users switch between chat, email, and phone.

The initial assessment of a submitted request to confirm it is valid, correctly classified, and routed to the right model and fulfilment team. Good triage prevents misrouted work and catches requests that should actually be incidents or changes.

An unplanned interruption to, or reduction in the quality of, a service. Distinguishing incidents from service requests matters because incidents follow restoration-focused processes while requests follow predefined fulfilment models.

The practice that minimises the negative impact of incidents by restoring normal service operation as quickly as possible. It shares intake channels with request management, so clear classification rules between the two are essential.

The practice ensuring that risks are properly assessed and that changes are authorised and scheduled appropriately. It sets the boundary that determines which requests can be handled as standard changes and which need formal change control.

A documented agreement between a provider and a customer that identifies required services and expected service levels. Request models should carry response and fulfilment targets that are consistent with the relevant agreement.

The elapsed time between a request being received and the first meaningful action or reply to the user, such as acknowledgement or triage. It measures responsiveness rather than the time taken to deliver the requested item.

The elapsed time from an accepted request to delivery and closure, covering all internal steps and waits. It is the measure users care about most and should be reported by request type rather than as a single average.

The total time from a user first expressing a need to receiving the outcome, including any waiting before the request is formally raised. Reducing lead time often requires catalogue clarity and fewer approval steps, not faster technical work.

A defined quantitative measure used to judge whether request handling is performing as intended, such as volume, first-time-right rate, or cost per request. Metrics should be few, tied to a decision, and balanced against user experience data.

A metric chosen because it indicates whether an important objective is being achieved, and which triggers action when it drifts. Effective request KPIs combine speed, quality, and user satisfaction rather than volume alone.

The proportion of requests completed correctly without rework, rejection, or reopening. It reveals defects in request models, catalogue descriptions, or approval rules and is a strong indicator of hidden waste.

Effort spent redoing a request because it was rejected, incorrectly submitted, or fulfilled wrongly. Tracking rework by request type shows where catalogue wording or workflow design is failing users.

Using technology to perform request steps such as form validation, routing, approval, and provisioning without manual intervention. It improves consistency and speed but requires stable, well-defined request models to be worthwhile.

The ongoing practice of identifying and acting on opportunities to improve products, services, and practices. In request management it uses trend data, user feedback, and rework analysis to refine models and retire low-value items.

The series of steps an organisation uses to create and deliver value to a consumer, viewed end to end. Mapping the request value stream exposes delays, duplicate approvals, and handoffs that no single team controls.

A set of responsibilities assigned to a person or team within a practice or process, independent of job title. Request management typically defines request owner, approver, fulfilment team member, and service desk agent roles.

The person accountable for a request's progress, quality, and communication until it is closed, even when other teams perform the work. Ownership prevents requests from stalling between handoffs and gives the user a named contact.

Transferring a request to a higher level of authority or capability because it is at risk, blocked, or beyond the current team's remit. Functional escalation adds skills; hierarchical escalation adds decision-making authority.

The combination of knowledge, skills, and behaviour a person needs to perform a role well. Request staff need catalogue knowledge, empathy, and process discipline; fulfilment staff need accurate technical and record-keeping habits.

The organisation's combined ability to perform an activity, built from people, processes, technology, information, and partners. Strong request capability means predictable fulfilment, clear catalogues, and reliable measurement rather than heroic effort.

The structured approach to helping people adopt new ways of working, addressing awareness, desire, knowledge, ability, and reinforcement. Introducing self-service or new request models fails without deliberate attention to these human factors.

Identifying the people affected by or influencing a change and communicating with them in ways that build support. For request management this includes users, approvers, fulfilment teams, and senior sponsors of the catalogue.

Planned learning activity that builds the knowledge and skills people need for their roles. Request initiatives need training for users on how to order, for approvers on delegation, and for fulfilment teams on new workflows.

The means by which an organisation is directed and controlled, including decision rights, policy, and oversight. Request management operates within governance limits that set approval thresholds, risk appetite, and reporting expectations.