Service request

management
ITIL® 4 Practice Guide
AXELOS.com

28th
February
2020

AXELOS Copyright View Only – Not for Redistribution © 2020

2 Service request management AXELOS Copyright View Only – Not
for Redistribution © 2020

Contents
1 About this document 3
2 General information 4
3 Value streams and processes 10
4 Organizations and people 15
5 Information and technology 18
6 Partners and suppliers 20
7 Important reminder 21
8 Acknowledgments 22

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Service request management 3
for Redistribution © 2020

1 About this document

This document provides practical guidance for the service request management practice. It is split
into five main sections, covering:
● general information about the practice
● the practice’s processes and activities and their roles in the service value chain
● the organizations and people involved in the practice
● the information and technology supporting the practice
● considerations for partners and suppliers for the practice.

1.1 ITIL® 4 QUALIFICATION SCHEME

Selected content from this document is examinable as a part of the following syllabuses:
● ITIL Specialist Create, Deliver and Support
● ITIL Specialist High-velocity IT.
Please refer to the respective syllabus documents for details.

AXELOS Copyright View Only – Not for Redistribution © 2020

4 Service request management AXELOS Copyright View Only – Not
for Redistribution © 2020

2 General information
2.1 PURPOSE AND DESCRIPTION

Key message

The purpose of the service request management practice is to support the agreed quality of a
service by handling all predefined, user-initiated service requests in an effective and user-
friendly manner.

Definition: Service request

A request from a user or a user’s authorized representative that initiates a service action which
has been agreed as a normal part of service delivery.

Service requests are an important type of user query and an important part of the user experience.
Typically, service requests include the following:
● a request initiating a service action (performed by the service provider or jointly with the user)
● a request for information
● a request for access to a resource or service
● feedback, compliments, or complaints.

Fulfilling service requests may include changes to services or their components; these are usually
standard changes. As service requests are predefined and pre-agreed as a normal part of service
delivery, they can usually be formalized with a clear, standard procedures for initiation, approval,
fulfilment, and management. Some service requests have very simple workflows, such as a request
for information. Other service requests, such as the setup of a new employee, may be complex and
require contributions from many teams and systems in order for it to be fulfilled. Regardless of the
complexity, the steps to fulfil the request should be well-known and tested. This allows the
service provider to agree times for fulfilment and provide clear communication of the status of the
request to users.

The development and testing of the procedures are performed at the respective stages of the
product and service lifecycle and involve multiple practices, such as the business analysis, service
design, risk management, change enablement, service catalogue management, and service level
management practices, among others.

Some service requests require authorization, according to financial, information security, or other
policies. In order to handle this appropriately, the service request management practice should
follow these guidelines:
● service requests and their fulfilment should be standardized and automated as far as possible
● policies should be established depending on which service requests can be fulfilled with limited
or no additional approvals to streamline fulfilment
● user expectations regarding fulfilment times should be clearly set based on what the
organization can deliver
● opportunities for improvement should be identified and implemented to produce faster
fulfilment times and leverage automation
● policies and workflows should be included for documenting and redirecting any requests that are
submitted as service requests, but which should be managed as incidents or changes.

Some service requests can be completely fulfilled by automation, from submission to closure,
allowing for a complete self-service experience. For example, client software installation or the
provision of virtual servers.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Service request management 5
for Redistribution © 2020

2.2 TERMS AND CONCEPTS

The main characteristics of a service request includes the following:
● It is initiated by a user or a user representative.
● It requires an action from the service provider.
● It is an action that has an agreed upon service outcome. This means the service outcome was
tested in advance, the approval flow and fulfilment flow for the request were pre-approved,
people were trained, and service components were setup to fulfil it.

A service request is a normal part of service delivery, which is ‘business as usual’. This means the
results and the timelines are well understood by the customer, users, and operation teams of the
service provider, and are usually predictable. Wherever possible, service requests should be
automated and accessible through channels that are efficient and convenient for users, such as a
client portal.

