Request fulfilment: Asking for a better service desk experience
Are there any self-contained lessons I can implement from ITIL v3 without having to undertake a costly reorganisation? Is there any way I can better analyse the value of my service desk?
These questions are being asked by an increasing number of IT and service desk managers. Thankfully some concepts are so intuitive that whatever position you are in it is well within your interest to take a serious look.
These days most people know the difference between an incident and a problem: they are concepts that have escaped the confines of ITIL and successfully permeated IT culture. Many organisations that have yet to implement ITIL in any formal way have recognised the benefits of drawing this distinction in their day-to-day work.
The reasons are obvious: incident and problem management are simple processes to understand and are equally as intuitive. What is more, they offer immediate benefits to support staff and management trying to work under increased pressure.
Another process that has the same magic qualities but appears to be far less ubiquitous is request fulfilment. The ITIL v3 framework does an excellent job of highlighting this more than in past versions and it can be a valuable and quick lesson to digest for all IT departments.
The scope of a ‘service request’ can vary greatly from organisation to organisation but the basic concept remains the same – a request from a user for advice, information, or provision of a standard service. Despite this being an obvious distinction from an incident (unplanned degradation or outage of an IT service) many IT departments still log and report on requests using the same key performance indicators (KPIs) as they do for incidents.
When you formally acknowledge that your service desk is dealing with requests as well as incidents you can begin to produce better reports based on more focused KPIs. In my experience this almost always results in more positive results for the service desk – and if you have a proven tool, such as our SupportDesk ITSM solution, you should find it includes reports as standard that can show performance against a sensible set of KPIs at the touch of a button.
As request fulfilment is strong on the common-sense factor there is often little resistance from users. Few would argue that a request for a brand new service should be handled in the same way as the failure of an existing one. And once users understand that making this distinction means more focused incident management and a separate agreed process for request fulfilment with its own service and operational level agreements, this should reduce any resistance even further.
In order for request fulfilment to work best you must clearly define what sorts of requests you are able to handle and, equally as importantly, what are the SLAs covering them. Some service desk tools, including House-on-the-Hill’s SupportDesk, will allow you to easily set a separate SLA structure for request fulfilment based on the types of service requests available to the user rather than impact or urgency as with incidents.
Being such a useful concept, I believe request fulfilment deserves to be understood in broader IT culture than I find currently. Perhaps it will one day be as omnipotent as incident management, but in the meantime I recommend staying ahead of the pack by acknowledging it now.
