What is ITIL?

ITIL is a set of best-practice publications for IT service management (ITSM). ITIL was initially developed by the UK Government’s Central Computer and Telecommunications Agency at the end of the 1980’s as an IT framework for use within British public sector organizations. This was soon adopted by both the UK public sector and some large global private sector organizations. The second version of ITIL, often referred to as Version 2, was published in 2001. The books covering Service Delivery and Service Support were rethought and redeveloped into more usable concise volumes. ITIL soon became the most widely used source of ITSM good practice worldwide in both the public and private sectors. In 2007 a new version of ITIL was published which adopted a lifecycle approach to ITSM. This version, sometimes called Version 3 (V3), introduced several new processes including request fulfilment. An updated version of ITIL was published in 2011. ITIL 2011 resolved errors and inconsistencies in the text and diagrams across the whole suite of publications. A new version of ITIL that will be known as ITIL V4 will be published in 2019.  

ITIL gives guidance on the provision of quality IT services and the processes, functions and other capabilities needed to support them. The ITIL framework is based on a service lifecycle and consists of five lifecycle stages (service strategy, service design, service transition, service operation and continual service improvement), each of which has its own supporting publication. There is also a set of complementary ITIL publications providing guidance specific to industry sectors, organization types, operating models and technology architectures.

 

What is a request?

A request is a formal request from a user for something to be provided. ITIL also uses the term service request for a request managed under ITSM. The details of a service request are recorded by request fulfilment in a service request record. Service requests are often sent to the service desk, but can be routed directly to the team responsible for fulfilling the request. Sometimes this routing of a service request for subsequent fulfilment is achieved by using service request software. Service requests are usually directed to IT, but a service request can also be a request to ask the service desk to do something or to ask other parts of the business to provide something, including human resources and procurement.  Service requests can include a request for information, password reset requests, asking for advice, requesting new software and asking for equipment to be moved. Examples are asking for an address change on a personnel record, requesting a new mobile phone, and asking for a new version of flowcharting software to be loaded onto a laptop. Some categories of service request may require approval before they can be fulfilled, for example it may be necessary for a budget holder to approve a request to purchase a new laptop before the service request is passed to the procurement department.

What is the difference between an incident and a service request?

Put simply, an incident occurs when something has broken whereas a request is made when a user wants something new or different.  In ITIL, an incident is defined as “An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident – for example, failure of one disk from a mirror set.” Whereas ITIL defines a service request as “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”. Request fulfilment differs from incident management. Incident management focuses on restoring services when there has been an interruption or reduction in quality, whereas request fulfilment does not concern itself with service failures.

 

What is request fulfilment in ITIL?

Request fulfilment is the process than manages service requests through their lifecycle, from the initial raising of the request through to its closure. Request fulfilment was added as a new process to ITIL V3 with the aim to have a dedicated process dealing with service requests. Prior to that, the incident management process managed requests as well as incidents. This was motivated by a clear distinction in ITIL V3 between incidents (service interruptions) and service requests (standard requests from users, e.g. password resets). Request fulfilment has been completely revised. Request fulfilment consists of five sub-processes, with each providing a detailed description of the related activities and decision points. Request fulfilment has interfaces with incident management, for requests which are subsequently diagnosed as incidents, and with service transition for when fulfilling the request requires the involvement of change management. ITIL request fulfilment refers to a service request model, which defines specific agreed steps that will be followed for a service request of a particular type or category. ITIL also has the concept of service request status information. This is a message containing the present status of a service request which can be provided the user who made the request. Status information is typically provided to users by the request fulfilment process at various points during the lifecycle of a service request.

What are the objectives of the ITIL request fulfilment process?

The primary objective of ITIL request fulfilment is to fulfil service requests made by users. In many cases, the service requests are standard changes, such as requests to change a password, or requests for information. Put simply, request fulfilment is all about providing users with access to the services that IT makes available to them. Related objectives for the request fulfilment process include:

What are the activities in request fulfilment?

The activities in request fulfilment are executed in sequence:

What are the sub-processes of ITIL request fulfilment?

ITIL request fulfilment has five sub-processes:

Request fulfilment support

This sub-process of request fulfilment provides and maintains the tools, service request model, processes, skills, and policies necessary for the effective and efficient execution of the efficient processing of service requests.

Request logging and categorization

This sub-process of request fulfilment records and categorizes the service requests, including checking the requests for completeness and the requester's authorization to submit them, in order to support swift and effective processing of the service requests.

Request model execution

The objective of this sub-process of request fulfilment is to execute the lifecycle of a service request within the time schedule agreed in the service level agreement.

Request monitoring and escalation

This sub-process of request fulfilment aims to continually monitor the processing status of in-progress service requests, so that action can be taken as soon as possible if service levels are likely to be breached.

Request closure and evaluation 

This sub-process of request fulfilment carries out quality controls on the service request resolution and associated service request record before the request can be fully closed. The aim is to ensure that the service request has been satisfactorily fulfilled and that all the information required to describe the lifecycle of the request has been captured in sufficient detail. The sub-process also aims to achieve continual improvement for the request fulfilment process by learning lessons for the future from the processing of this request.

What are the roles and responsibilities in request fulfilment?

The request fulfilment process involves a number of different roles. These roles can be carried out by the same individual, or by different people.

Users – Requestor

Users are responsible for raising service requests using the method agreed and documented in the request fulfilment service request model. Users should be trained in how to raise service requests, how to access updates on the status of their request, and how to accept closure of the service request following fulfilment. 

1st level support