Service requests may play different roles within service quality and service experience. In many
cases, they contribute to service utility when service actions are a key form of service interaction.
In some cases, service requests can add to higher service levels, adding valuable options to
otherwise standardized service offerings. Finally, service requests may be used to initiate the
maintenance of service components, where the service provider’s monitoring and event
management capability is limited and the monitoring of service components is delegated to users.

Note that service requests are a form of user query and a way to initiate certain predefined
activities significant to service experience. The same activities may be initiated differently, and
although technical operations may be identical, their role in the user experience would be
different, as shown in Table 2.1.

Table 2.1 Activities related to the service request practice described in other practice guides

Example Activity Practice guide

Service desk
A user monitors status of a printer. Service request
When the printer signals ‘low toner’, Service request management
the user requests toner refill. The
service provider’s technician replaces Infrastructure and platform
the toner cartridge. Except for the management
replacement procedure, printing is not
interrupted.
Monitoring and event management
A printer communicates its status and Event
events to the operations team. When a Infrastructure and platform
‘low toner’ event occurs, the service management
provider’s technician replaces the
toner cartridge. Except for the
replacement procedure, printing is not
interrupted.
Service desk
In the case of something going wrong Incident
in the above scenarios. The ‘low toner’ Incident management
status is not reported in time (or the
cartridge is not replaced in time or Infrastructure and platform
replaced incorrectly). The printing is management
interrupted. Users report the situation
to the service provider. The service
provider’s technician replaces the
toner cartridge. Printing is restored.

Similarly, service requests may initiate changes, which are usually standard changes but can
sometimes be a normal change. The need for change is defined by the change typology adopted by
the company; there is mandatory 'correlation between service requests and changes. For example,

AXELOS Copyright View Only – Not for Redistribution © 2020

6 Service request management AXELOS Copyright View Only – Not
for Redistribution © 2020

moving an employee from one desk to another within the office is likely to be managed as a
service request; whether it needs a change or multiple changes, depends on technical impact of
the move and criteria for changes agreed in the organization (as part of the change enablement
practice). Some service requests of this type may need one or more changes; others would be
fulfilled without the change enablement practice involved.

The lifecycle of a service request always involves multiple practices. A typical value stream to
fulfil a service request is likely to involve:
● service desk: to process the user query
● service request management: to route and guide the request fulfilment
● infrastructure and platform management: to perform the necessary technical operations
● release management: to make the service components available to users
● change enablement: to coordinate the necessary changes
● information security management: to provide or alter access.

Other practices may be involved, as needed. The involvement and procedure for fulfilling every
type of service request is documented in the service request models.

Definition: Service request model

A repeatable predefined approach to the fulfilment of a particular type of service requests.

Service request models are usually produced during product and service design. The models are
tested and deployed to operations along with other components of the service. The service request
management practice is involved at all stages to ensure that the models are realistic and accepted
by everyone involved in their management and execution. The continual improvement of products
and services may include the improvement of the related service request models.

Service request models describe the conditions and procedures for service request fulfilment,
covering all four dimensions of service management:
● procedures and workflows, including possible options and decisions
● roles and teams responsible (usually as a RACI matrix)
● automation and tools used
● third parties involved in and supporting agreements.

As service requests are initiated by users or their representatives, they should be available to users
in a convenient and actionable way. The most common approach is to include the available service
requests in user-facing views of the organization’s service catalogue. Management of the catalogue
is within the scope of the service catalogue management practice, but information for it is
provided by the service request management practice.

Definition: Request catalogue

A view of the service catalogue, providing details on service requests for existing and new
services, which is made available to the user.

Usually, the following information about the available service requests is available through a
request catalogue:
● service to which a service request belongs
● prerequisites/conditions for a service request invitation
● information required to initiate the request
● approval workflow, if applicable
● target fulfilment time
● other relevant information.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Service request management 7
for Redistribution © 2020

The service request catalogue view is expected to be tailored for service level agreements (SLAs)
that are applicable to the user accessing the view, so that all of the information reflects the
conditions and targets agreed for the user. The more relevant the information in the request
catalogue is, the more efficient the service request fulfilment will be, and the higher the user
satisfaction.

