Request Management
What is request management?
Where incidents are typically viewed as interruptions to regular service (i.e. things going wrong), request management is responding to requests from the business for knowledge or new services (e.g. a new laptop or 'how do I…' queries).
Request management focuses on handling service requests from users in a structured, efficient, and user-centric manner. Service requests can include anything from password resets to access requests or software installations.
The main goal of Request Management is to ensure that these requests are handled in a timely and organised way to maintain high user satisfaction.
Some examples of requests
Account setups
Password resets
Access requests (changes to access rights for users)
Software installations
New hardware (laptops, phones, etc.)
Training
Don't we already have Incident Management for that?
Yes, kinda, but here we are explicitly calling out request management as a related but separate process for handling routine, procedure-driven requests for standard offerings. In a more mature IT environment, we should be pushing for a higher % of requests than incidents; we want to be servicing the customer, not responding to faults.
Incident Management focuses on resolving incidents, which are unplanned interruptions or reductions in the quality of IT services. In contrast, Request Management deals with service requests, which are routine and planned requests for information, access, or standard changes. You can optimise resources by separating these two processes, either logically or physically, as activities within a team. For example, having dedicated resources focusing on requests can ensure that incident resolution isn't delayed due to routine service requests and vice versa.
I'm going to continue to use Incident Management for requests.
Do things how you think best, but being able to separate incidents from requests, clearly articulate your services to customers, and create clear procedures for service requests can be valuable.
Either way, you'll still need to deal with many of the challenges in this chapter, so don't desert us yet. It is most likely that your incidents and requests will be processed through the incident management/ticketing system but identified clearly as being different and directed to different queues and workflows.
The Request Management Process
Much of what was discussed under Incident Management will apply here to request management. As recognised, they are similar but serve different purposes.
Below is a sample process map.
Step | Description | Summary |
1 | Record Request | A record is made in the Incident Management system but clearly labelled as a request. |
2 | Classification | The request is assessed and classified and, if necessary, sent for approval by the appropriate authority. |
3 | Assign & Fulfil | Once approved, the request is assigned to the support team, which then fulfils the request. |
4 | Contact Customer | Once the request is completed, the customer is contacted, and the outcomes are shared. |
5 | Close Request | The request should be formally closed only once the customer has agreed that their request has been completed satisfactorily. |
Key Points
Remember: The Help Desk are the single point of contact for all requests
This stops customers from contacting other teams, queue jumping or getting confused about processes, just like with the incident management process.
Automate where possible to enable frictionless processes
Automating the service requests via a portal or other method can clarify the IT services to customers and help speed up the classification & approval steps. The approval process is crucial. If you can automate that part of the process with your tooling, you should. It removes the back-and-forth bouncing of a request, slickens the process and forces everyone to be clear about who can approve what in an organisation because it has to be configured as a workflow.
Push as much request fulfilment towards the Helpdesk as possible
Requests should be routine and repeatable. That means they can be easily documented and trained. This speeds up the resolution, simplifies the process and frees up more experienced staff for higher-value tasks.
Start small and grow
Start with the most common requests, and build out from there. You don't need to begin by capturing all types of requests and processes. Maybe pick one area, software or new account requests and go from there. Perfection is the enemy of progress!
Be clear on Service Level Agreements
Ensure the SLAs for services are published in your service catalogue, clarifying the turnaround times for certain customer requests. That's why we are tying requests to SLAs to the service catalogue. Making sense now?
Don't be ambiguous about services and standards
In the absence of clearly published services and processes, the customer will make up their own, and this will potentially cause trouble. For example, requesting hardware or software that duplicates existing options or does not fit with the organisation's security. When you are clear about the options, deviation from them becomes much harder for those rouge elements in an organisation who like to work in isolation.
KPI Suggestions
Here are a couple of suggested KPIs that can give us a sense of how the request management process is working.
Request Volume: This KPI measures the total number of service requests received over a given period of time. This helps to identify trends and areas where additional support may be required.
Request Resolution Time: This KPI measures the time it takes to resolve a service request from the time it was submitted. This helps identify bottlenecks in the process and ensure that service requests are handled in a timely manner.
Customer Satisfaction: This KPI measures the satisfaction of end users or customers with the service request management process. This can be measured through surveys, feedback forms, or other means of communication.
Service Request Backlog: This KPI measures the number of open service requests that have not been resolved. A high backlog can indicate a capacity or resource issue and may require additional support or process improvements.
Service Request Reopen Rate: This KPI measures the percentage of reopening service requests after they have been resolved. A high reopen rate can indicate that the service request was not fully resolved or that a recurring issue needs to be addressed.
Identifying Service Requests
Once you know your process, you'll need to compile a list of services offered by IT, either directly or indirectly (e.g. third-party services).
This should include technical and non-technical services. It should be a list of everything the IT team offer. It can help all kinds of decision-making, ownership allocation, roles & responsibility clarities, clarifying to senior execs exactly the scope and costs of IT services, etc.
At this time, it is ALL services, regardless of whether or not they are to be included in the service catalogue for service requests.
For each service, define its scope, eligibility criteria and any associated costs, if applicable.
