Password reset.
Order a new laptop or smartphone.
Move a workspace to a new location.
Ask a question about the ERP solution in use within the organization.
These are all common, everyday interactions between a user and an IT organization, right?
These interactions are known within service management as “service requests”. ITIL® 4 defines[1] a service request as “a request from a user…that initiates a service action which has been agreed as a normal part of service delivery”.
The act of making a service request seems to be simple enough. It’s a call to the service desk. Or perhaps, it’s a click or two on a web portal. And soon, that service request has been registered and processed…and perhaps, depending on the nature of the request, it’s even been fulfilled within just a few minutes.
Those making a service request may not appreciate what happens behind the scenes. But that is what a well-planned, designed, and implemented service request management practice does for an organization, its service consumers, and its service providers. It makes requesting and managing service requests simple enough.
But the importance of an effective service request management (SRM) practice is often overlooked…even taken for granted.
Behind the scenes
The Service Request Management practice provides a standard way for users to make requests of a service provider to provide resources or take actions that are an agreed part of the normal delivery of a service. SRM is one of the most visible service management practices within an organization.
Service requests all follow the same basic structure. First, the requester’s identity is confirmed to ensure that only those that are permitted to make a service request can make a request. The specifics of the particular request are then analyzed.
Some requests are quite simple and require minimal effort for fulfillment, while other requests may be more complex, requiring contributions from several teams or involving several systems. As part of that analysis, what the requester is entitled to request is confirmed, along with any needed authorization (from a security perspective) or approvals (from a budget perspective). Finally, the request is fulfilled.
For example, a service request involving software may have to confirm that there are sufficient unassigned licenses available for fulfilling the request, and if not, trigger procurement of additional licenses. A service request for hardware, like a laptop or smartphone, may involve third parties to fulfill the request. A request for system access requires that SRM confirm that the requester is in fact authorized to access that system, and if so, provide only the type of access to which the requester is entitled.
So, regardless of whether it’s asking for a new smartphone, resetting a password, or asking a question, the basic structure of a service request is always the same. But that’s just the basics. The fact is that not all service requests are the same.
How to make it look simple
There’s so much going on behind the scenes than what may meet the eye when it comes to service requests. Behind the scenes, even the simplest service requests often involve several steps. What is the key to making it look simple?
The answer is request models.
A request model is a pre-defined method for fulfilling a specific type of service request. In other words, for any request, there should be a pre-defined and agreed approach, or model, for fulfillment. This means that a request model must:
Define the inputs and outputs of the model – What information is needed to fulfill the request? What outputs result from processing the request?
Define what information is needed from the requester – In addition to a name and userid, additional information may be required, such as location, manager name, or contact information.
Identify what individuals or teams are involved – Who takes the actions required for fulfilling the request?
Define the time frames for fulfilling the request – How much time is needed to fulfill the request? What should be done if it’s taking longer than defined for fulfilling the request?
Define and design how the request may impact other service management practices, such as supplier management, access management, change enablement, or others – No service management practice can be successful by existing in a vacuum. A service request may trigger an action to order a new laptop from a supplier or cause the execution of a standard change. Performance targets and expectations for SRM should be defined and agreed in Service Level Agreements (SLA). Recognizing how service requests interact with other service management practices prevents unanticipated delays with fulfilling requests.
Specifically define how the output will be delivered to the requester – Some outputs can be delivered electronically, like software. Other outputs require a physical installation. Some may require both.
Consider if automation can be used to fulfill the request – Many service requests can be fulfilled without direct human interaction.
A little planning and design goes a long way
Sounds like a lot of work, doesn’t it? The fact is that to deliver the outcomes from a SRM practice that seems simple for the user does require some planning and design. There are a number of benefits that result from planning and designing of request models.
Improves coordination between teams – While many requests may be fulfilled by a single technician, some requests actually involve more than one team for fulfillment.
Delivers a better user experience – Users have confidence that they will get what they need in a timely, friction-free way.
Helps further identify opportunities for self-service and automation – This is a win-win for both the end-user and the fulfillment teams. The end-user gets her requests fulfilled on a near-real time basis. The providing organization, no longer needed to manually fulfill such requests, can devote more time to fulfilling requests that are more complex.
Provides measurability – One of the results of defining is that fulfilling such requests becomes consistently measurable. The ability to measure then opens possibilities for continual improvement, as well as the ability to set reasonable expectations regarding fulfillment – for both the end-user and fulfillment teams.
Don’t take service request management for granted!
It can be easy to take service request management for granted. But SRM is a way to illustrate the business value of the service provider. Here are some things to do to ensure that SRM isn’t being taken for granted, while continually improving the value of SRM.
Regularly publish performance reports – Illustrate just how much work is being done by SRM. Capture and publish agreed key performance indicators, or KPIs, such as the number of requests and the average time for fulfillment of requests being managed through the practice. By doing so, both the user community and the IT organization will have a shared understanding of the value that SRM provides.
Identify top 5 requests logged by service desk agents – This will help identify further opportunities for improvement and potentially automation.
Periodically audit current request models – Do existing request models accurately represent the current criteria for approvals and authorizations?
Service Request Management may seem simple to the user and to the organization. But having a well-designed and effective SRM practice is not only critical for service management implementations, but it is also important for the performance of the overall organization. Don’t let your organization take SRM for granted!
[1] ITIL Foundation, ITIL 4 Edition, p 195
About Doug Tedder: Doug Tedder is the principal consultant of Tedder Consulting LLC, a service management and IT governance consultancy. He is a recognized ITSM thought leader and holds numerous industry certifications ranging from ITIL®, COBIT®, Lean IT, DevOps, KCS™, VeriSM™, and Organizational Change Management. Doug is an author, blogger, and frequent speaker at local industry meetings and national conventions.