2.3 SCOPE
The scope of the service request management practice includes:
● managing service request models
● processing service requests submitted by users or their representatives
● managing the fulfilment of service requests according to the agreed models
● reviewing and continually improving request processing and fulfilment performance.

There are several activities and areas of responsibilities that are not included in the service
request management practice, although they are closely related to service request management.
They are listed in Table 2.2, along with references to the practices in which they can be found. It
is important to remember that ITIL practices are tools to use in the context of the value streams;
they should be combined as necessary, depending on the situation.

Table 2.2 Activities related to the service request management practice described in other
practice guides

Activity Practice guide

Resolving incidents Incident management

Communicating with users Service desk

Management and realization of changes to products Change enablement

and services Deployment management
Release management

Monitoring services and technology Monitoring and event management

Ongoing management and implementation of Continual improvement

improvements

Management of request catalogue Service catalogue management

Management and provision of access to services Information security management

Creating service request models Service design

AXELOS Copyright View Only – Not for Redistribution © 2020

8 Service request management AXELOS Copyright View Only – Not
for Redistribution © 2020

2.4 PRACTICE SUCCESS FACTORS

Definition: Practice success factor

A complex functional component of a practice that is required for the practice to fulfil its
purpose.

A practice success factor (PSF) is more than a task or activity as it includes components from all
four dimensions of service management. The nature of the activities and resources of PSFs within a
practice may differ, but together they ensure that the practice is effective.

The service request management practice includes the following PSFs:

● ensuring that the service request fulfilment procedures for all services are optimized
● ensuring that all service requests are fulfilled according to the agreed procedures and to user
satisfaction.

2.4.1 Ensuring that the service request fulfilment procedures for all
services are optimized
The development of the service request procedures should be integrated early into the product
and service lifecycle management. The service request practice should contribute to business
analysis, architecture management, and service design activities. Depending on the decisions that
are made at those stages, a service may be optimized for a no-request operation or include
multiple requests available to users as a part of normal consumption. In the first case, generic
requests, such as compliments, complaints, or how-to requests are still available to service users.
In the second case, there may be various requests specific to service utility (their fulfilment
becomes an important contributor to service quality). Service requests can also be a differentiator
between different levels of service offerings (more requests may be available to users of higher
trims of the service).

It is important to identify, document, and test service request fulfilment procedures and assign
responsibilities for the activities. It is equally important to ensure that requests are correctly
described in a request catalogue and that the catalogue is available to the users who should be
able to initiate the requests. This is achieved in conjunction with the service catalogue
management practice.

Service request fulfilment procedures should be subject to continual improvement based on the
monitoring of fulfilment performance and user satisfaction. One way to optimize the fulfilment
procedures is to automate them wherever reasonably possible. This applies to the most popular
and routine requests that have limited variations in fulfilment workflows. Tailored, complex, and
rare requests should be automated only after careful consideration to ensure that the costs and
risks of automation are justified.

Service request fulfilment procedures are documented within the service request models, along
with resources, responsibilities, and other relevant information.

2.4.2 Ensuring that all service requests are fulfilled according to the
agreed procedures and to user satisfaction
If the fulfilment procedures are optimized and documented, and responsibilities are clear, service
requests are easy to fulfil and plan for. Statistics on every type of request can help to optimize
resource planning and to ensure the timely processing of all requests. Unlike incidents, service
requests do not need to be fulfilled urgently; they allow for more comfortable planning and should
be completed within an agreed timeframe.

Requests may require a review after fulfilment. The review can be limited to a satisfaction survey
or include a detailed internal review (usually necessary if something went wrong, or user
satisfaction is low).

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Service request management 9
for Redistribution © 2020

2.5 KEY METRICS

The effectiveness and performance of the ITIL practices should be assessed within the context of
the value streams to which each practice contributes. As with the performance of any tool, the
practice’s performance can only be assessed within the context of its application. However, tools
can differ greatly in design and quality, and these differences define a tool’s potential or
capability to be effective when used according to its purpose. Further guidance on metrics, key
performance indicators (KPIs), and other techniques that can help with this can be found in the
measurement and reporting practice guide.

