Objective: ITIL Request Fulfilment aims to fulfill Service Requests, which in most cases are minor (standard) Changes - e.g. requests to change a password or requests for information.
Part of: Service Operation
Process Owner: Incident Manager
Request Fulfilment has been added as a new process to ITIL V3 with the aim to have a specific process dealing with Service Requests.
This was motivated by a clear distinction in ITIL V3 between Incidents (Service Interruptions) and Service Requests (standard requests from users, such as password resets).
In ITIL 2011, Request Fulfilment has been completely revised.
Request Fulfilment now consists of five sub-processes, to provide a detailed description of all activities and decision points.
The process contains interfaces
- with Incident Management - if a Service Request turns out to be an Incident and
- with Service Transition - if fulfilling a Service Request requires the involvement of Change Management. The process overview of ITIL Request Fulfilment shows the key information flows (see fig. 1).
A clearer explanation of the information that describes a Service Request and its life cycle has been added. Furthermore, the concept of Service Request Models is explained in more detail.
ITIL 4 refers to Request Fulfilment as a service management practice, and has renamed the practice to "Service request management". The service desk activities are described in the ITIL4 practice of "Service desk".
These are the ITIL Request Fulfilment sub-processes and their process objectives:
Request Fulfilment Support
- Process Objective: To provide and maintain the tools, processes, skills and rules for an effective and efficient handling of Service Requests.
Request Logging and Categorization
- Process Objective: To record and categorize the Service Request with appropriate diligence and check the requester's authorization to submit the request, in order to facilitate a swift and effective processing.
Request Model Execution
- Process Objective: To process a Service Request within the agreed time schedule.
Request Monitoring and Escalation
- Process Objective: To continuously monitor the processing status of outstanding Service Requests, so that counter-measures may be introduced as soon as possible if service levels are likely to be breached.
Request Closure and Evaluation
- Process Objective: To submit the Request Record to a final quality control before it is closed. The aim is to make sure that the Service Request is actually processed and that all information required to describe the request's life-cycle is supplied in sufficient detail. In addition to this, findings from the processing of the request are to be recorded for future use.
The following ITIL terms and acronyms (information objects) are used in the Request Fulfilment process to represent process outputs and inputs:
Request for Service
- A formal request from a user for something to be provided – for example, a request for information or advice; to reset a password; or to install a workstation for a new user. The details of a Request for Service are recorded by Request Fulfilment in a Service Request Record.
Service Request Model
- A (Service) Request Model defines specific agreed steps that will be followed for a Service Request of a particular type (or category).
Service Request Record
- A record containing all details of a Service Request. Service Requests are formal requests from a user for something to be provided – for example, a request for information or advice; to reset a password; or to install a workstation for a new user.
Service Request Status Information
- A message containing the present status of a Service Request sent to a user who earlier reported requested a service. Status information is typically provided to users at various points during a Service Request's lifecycle.
Roles | Responsibilities
Incident Manager - Process Owner
- The Incident Manager is responsible for the effective implementation of the Incident Management process and carries out the respective reporting. He represents the first stage of escalation for Incidents, should these not be resolvable within the agreed Service Levels.
1st Level Support
- The responsibility of 1st Level Support is to register and classify received Incidents and to undertake an immediate effort in order to restore a failed IT service as quickly as possible. If no ad-hoc solution can be achieved, 1st Level Support will transfer the Incident to expert technical support groups (2nd Level Support). 1st Level Support also processes Service Requests and keeps users informed about their Incidents' status at agreed intervals.
Service Request Fulfilment Group
- Service Request Fulfilment Groups specialize on the fulfilment of certain types of Service Requests. Typically, 1st Level Support will process simpler requests, while others are forwarded to the specialized Fulfilment Groups.
|ITIL Role / Sub-Process||Incident Manager||1st Level Support||Service Request Fulfilment Group|
|Request Fulfilment Support||AR|
|Request Logging and Categorization||A||R||-|
|Request Model Execution||A||R||R|
|Request Monitoring and Escalation||AR||R||-|
|Request Closure and Evaluation||A||R||-|
 A: Accountable according to the RACI Model: Those who are ultimately accountable for the correct and thorough completion of the Request Fulfilment process.
 R: Responsible according to the RACI Model: Those who do the work to achieve a task within Request Fulfilment.
By: Stefan Kempter , IT Process Maps.
Process Description › Sub-Processes › Definitions › Roles