Service request management is central to how we handle interactions between the IT team and end users.
Empowering colleagues with regularized, efficient access to services is one of the most basic pillars of our ITSM delivery.
The IT Infrastructure Library (ITIL) is a framework for designing and implementing ITSM processes that prioritizes value for the wider organization.
In this guide, we’re exploring how service requests are handled within ITIL and the practical and theoretical issues that underpin effective service delivery.
Service request management is the ITSM process that enables users to access regular, defined services.
This is the point at which most end-user-focused service processes are initiated. For example, device rentals, data requests, password resets, support ticketing, or other day-to-day internal IT services.
The goal of service request management is, firstly, to provide colleagues with a convenient, accessible way to initiate service requests. Secondly, this furnishes IT teams with the information they need to respond to requests.
Therefore, our priorities are balancing streamlined experiences for the users initiating requests with the need to collect the structured data that’s required to enact defined business rules relating to delivering specific service workflows.
At the highest level, a service request is any interaction between a service user and the IT team that initiates a service workflow.
Informal examples of this could be an email, phone call, or face-to-face conversation.
However, in an enterprise context, service request workflows must be formalized. This means providing users with a consistent means to provide information about their requests in a defined schema.
Therefore, at a more technical level, when we talk about a service request, we’re also referring to the data object that triggers a service workflow.
Defining this data schema is a core part of our service design, with service requests applying specifically to regularized processes that are offered within our service portfolio.
To better understand what service requests are, we can situate them within their broader workflows.
That is, the sequence of events and actions that requests result in.
Naturally, the granular details of this will vary hugely across different organizations and the services they offer.
However, we can characterize almost all service request workflows as being made up of the following elements.
At least, these are the core building blocks of a request workflow.
In the real world, the scale and complexity of each of these steps can vary widely.
For instance, authorizing a basic request like a password reset might be a simple matter of agent availability. Or, this could even be largely automated in a self-service workflow.
By contrast, authorizing a request to acquire a new device might require input from a range of stakeholders, including the IT, legal, finance, or operations departments.
Besides these three core elements, some service request workflows might require additional stages, especially where there are stricter requirements around business analysis and evaluation or documentation and knowledge management.
ITIL is a very specific approach to managing ITSM that breaks our service provision down into 37 constituent practices. These are divided into three categories: general management, service management, and technical management.
Service request management is an ITIL practice under the service management umbrella.
This is formally defined within ITIL as the practice that handles all pre-defined, user-initiated service requests in an effective and user-friendly way.
ITIL also defines a service request as any submission from a user that initiates a service that has been agreed upon as a normal part of service delivery.
While ITIL does not prescribe rigid processes to individual ITSM practices, it does offer a clear framework for delivering value across the business through IT services.
Here’s what this means in the context of service request management.
Earlier, we alluded to the fact the specific kinds of service requests may be handled differently from one another. ITIL distinguishes between a variety of different types of service requests.
Specifically, these are characterized as including one or all of the following:
In some cases, service requests might also necessitate change within our services, although these are limited to what are known as standard or normal changes within ITIL’s change control practice.
That is, routine changes that might still require some element of authorization, such as procuring new devices.
The important thing here is that different kinds of service requests will have distinct initiation, authorization, and fulfillment processes, as well as varying in terms of the colleagues that can initiate, approve, or fulfill them.
We’ll also see a similar variety within each category of service request. For instance, all asset rental requests might follow a similar pattern, but the specific business rules governing individual devices could vary depending on their financial value or importance.
As such, ITIL does not go as far as providing detailed guidance on how to handle requests for individual services, as the likelihood is that we’ll need to design a large number of these even within a single organization.
Rather, it provides a series of principles for designing effective service request flows, along with best practices, such as providing expectations and timelines to users around their requests as part of the service catalog management process.
One of the underlying facets of ITIL is recognizing and accounting for the intersection of various ITSM practices. Certain IT processes will always overlap.
The two practices we need to be cognizant of here are change control and incident management.
Change control is the practice of assessing and authorizing requests for updates, alterations, or removals to elements that contribute to an IT service. Incident management relates to how we mitigate the impact of events that could affect our service delivery.
While each of these is a distinct practice within ITIL, it’s nonetheless important to understand the relationships between them and the specific points where they can intersect.
The key thing here is that an single request from a user might entail elements of some or all of these practices.
As we saw a few moments ago, some element of change might be required in order to deliver a routine service. For example, if we need to acquire a new asset or make changes to any other configuration item in order to deliver a service according to specifications.
Similarly, the initial need for an end user to initiate a service workflow could be related to an incident. A common example of this would be requesting a password change because of a low-level security breach.
In this case, as well as delivering the directly applicable service, we’d need to carry out whichever remedial actions are outlined in our incident management practice in response to their service request.
As such, it’s imperative that we build these points of overlap into our designs for each of these practices.
All ITIL practices are structured around what is known as the service value chain (SVC). The core focus of ITIL is delivering value to end users through IT services.
The SVC is a framework for outlining the activities that IT teams can perform in order to deliver value.
This is made up of six parts:
The service value chain applies across our ITSM efforts, but individual services and practices typically skew more towards some activities more than others.
For instance, service request management is most heavily weighted towards the delivery and support stage.
Nevertheless, we can apply the entire service value chain to our ITIL service request management practice.
This might look like the following:
ITIL’s overarching goal is to enable IT teams to identify demand for services and respond to these in a way that delivers value to the entire organization.
As such, within individual practices, we need to think about what value means to various stakeholders.
There are a few distinct strands of value we need to be aware of here in the context of service request management.
The first relates to the IT resources that are required to deliver services to users. Effective request management drives efficiency in this respect, including eliminating manual admin and communications tasks, as well as helping to rationalize resource allocation.
Similarly, service request management helps to deliver value for end users by lowering the barrier to accessing the services they need, thereby enabling them to carry out their own daily responsibilities.
So, we might operationalize this around metrics such as time to resolution for service request tickets.
We can also frame the value that service request management drives in terms of our wider goals for specific services. That is, if the service that users are trying to access meets its goals then this is a positive indicator for our request management workflows too.
These could include the likes of uptime, user satisfaction, resolution rates, capacity management metrics, and more, as defined in our service quality management practice.
As we’ve said already, one of the key characteristics of ITIL is that the constituent practices are highly interrelated, often in complex ways.
While we can’t predict every possible permutation of this, it’s vital to understand the other practices that ITIL service request management is most closely related to.
Two that we’ve seen already are change control and incident management, which both also seek to manage user interactions for defined service workflows. IT asset management is similarly intertwined with request management.
We’ve also alluded to service financial management. This is the practice that relates to the budgetary resources required to deliver our services. Request management has a role to play here, especially in terms of minimizing the costs associated with fulfillment.
Several practices under the service management category also interact closely with our request management efforts, including service level management, capacity and performance management, service desk, and service design.
Each of these is central to how we define goals and design request workflows to meet them as part of our normal service delivery.
ITIL emphasizes the need to work holistically in order to deliver value through our ITSM provision, with no individual practices operating in isolation. We’ll return to this idea later in this resource under best practices.
ITIL is a specific framework for IT service delivery. However, it’s not the only model we can use to structure our ITSM provision. As such, it’s useful to consider the relative pros and cons of implementing ITIL in the specific context of handling service requests.
To understand the benefits of ITIL thinking, we’re best served by considering the core principles that underpin it.
ITIL’s seven guiding principles are:
These provide guidance on how best to develop ITSM workflows that mutually benefit IT teams and service users.
By applying these principles to our service request management practice, we can expect the following benefits:
Ultimately, we can distill this down to the idea that ITIL provides us with a roadmap to design and implement ITSM workflows that deliver value to users while minimizing the costs incurred by the IT team.
However, implementing ITIL service request management is not necessarily a straightforward process. In fact, we’re likely to encounter a range of challenges that could impede our progress across financial, operational, human, and technical issues.
These include:
While none of these are likely to rule out ITIL request management entirely, they are all issues that we need to account for within our process design.
As such, we need practical guidance on the steps we can use to maximize our chances of success.
As we know, ITIL is not concerned with defining rigid processes or prescriptive structures for our ITSM practices. Instead, the priority is furnishing IT teams with guidance on how to design practices that are appropriate to their unique requirements.
As part of this, ITIL outlines several best practices for managing service requests.
As far as possible, request workflows relating to a particular service must be standardized. That is, the underlying business rules must be enforced consistently for each instance of a given service request.
Generally speaking, this means that the same outcomes should be reached regardless of which colleagues initiate and respond to the request. Or, in more complex cases, this might apply to individual colleagues that share a particular role.
Standardization is also a precondition for automating workflows.
Again, one of ITIL’s guiding principles is to optimize and automate service delivery.
There are a few key areas within service request management where we can most readily apply this. One important optimization strategy is providing users with self-service tools, enabling us to divert IT resources toward more pressing issues.
Opportunities for improving service request management include automatically authorizing requests based on computable values, as well as triggering certain communications or other basic follow-on actions.
Related to standardization is the idea that our practices should be simplified to the minimum number of steps required to effectively enforce business rules.
The element of request management where this is most pertinent is authorization and approvals.
It’s not uncommon for teams to get caught up in extraneous approval processes. In turn, this introduces additional costs and delays, thereby harming our service quality management and service financial management practices.
As such, our goal should be to outline clear responsibilities so that we can rely on the minimum number of approval steps that adequately enforce our business rules.
When designing service request solutions, it’s useful to think in terms of user experiences. The idea here is that a streamlined, effective UX will also feed other aspects of our service quality management, including efficiency, resolution rates, or other key metrics.
There are a couple of key aspects to focus on here.
The first is our request submission flow. This begins from the moment the user realizes they need to access a service. Our task at this stage is empowering them to identify the specific services that will meet their needs without our service catalog.
Following on from this, our priority is to provide a clear, guided experience for users to submit requests, typically in the form of ticketing platforms or dedicated form UIs.
During the fulfillment stage, user experience largely relates to resolution times, but we can also consider what steps we can put in place to ensure that users receive adequate communications as their cases progress, including leveraging automations.
One of the key ideas within ITIL service request management is continuous improvement. At a broad level, this means that we should seek out opportunities to make our request workflows more effective on an ongoing basis.
There are a couple of practical elements to this.
Firstly, it’s good practice to provide colleagues, including IT teams and service users, with tools to submit feedback on our service provision. For example, feedback or suggestion forms to help us identify opportunities to streamline workflows.
Secondly, we can more proactively seek out improvement opportunities. As a part of our monitoring and quality management workflows, the goal here is to identify areas where improvement is required and then use this information to design specific interventions.
Related to this is the issue of maintaining our service quality in the face of changing requirements, service demand, or other external factors. For example, planning for how we can scale our service request workflows to a growing user base.
Lastly, in order to effectively implement ITIL thinking, we must take account of the areas where constituent processes intersect. As we said earlier, the most relevant practices here include change management and incident management.
In both cases, part of the challenge is that users might submit information relating to a change or an incident as part of a normal service request without understanding the difference.
We can think more practically about how we can put measures in place to ensure that the appropriate process is initiated by these kinds of requests.
The key here is what’s known as workflow routing. Essentially, this means passing our submission to a separate practice if certain defined criteria are met, such as relating to a particular kind of configuration item or event.
We might even rely on automation here. Enabling our service colleagues to automatically create a new row in our incident management database based on a service request submission using an in-app action like a button-click.
Lastly, it’s important to be aware of the kinds of capabilities that are generally required for service request management. We’ve touched on most of these already and will cover each in more detail in a separate resource.
For now, though, we can simply outline the core tools that most IT teams rely on here.
One approach is handling all service requests within a centralized ticketing platform. A benefit of this is that we can provide service users and IT colleagues with a singular tool to manage requests, as well as related tasks like support, incident management, or device rentals.
As such, this can often be an attractive option, especially for teams with more simplistic ITSM requirements.
For more sophisticated ITSM portfolios, we’ll often rely on a service catalog. This is an internal tool where colleagues can access information about the services available to them and initiate requests.
Importantly, different colleagues might have access to different services, depending on their role and seniority. In any case, the goal is to outline what the service entails and what’s required to initiate it.
We might still handle submissions within a ticketing platform or with dedicated forms, depending on how closely we want to control our submission data.
Lastly, like all ITIL practices, our service request management needs effective tracking and monitoring in the form of admin panels, dashboards, and other tools, in order to consistently monitor key metrics, such as request volumes, resolution rates, or other defined KPIs.