When the British Office of Government Commerce (OGC) published ITIL V2 (released in 2000/2001), the authors introduced the Service Request Management Practice as the Yin to Incident Management's Yang. Most readers know anything related to service not performing as designed is an Incident. If it is working, it is a Service Request. Everything we do in IT is a Service Request, Incident, or Project. What Service Requests are and how we manage them is the topic of this article. We discussed the Incident Management Practice in another article.
What is the Service Request Management Practice?
ITIL defines the purpose of the Service Request Management Practice as:
"To support the agreed quality of a service by handling all pre-defined, user-initiated service requests in an effective and user-friendly manner."1
For ITIL, correct vocabulary is everything
ITIL is specific with this definition. Agreed quality means that IT and business leaders have a signed document called a Service Level Agreement (SLA) for each IT service that defines service.
The SLA defines quality and IT performance metrics for efficiently running business operations.
Service Request Management focuses on pre-defined actions. Even before the service goes live, the project team, including users and IT members, discusses and documents potential Service Requests that users might initiate. Working off this, they create and document value streams and processes for dealing with Service Requests before launching the service.
Continuing, it is users that initiate most Service Requests. Service Request Management's primary goal is to make it possible for users to create their requests without IT human resources. As we will see, this Practice benefits significantly from automation, not only in the menu-driven initiation but in the descriptions of services and guidance necessary for valid Service Requests.
Why value streams and processes are essential for Service Request Management
Value streams and processes should be everywhere in IT. IT creates value streams specific to all products and services and defines activities, workflows, controls, and procedures to achieve agreed objectives. ITIL defines value streams as:
"A series of steps an organization undertakes to create and deliver products and services to consumers."2
Throughout this paper, we discuss Service Request Management, and the documented, tested, and monitored value streams that deliver service request results to users. Value streams are the secret to successful Service Request Management.
What is a Service Request?
Now that we covered what the Service Request Management Practice is, let us look at what the Practice manages — Service Requests, one of which is defined by the following:
"A request from a user or a user's authorized representative initiates an agreed service action as a normal part of service delivery."3
Who is the Requester?
Four roles submit Service Requests:
- A User is someone that uses services4 as part of their job requirements and may submit a request to accomplish business requirements.
- A Customer is a person who defines the requirements for service and takes responsibility for the outcomes of service consumption (i.e., department head).5 They may submit a request to improve the service.
- An Authorized Representative is someone tasked with requesting on behalf of a Customer (e.g., an admin assistant).
- A Supplier can make requests. For example, requesting that IT download a security patch.
Service Request examples
To understand them better, the following are some of the hundreds of Service Requests:
| Request | Example |
|---|---|
| Reset my password | Resetting passwords is the most common Request. The user will probably say this is an Incident because their password is not working. If other users can log in, then it is not broken, but it is a priority one request. |
| New employee setup | Onboarding requires the coordination of many IT departments. It is the new employee's first encounter with IT. You want the impressions to be a 5 out of 5 rating. The new employee not being ready on day one means a loss of productivity (i.e., revenue loss) and a low impression of IT; but if done right, the start of a great relationship. |
| How do I? | A user not knowing how to do something brings loss of productivity (i.e. revenue), so this is also a high priority! Also, a great source of new online FAQ articles. |
| Request for advice | Usually a low urgency. A good source for online articles. |
| Request for approval | Depending on the security and financial requirements, getting the right approval source is critical. Approvals could be for a laptop, software, training, etc. The IT Asset Practice usually provides the proper routing for approval. |
| Basic information | Users have lots of questions. These questions are a great opportunity to develop knowledge articles for service desk agents and users. Whenever the Service Desk agent is stumped, create an article as part of continuous improvement. |
| I need access to | There are many services your company offers but requires permission (e.g., printers, applications, etc.). In addition, many access actions require approval from Change Enablement through a Standard change. The Service Desk creates a pre-approved Standard change and attaches it to the request. |
| I want the latest version of this application | There are times when application upgrade projects miss some users. The Service Desk easily handles this request with a Service Request and attached Standard change. |
| Direct me to the right place | In many organizations, when a user does not know where to go, they call the Service Desk. Why disappoint? Incorporate HR, Finance with a robust request system to take the guesswork out and increase efficiency while saving money. |
What is the difference between a Service Request and an Incident?
ITIL defines an incident as:
"an unplanned interruption to a service or reduction in the quality of a service."6
We briefly discussed Request/Incident differences earlier. It is of utmost importance that IT accurately logs the issue to the right type of record. An Incident means something is broken, and IT is not delivering the service as agreed. Incidents are symptoms of an underlying problem. In the Incident value stream, all incidents must link to a problem. Finding and resolving the underlying cause of a problem is the responsibility of the Problem Management Practice. Once fixed, all related Incidents are fixed and should not happen again.
If the service is not broken, it should be a Service Request. You can see that there might be confusion when it depends on the point of view. The user says my password is broken (i.e., Incident). The Service Desk says the password security system is working perfectly; therefore, you entered your password incorrectly (i.e., Service Request), and I have reset your password, please try it again.
In most organizations, Service Requests and Incidents are created at the Service Desk as the single point of contact between users and IT. This is by far the most efficient use of resources but may blur Incident/Request differences to outsiders.
There are many Service Request Management benefits
The actions required to address user requests, manage and track the workflow, monitor the response rate to request priorities, monitor performance, and look for improvement opportunities, is a full-time job. Attending to users' needs to keep them productive has significant financial value for any business.
Using Service Catalogs for standardization
A valuable part of Service Request Management is having a complete list of services available to the business. The Service Catalog Management Practice has the following purpose:
"Provide a single source of consistent information on all services and service offerings and to ensure that it is available to the relevant audience."7
When we speak of more than one catalog, we mean different views for different users:
- User view: This view provides information on service offerings that can be requested and on provisioning details.
- Customer views: These views are for business leaders showing service levels, financial, and performance data.
- IT to IT customer: These views provide technical, security, and service delivery information.8
The user view is called the Request Catalog because users can browse for what they want, order it, and have it delivered to their door (ala Amazon-like performance). Behind the scenes, Service Request Management drives service delivery automation, encouraging users to request goods and services from the Catalog.
Step-by-step tracking through the Request value stream
Defining value streams, tracking the completion of steps, and reporting is the best way to improve. Everything we do in ITIL boils down to continuous improvement.
A lot can happen between the user submitting a request and the ticket closing. Track enough requests, in enough detail, and you will see patterns. Look at the exceptions, and you will see variables you never noticed before.
The tracking and reporting provide value stream owners with the data they need to become efficient. The goal is to set business expectations so that when they hire a new employee, IT will have everything 100% ready and tested on the day they arrive.
What is the typical Service Request fulfillment workflow?
Submitting and receiving
| Method | Description |
|---|---|
| Service Catalog |
The Service Catalog (Request Catalog) may be the most efficient because you can pack it with much information and automation. For example, New Hire. Imagine all the options within a form, such as a name, the new position, manager, start date, type of laptop, and access to various applications.
Each department could set up a standard menu of services a typical new hire should have. They would simply click the box for a standard setup.
Standardization is the key. Behind each menu item are descriptions of how to do it. When the hiring admin saves the form, a new hire process-driven engine does all the rest.
|
| Service Desk | This is the traditional way. One phone call to the Service Desk and an agent opens up a new hire template, asks the questions, and fills out the template. This is the most expensive way, as two people are connected for a long duration. Typically, the Service Desk agent creates one ticket (i.e., new hire), and from that, multiple requests propagate for all the different IT departments and actions. When IT completes all the sub-requests, the primary ticket closes and lets the business know. |
| Web Interface | You could, through a web interface, complete a new hire template. Not as much depth as is possible with using the Service Catalog because they would have to know where to navigate. |
| Request for Change (RFC) | Request for Change (RFC) comes from the Change Enablement Practice. With many change projects, several users may need a training class or to watch a video before they get a new service. The project team could create a batch of Service Requests to notify users, track their completion, and turn on the service when complete. |
Verify the Request
Of course, during this introduction step; someone must determine if the Service Request is a Request or if it is an Incident. If it is not a Request, you should have an easy process to change the Request ticket into an Incident.
What is the Request category?
There must be a process to determine the category of the Request. Every request should have a correct category defining the Request and related service. Dropdown menus ensure correct types. Typical categories of Requests might include:
- Service: Email service, SAP Purchasing service
- Activity: Service value chain activities include plan, improve, engage, design and transition, obtain and build, and deliver and support
- Type: New hire, access, Operational Level Agreement (OLA)
- Function: Organizations and people, information and technology, partners and suppliers, and value streams and processes
-
Configuration Item (CI) Type:
- Service models
- Service packages
- Service resource assets
Assessment to understand the request
What is the Request priority?
Requests have priorities. Priorities consider both the urgency of the Request and the impact on the business. Priority assists the assignee in determining the order in which they resolve the Requests in their queue. Request priorities are similar to Incident priorities (i.e., P1, P2, P3, and P4). What is different is the associated time to complete the task. The SLA lists the expected time for each priority.
Requests must be authorized
Authorization is necessary before work can start. The Service Desk has approval authority for the vast majority of Requests. Other approvals might come from finance, IT Asset Management, or the requester's manager.
The next step is fulfillment by an assigned technician
A Service Desk agent always owns the Request. If they escalate, they still own it, and a higher-level technician does the work.
Anytime the Service Desk escalates from Level 1 to Level 2 or 3, both parties audit the Request to verify agreed documentation standards. Audits are part of continuous improvement. Insisting on high documentation standards at all levels is a priority of continuous improvement, because only when all fields are accurate is it possible to see patterns that lead to improvements.
Request completed
When completed, the software notifies the user, triggers an audit of the requested document for accuracy, and if needed, enters suggestions for improvement into the Continuous Improvement Register (CIR).
ITIL Service Request vs Change Request: What's the difference?
Since the beginning, we have looked at Service Request Management from many angles. There is another closely related activity associated with certain types of changes. We are referring to the Request for Change (RFC).
Change Enablement is the ITIL Practice that authorizes changes to the live environment. ITIL says:
"The purpose of Change Enablement is to maximize the number of successful service and product changes by ensuring that risks have been properly assessed, authorizing changes to proceed, and managing the change schedule."9
ITIL defines a change as:
"The addition, modification, or removal of anything that could have a direct or indirect effect on service."10
When Request Fulfillment requires permission to change the live environment, Request Fulfillment asks permission of Change Enablement. This is done through a Request for Change (RFC), although not just any change but a Standard Request for Change.
"Standard changes are low-risk, pre-authorized changes that are well understood and fully documented, and can be implemented without needing additional authorization."11
Sample value stream for Request Fulfillment
| Steps | Action |
|---|---|
| 1 | The user contacts the Service Desk to request a new laptop. |
| 2 | The Service Desk agent determines proper authorization. |
| 3 | Create a Service Request. |
| 4 | Create a Standard RFC for a computer and digitally attach it to the Service Request. |
| 5 | Escalate the Service Request to the desktop team for fulfillment. |
| 6 | The desktop team completes the action, updates the Configuration Management System (CMS), and resolves the Request. |
| 7 | The Service Desk closes the Service Request. |
Optimizing Service Request integration
ITIL has created 34 Practices for organizations to optimize IT to support the business. All the Practices are designed to work together. When anyone is missing, the quality of business support diminishes. Each Practice contributes its specialty to other Practices and receives something in return.
The following table highlights the contribution of Service Request Management with the other Practices:
| Practice | Inputs and Outputs |
|---|---|
| Incident | If it is broken, it is an Incident. Not broken, it is a Service Request. |
| Change Enablement | If the Request is a configuration item going into or out of the live environment, it requires a Request for Change (RFC). More specifically, a Standard change. |
| Configuration Management | If a Service Request meets the qualification of a Configuration Item (CI). Request Management registers it with the CMS. |
| Service Catalog | The Catalog holds all the services that users can utilize if authorized. Users go to the request Catalog to start the Service Request value stream. |
| Service Level Management | SLM and their Service Level Agreements (SLAs) define Request priorities and the agreed target time to complete by service priority. SLM also requires Operational Level Agreements (OLA) for each Service Request category. The OLA defines how each IT department contributes to meeting the SLA goals. |
| Continual Improvement | The Continual Improvement Practice supports Service Request Management to continually provide greater value for the business by reducing waste and costs and increasing customer satisfaction. |
| Information Security | Information Security Practice defines the security requirements to be met for each type of Service Request. |
| Knowledge Management | Knowledge Management supplies the Service Knowledge Management System (SKMS) to store all searchable Practice documentation and performance metrics in support of the Practice. |
| IT Asset Management | IT Asset Management keeps track of the whole lifecycle of IT assets. When Request Management transfers IT assets to business users, IT Asset Management wants to know of the asset change. |
| Service Desk | The Service Desk is the Single Point of Contact (SPOC) for users to request services and service changes. |
| Monitoring & Event Management | Supports Request Management in the step-by-step tracking of the delivery processes of a Request. |
| Release Management | Stores thoroughly tested releases in a secure location. |
| Deployment Management | Provides guidance and tools for moving releases to the live environment. |
Service Request Management is an essential Practice
In conclusion, no other ITIL Practice has as great an opportunity to impress users as Service Request Management. It is the perfect Practice for continuous improvement, coordinating all IT departments, and supporting the business.
Footnotes:
- IITI® Foundation ITIL 4 Edition, Axelos Limited, 2019, p. 156
- Ibid, p. 32
- Ibid, p. 156
- Ibid, p. 10
- Ibid, p. 10
- Ibid, p. 121
- Ibid, p. 137
- Ibid, p. 138
- Ibid, p. 118
- Ibid, p. 119
- Ibid, p. 119