1st level support, which is often the service desk, has the role of recording and categorizing service requests from information provided to them by the users. 1st level support is responsible for passing any unfilled requests to 2nd level support for fulfilment. These are also known as request fulfilment groups. 1st level support is additionally responsible for keeping users informed on the status of the service requests through the request fulfilment process.

Request fulfilment group

There can be several request fulfilment groups, with each one responsible for executing the fulfilment of specific categories and types of service requests. For some types of service request, it may be necessary for one fulfilment group to enlist the assistance of another specialist request fulfilment group, for example engaging with a procurement function where it is necessary to buy in equipment or services necessary to fulfil the service request.

Service request approvers

Some categories of service request require approval before they can be actioned and fulfilled. This can include financial approval where spend is required and the cost to fulfil the service request is greater than the approval limit of the requestor. It can also include security approval if the type of service requested requires the requestor to have sufficient security clearance. Some organizations insist that line managers review and approve all service requests that aren’t just requests for information.

 Incident Manager

The incident manager is the process owner for the request fulfilment process. The role is responsible for the effective design, implementation, change management, and continual improvement of the request fulfilment process. The role also carries out reporting for the process Key Performance Indicators (KPIs) and is responsible for defining the interfaces between the request fulfilment process and related ITSM processes including incident management, access management, knowledge management, change management, financial management, and configuration & asset management. The role provides the first stage of escalation for any issues with request fulfilment, including and requests that cannot be fulfilled within the agreed service levels.

What are typical request fulfilment workflows?

The precise details of request fulfilment workflows will depend on the needs and organizational structures of each business. Here are some examples of different types of typical request fulfilment workflows that can be configured into the service request software: 

 

Request for information request

In this type of service request, the user is asking for information such as ‘What hours does the service desk operate’.  Ideally, in order to try and reduce this type of service request, as much information as possible should be made available to users in an easily accessible and understandable knowledge base. However, it is never possible to fully eliminate this type of request in request fulfilment. The first step in this request fulfilment workflow is that the user asks the question, either by entering it into a request fulfilment software tool or by contacting the service desk who then enter it on their behalf.  A request fulfilment tool may have type-ahead search capabilities, where possible answers are presented and narrowed down as further information on the request is entered. It may be possible to fulfil the request at this point by providing the user with the information that they are looking for. Where this is not possible, the request fulfilment workflow should use the information provided in the request and the rules in the service request model to route the request to the appropriate fulfilment group. This fulfilment group can then either contact the user directly with the requested information or send it to them using the request fulfilment tool. The service request can be closed in the software once the user has confined that their request has been fulfilled to their satisfaction.

 

‘How do I’ request

These are service requests when the user is asking how to do something. The workflow for this type of service request is very similar to a request for information. Some organizations use the same request fulfilment workflow. Again, the ideal is that the request can be fulfilled using a request fulfilment software tool and if not routed automatically to the appropriate request fulfilment group. The difference between this type of request and a request for information is that a ‘how do I’ request indicates either that the user requires further training in the subject that they are asking about, or that the training materials used to train them are inadequate. This is why it is good practice to categorize ‘how do I’ requests in request fulfilment separately from information requests. Reports can be generated for this category and sent to the training function so that they can take appropriate action.

 

Password reset request

Most organizations have now installed software to fulfil requests to reset passwords without the need for support from anyone except the user themselves. This software can be part of request fulfilment software or separate, but with a link to it so that the user can access the reset functionality via the menu in the request fulfilment software. Where this hasn’t been done, it is likely that there will be a high volume of password reset requests, so the request fulfilment process for managing them must be efficient. It is important to track password reset requests in order to identify any ‘repeat offenders’ that could benefit from training. This type of request fulfilment workflow has a security aspect. It is important to verify the identity of the user making the request as it could be a fraudulent attempt to gain access to systems using their credentials. Hence it is vital to include a request fulfilment workflow step that includes verifying the identity of the user before resetting their password.  This is essentially access control, the process responsible for allowing users to make use of IT services, data or other assets.

 

Desk move request

In this type of request fulfilment workflow, a user is moving desks from one location in an organization to another. This could involve a number of different activities and fulfilment groups, including IT to move the equipment, security to issue new access passes, and office services to update building location information. An efficient request fulfilment workflow for this type of request would inform all of the relevant request fulfilment groups about the move at the same time, and give them all visibility of the other request fulfilment groups plans in order to coordinate the move between them. The service request can only be closed in the request fulfilment process when all the component activities have completed. This is a good example of a multi-branch request fulfilment workflow.

 

New software request

When a user requests new software the request fulfilment workflow is likely to include a number of different approvers.  If the software isn’t used anywhere else in the organization, then the request fulfilment process will have to request approval from the team responsible for the IT architecture.  If IT budgets are held centrally then the request fulfilment workflow will have to include a step to request approval from the budget holder for IT. Some organizations may also require approval and a written justification from the user’s head of department. Once all approvals have been given then the service request should be passed to procurement to purchase the software, then to IT to test it, and potentially to desktop support to implement it. This type of service request can be complex to define in the request fulfilment model, but once this has been completed all similar service requests can be efficiently managed to fulfilment.

 

Reporting request

This request fulfilment workflow is used when a user wants IT to produce a report for them. This is a simple workflow for the request fulfilment process, as it can usually be routed directly to IT without any prior review or approval stage.

How can you measure the effectiveness of request fulfilment?

ITIL includes the definition of some key metrics for request fulfilment which can be used to assess both the efficiency and effectiveness of the request fulfilment process. The suggested metrics include:

Other Related Resources

BLOG

Incident and Service request: How are they different?
BLOG

Improve Incident Resolution with Freshservice Team Huddle
BLOG

What can service management learn from product management?
BLOG

You Still Don’t Have a Service Catalog? BIG Mistake!