1. About this document
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.
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.
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.
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 | |
|---|---|---|---|
| A user monitors status of a printer. When the printer signals ‘low toner’, the user requests toner refill. The service provider’s technician replaces the toner cartridge. Except for the replacement procedure, printing is not interrupted. | Service request | Service desk Service request management Infrastructure and platform management | |
| A printer communicates its status and events to the operations team. When a ‘low toner’ event occurs, the service provider’s technician replaces the toner cartridge. Except for the replacement procedure, printing is not interrupted. | Event | Monitoring and event management Infrastructure and platform management | |
| In the case of something going wrong in the above scenarios. The ‘low toner’ status is not reported in time (or the cartridge is not replaced in time or replaced incorrectly). The printing is interrupted. Users report the situation to the service provider. The service provider’s technician replaces the toner cartridge. Printing is restored. | Incident | Service desk Incident management Infrastructure and platform management | |
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, 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.
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 and and services | Change enablement Deployment management Release management |
| Monitoring services and technology | Monitoring and event management |
| Ongoing management and implementation of improvements | Continual improvement |
| Management of request catalogue | Service catalogue management |
| Management and provision of access to services | Information security management |
| Creating service request models | Service design |
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).
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 fulfilment procedures for all services are optimized | Completeness of the service request catalogue, number, and percentage of service requests that are not supported with fulfillment 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 are fulfilled according to the agreed procedures and to user satisfaction | Number and percentage of requests fulfilled according to the SLA 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.
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.
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 Service request models Service level agreements Fulfilment actions records and reports | Request categorization Service request model initiation and control Ad hoc fulfilment control Fulfilment review | Fulfilled service requests Fulfilment actions records and reports User satisfaction surveys |
Figure 3.2 shows a workflow diagram of the 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
| Activity | Manual or incomplete service request model | Highly automated service request model |
|---|---|---|
| Request categorization | All the prerequisites for the service request and user eligibility are checked, wholly or partly manually. Missing information or paperwork is requested from the user. The service desk agent chooses the appropriate service request model. | In a highly automated environment, a service request is automatically checked for all the prerequisites. If additional information or paperwork is needed, the system contacts the user and asks for the missing prerequisites. An appropriate model and set of automated procedures are chosen based on the service request characteristics. |
| Service request model initiation and control | The service desk agent may need to manually select the right support team or specialists, according to the service request model. The assigned teams follow the service request fulfilment procedures defined for the model. 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. | Request fulfilment according to the chosen service request model is initiated and the system controls the flow of procedures and scripts evoked to fulfil the request. Upon fulfilment, the service request is routed to the fulfilment review. |
| Ad hoc fulfilment control | There are cases when a service request 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 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 review | Service request fulfilment is checked according to the model. 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 |
|---|---|---|
| Current service request models User survey results Related changes and change models Policies and regulatory requirements Service catalogue Service level agreements IT asset information CMDB Capacity and performance information | Service request records and reports analysis Service request model improvement initiation Service request model update communication | Updated service request model Updated service request procedures and working instructions |
Figure 3.3 shows a workflow diagram of the 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 reports analysis | The service request practice owner, together with the service 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 improvement initiation | The service request practice owner registers the improvement 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 communication | If the service request model is successfully updated, it is communicated to the relevant stakeholders. This is usually done by the service request practice owner or the service owner. |
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 code | Competency profile (activities and skills) |
|---|---|
| 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 Product owner Service owner Technical specialist | CTM | Good knowledge of the organization’s products and services Knowledge of service catalogue, SLAs, request models |
| Service request model initiation and control | User support agent Service owner Technical specialist | CAT | Good knowledge of the service request models and of the service provider organization |
| Ad hoc fulfilment control | Service owner Technical team lead | CTA | Good knowledge of products, services, and SLAs Understanding of business needs Authority to assign resources and plan ad hoc work |
| Fulfilment review | Service owner Practice owner Practice manager/coordinator | MCT | Good knowledge of products, services, and SLAs Understanding of business needs Good knowledge of the service request models and of the service provider organization |
| Service request and review optimization | |||
| Service request records and reports analysis | Product owner Service owner Practice owner Practice manager/ coordinator | TM | Good knowledge of the service and products and service request models |
| Service request model improvement initiation | Practice owner Practice manager/ coordinator Product owner Service owner Resource owner ITSM tool consultant | TCA | Good knowledge of the service, products, and service request modelsGood knowledge of available tools and methods |
| Service request model update communication | Practice owner Practice manager/ coordinatorProduct owner Service owner Resource owner | C | Understanding the service request modelsCommunication skills |
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.
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 and collaboration tools ITSM toolsets | Request catalogue management work assignment Pre-defined routing | High |
| Service request model initiation and control | Workflow management and collaboration tools ITSM toolsets | Work assignment Predefined routing Collaboration, task | High |
| Ad hoc fulfilment control | Workflow management and collaboration tools ITSM toolsets System monitoring tools | Monitoring work progress Communications Notifications, escalation | Medium to high |
| Fulfilment review | Workflow management and collaboration tools ITSM toolsets | Communication and collaboration Reporting and analytics | Medium |
| Service request and review optimization | |||
| Service request records and reports analysis | Analysis and reporting tools | Statistical analysis of service request workloads and flows | High |
| Service request model improvement initiation | Workflow management and collaboration tools | Backlog and workflow management and visualization Communication and collaboration | Medium to high |
| Service request model update communication | Publishing tools Social media Workflow management tools | Mail Push notifications Web portal Awareness posts | High |
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).
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.