Key metrics for the service request management practice are mapped to its PSFs. They can be
used as KPIs in the context of value streams to assess the contribution of the service request
practice to the effectiveness and efficiency of those value streams. Some examples of key metrics
are given in Table 2.3.

Table 2.3 Examples of key metrics for the practice success factors

Practice success factors Key metrics

Ensuring that the service request Completeness of the service request catalogue, number, and
fulfilment procedures for all percentage of service requests that are not supported with
services are optimized fulfilment procedures

Number and percentage of service requests that could not be

fulfilled by following the agreed procedure due to
errors/inefficiencies in the procedure

Satisfaction of the team members fulfilling the requests with

instructions provided

Average time and cost needed to fulfil requests (by

types/models)

Percentage of service requests with fully or largely

automated fulfilment (number, percentage in the catalogue,
percentage in total number, and fulfilment time)

Ensuring that all service requests Number and percentage of requests fulfilled according to the
are fulfilled according to the SLA
agreed procedures and to user
satisfaction Impact of incidents caused by the incorrect fulfilment of
service requests

User satisfaction with request fulfilment

Number and percentage of requests fulfilled with deviations

from the agreed procedures

The correct aggregation of metrics into complex indicators will make them easier to use for the
ongoing management of value streams and for the periodic assessment and continual improvement
of the service request management practice. There is no single best solution. Metrics will be based
on the overall service strategy and priorities of an organization, as well as on the goals of the
value streams to which the practice contributes.

AXELOS Copyright View Only – Not for Redistribution © 2020

10 Service request management AXELOS Copyright View Only – Not
for Redistribution © 2020

3 Value streams and processes

3.1 VALUE STREAM CONTRIBUTION
Like any other ITIL management practice, the service request practice contributes to multiple
value streams. It is important to remember that a value stream is never formed from a single
practice. The service request practice combines with other practices to provide high-quality
services to consumers. The main value chain activities to which the practice contributes are:
● engage
● deliver and support
● design and transition
● obtain/build.

The contribution of the service request management practice to the service value chain is shown
in Figure 3.1.

Figure 3.1 Heat map of the contribution of the service request management practice to value
chain activities

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Service request management 11
for Redistribution © 2020

3.2 PROCESSES
Each practice may include one or more processes and activities that may be necessary to fulfil the
purpose of that practice.

Definition: Process

A set of interrelated or interacting activities that transform inputs into outputs. A process takes
one or more defined inputs and turns them into defined outputs. Processes define the sequence
of actions and their dependencies.

Service request management activities form two processes:

● service request fulfilment control
● service request review and optimization.

3.2.1 Service request fulfilment control

This process includes the activities listed in Table 3.1 and transforms the inputs into outputs.

Table 3.1 Inputs, activities, and outputs of the service request fulfilment control process

Key inputs Activities Key outputs

Service request queries Request categorization Fulfilled service requests

Service request models Service request model initiation Fulfilment actions records and
and control reports
Service level agreements
Ad hoc fulfilment control User satisfaction surveys
Fulfilment actions records and
reports Fulfilment review

Figure 3.2 shows a workflow diagram of the process.

Figure 3.2 Workflow of the service request fulfilment control process

The process may vary depending on the request model. Table 3.2 provides an example of
variations.

Table 3.2 Service request fulfilment control process activities

AXELOS Copyright View Only – Not for Redistribution © 2020

12 Service request management AXELOS Copyright View Only – Not
for Redistribution © 2020

Activity Manual or incomplete service request Highly automated service request model
model

Request All the prerequisites for the service In a highly automated environment, a service
categorization request and user eligibility are checked, request is automatically checked for all the
wholly or partly manually. Missing prerequisites. If additional information or
information or paperwork is requested paperwork is needed, the system contacts the
from the user. user and asks for the missing prerequisites.

The service desk agent chooses the An appropriate model and set of automated
appropriate service request model. procedures are chosen based on the service
request characteristics.

Service request The service desk agent may need to Request fulfilment according to the chosen
model initiation manually select the right support team service request model is initiated and the
and control or specialists, according to the service system controls the flow of procedures and
request model. The assigned teams scripts evoked to fulfil the request.
follow the service request fulfilment
procedures defined for the model. Upon fulfilment, the service request is routed
to the fulfilment review.
If necessary, additional approvals are
obtained, according to the service
request procedures.

In some cases, several service request

tasks need to be fulfilled. Manual
assignment and control by the service
desk agent is needed, as well as
notifications to the user.

Responsible teams fulfil whole service

request or specific tasks.

If necessary, the responsible team

updates the relevant configuration items.

Upon fulfilment, the service request is

routed to the fulfilment review.

Ad hoc fulfilment There are cases when a service request

control fulfilment needs some non-standard,
tailored work, or there are some new
circumstances that were not taken into
consideration when the service request
was planned. So following the procedure
does not produce the desired result, the
service request is then routed for an ad
hoc fulfilment.

Ad hoc fulfilment is an exception and

should be treated like one.

A decision should be made about whether

to act upon the exception or simply deny
the service request fulfilment. This
decision is usually defined by the model
and the way the model handles
exceptions.

Regardless of the decision made, details

of a case should become an input into the

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Service request management 13
for Redistribution © 2020

service request model review and

optimization process, so that this case is
well-defined and added to the model, or
additional checks are added to triage and
categorization, to sort such cases out of
the model.

Fulfilment Service request fulfilment is checked according to the model.

review
The fulfilment review should be described by the model. The fulfilment review may
contain some procedures to check to what extent the fulfilment has produced the
desired result.

The fulfilment review may also involve collecting user feedback and measuring user
satisfaction.

The reports and record of the fulfilment review serve as inputs into the service request
review and optimization process.

3.2.2 Service request review and optimization

The process is focused on the continual improvement of the service request models management
practice. It is recommended to perform this process regularly or when trigged by the user survey
results. This process includes the activities listed in Table 3.3 and transforms the inputs into
outputs.

Table 3.3 Inputs, activities, and outputs of the service request review and optimization process

Key inputs Activities Key outputs

Service request records and Updated service request model
Current service request models
reports analysis
Updated service request
User survey results
Service request model procedures and working
improvement initiation instructions
Related changes and change
models
Service request model update
communication
Policies and regulatory
requirements

Service catalogue

Service level agreements

IT asset information

CMDB

Capacity and performance

information

Figure 3.3 shows a workflow diagram of the process.

AXELOS Copyright View Only – Not for Redistribution © 2020

14 Service request management AXELOS Copyright View Only – Not
for Redistribution © 2020

Figure 3.3 Workflow of the service request review and optimization process

Table 3.4 provides a description of the process activities.

Table 3.4 Activities of the service request review and optimization process

Activity Description

Service request records and The service request practice owner, together with the service
reports analysis owners and other relevant stakeholders, perform a review of the
selected service requests and related metrics over the period
and/or relevant repeating changes from the change enablement
practice. They identify opportunities for the new service request
models and/or improvement of the current service request
models.

Service request model The service request practice owner registers the improvement
improvement initiation initiatives, which are submitted for processing with the
involvement of the continual improvement practice and/or
change requests.

If testing does not confirm the effectiveness of the proposed

service request model, it is returned for further analysis.

Service request model update If the service request model is successfully updated, it is
communication communicated to the relevant stakeholders. This is usually done
by the service request practice owner or the service owner.

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Service request management 15
for Redistribution © 2020

4 Organizations and people

4.1 ROLES, COMPETENCIES, AND RESPONSIBILITIES
The practice guides do not describe the practice management roles such as practice owner,
practice lead, or practice coach. They focus instead on specialist roles that are specific to each
practice. The structure and naming of each role may differ from organization to organization, so
any roles defined in ITIL should not be treated as mandatory, or even recommended. Remember,
roles are not job titles. One person can take on multiple roles and one role can be assigned to
multiple people.

Roles are described in the context of processes and activities. Each role is characterized by a
competency profile based on the model shown in Table 4.1.

Table 4.1 Competency codes and profiles

Competency Competency profile (activities and skills)

code

L Leader Decision-making, delegating, overseeing other activities, providing incentives

and motivation, and evaluating outcomes

А Administrator Assigning and prioritizing tasks, record-keeping, ongoing reporting,

and initiating basic improvement

C Coordinator/communicator Coordinating multiple parties, maintaining

communication between stakeholders, and running awareness campaigns

М Methods and techniques expert Designing and implementing work techniques,

documenting procedures, consulting on processes, work analysis, and continual
improvement

Т Technical expert Providing technical (IT) expertise and conducting expertise-based

assignments

There are no specialist roles specific to the service request management practice. The role of
request initiator can be fulfilled by any user or authorized user representative; it does not require
special skills or competencies. The key activities of the service processes described above are
typically performed by the service provider’s technical specialists, service owners, and user
support agents, but there are no or little competency profile specific to the practice.

Examples of other roles which can be involved in the service request management activities are
listed in Table 4.2, together with the associated competency profiles and specific skills.

Table 4.2 Examples of the roles involved in service request management practice activities

Activity Responsible roles Competency profile Specific skills

Service request fulfilment control process

Request categorization User support agent CTM Good knowledge of the

organization’s products
Product owner and services

Service owner

AXELOS Copyright View Only – Not for Redistribution © 2020

16 Service request management AXELOS Copyright View Only – Not
for Redistribution © 2020

Technical specialist Knowledge of service

catalogue, SLAs,
request models

Service request model User support agent CAT Good knowledge of the
initiation and control service request models
Service owner and of the service
provider organization
Technical specialist

Ad hoc fulfilment control Service owner CTA Good knowledge of

products, services, and
Technical team lead SLAs

Understanding of
business needs

Authority to assign
resources and plan ad
hoc work

Fulfilment review Service owner MCT Good knowledge of

products, services, and
Practice owner SLAs

Practice manager/ Understanding of

coordinator business needs

Good knowledge of the

service request models
and of the service
provider organization

Service request and review optimization

Service request records Product owner TM Good knowledge of the

and reports analysis service and products
Service owner and service request
models
Practice owner

Practice manager/
coordinator

Service request model Practice owner TCA Good knowledge of the

improvement initiation service, products, and
Practice manager/ service request models
coordinator
Good knowledge of
Product owner available tools and
methods
Service owner

Resource owner

ITSM tool consultant

Service request model Practice owner C Understanding the

update communication service request models
Practice manager/
coordinator Communication skills

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Service request management 17
for Redistribution © 2020

Product owner

Service owner

Resource owner

4.2 ORGANIZATIONAL STRUCTURES AND TEAMS

It is unusual to see dedicated organizational structures for the service request management
practice. This practice is integrated in the day-to-day activities of the service delivery and
realization team or technicians that are defined in advance during the service request model
definition. Usually, the same team structures are used for service request management as for the
incident management practice. However, in situations where services include service request as
part of the service utility, and demand is very high, dedicated teams can be formed to process and
fulfil all or some types of service requests. In many cases, automation can decrease the need for
such teams and improve service quality.

AXELOS Copyright View Only – Not for Redistribution © 2020

18 Service request management AXELOS Copyright View Only – Not
for Redistribution © 2020

5 Information and technology

5.1 INFORMATION EXCHANGE
The effectiveness of service request management practice is based on the quality of the
information used. This information includes, but is not limited to, information about:
● customers and users
● services and their associated request catalogue and request models
● partners and suppliers, including information on the services they provide
● policies and requirements which regulate service provision
● stakeholder satisfaction with the practice.

This information may take various forms. The key inputs and outputs of the practice are listed in
the value streams and processes section of this guide.

5.2 AUTOMATION AND TOOLING

In some cases, the work of the service request management practice can benefit significantly from
automation. Where this is possible and effective, it may involve the solutions outlined in Table
5.1.

Table 5.1 Automation solutions for service request management activities

Process activity Means of automation Key functionality Impact on the

effectiveness of the
practice

Service request fulfilment control

Request categorization Workflow management Request catalogue High

and collaboration tools management

ITSM toolsets Work assignment

Pre-defined routing

Service request model Workflow management Work assignment High

initiation and control and collaboration tools
Predefined routing
ITSM toolsets
Collaboration, task

Ad hoc fulfilment Workflow management Monitoring work Medium to high

control and collaboration tools progress

ITSM toolsets Communications

System monitoring Notifications, escalation

tools

Fulfilment review Workflow management Communication and Medium

and collaboration tools collaboration

ITSM toolsets Reporting and analytics

Service request and review optimization

Service request records Analysis and reporting Statistical analysis of High

and reports analysis tools service request
workloads and flows

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Service request management 19
for Redistribution © 2020

Service request model Workflow management Backlog and workflow Medium to high
improvement initiation and collaboration tools management and
visualization

Communication and
collaboration

Service request model Publishing tools Mail High

update communication
Social media Push notifications

Workflow management Web portal

tools
Awareness posts

AXELOS Copyright View Only – Not for Redistribution © 2020

20 Service request management AXELOS Copyright View Only – Not
for Redistribution © 2020

6 Partners and suppliers

Very few services are delivered using only an organization’s own resources. Most, if not all, depend
on other services, often provided by third parties outside the organization (see section 2.4 of ITIL
Foundation: ITIL 4 Edition for a model of a service relationship). Relationships and dependencies
introduced by supporting services are described in the practice guides for service design,
architecture management, and supplier management.

Due to the intrinsic characteristics of the service requests, such as being predefined, pre-
approved, and predictable, it is natural for organizations to outsource the service request
management. Organizations should be careful in keeping the level of the service request
management high, as it has a direct impact on the users’ satisfaction and may have an undesirable
impact on the value of the service.

Service request models should define how third parties are involved in service request fulfilment
and how the organization ensures effective collaboration. This will depend on the architecture and
design solutions for products, services, and value streams. Nonetheless, the optimization of service
request models supporting these solutions will involve the service request management practice.

Defined standard interfaces may become an easy way to communicate conditions and
requirements in order for a supplier to become a part of the organization’s ecosystem. Such an
interface description may include rules of data exchange, tools, and processes that will create a
common language in the multi-vendor environment.

Where organizations aim to ensure a fast and effective service request management practice, they
usually try to agree to close cooperation with their partners and suppliers, removing formal
bureaucratic barriers in communication, collaboration, and decision-making (see the supplier
management practice guide for more information).

AXELOS Copyright View Only – Not for Redistribution © 2020

 AXELOS Copyright View Only – Not Service request management 21
for Redistribution © 2020

7 Important reminder
Most of the content of the practice guides should be taken as a suggestion of areas that an
organization might consider when establishing and nurturing their own practices. The practice
guides are catalogues of topics that organizations might think about, not a list of answers. When
using the content of the practice guides, organizations should always follow the ITIL guiding
principles:
● focus on value
● start where you are
● progress iteratively with feedback
● collaborate and promote visibility
● think and work holistically
● keep it simple and practical
● optimize and automate.

More information on the guiding principles and their application can be found in section 4.3 of ITIL
Foundation: ITIL 4 Edition.

AXELOS Copyright View Only – Not for Redistribution © 2020

22 Service request management AXELOS Copyright View Only – Not
for Redistribution © 2020

8 Acknowledgments
AXELOS Ltd is grateful to everyone who has contributed to the development of this guidance.
These practice guides incorporate an unprecedented level of enthusiasm and feedback from across
the ITIL community. In particular, AXELOS would like to thank the following people.

8.1 AUTHORS
Miroslav Hlohovsky, Don Page, Robert Pinnington.

8.2 REVIEWERS
Dinara Adyrbayeva, Cheryl Grimes, Roman Jouravlev, Georges Kemmerling, Henny Kerkvliet, Niels
Loader, Anton Lykov, Paulo Tourinho.

AXELOS Copyright View Only – Not for Redistribution © 2020