Why You’re Drowning in ‘High-Priority’ Tickets – and How to Make it Stop
As per ITIL, priority is a factor of impact and urgency, which means that the priority of an incident is determined both by the effect it has on business and the time available for repair (or avoidance) before the incident’s impact is felt by the business. A priority matrix is a useful tool which lets service desk agents assign priority to incident tickets based on their impact and urgency. But end users don’t care about this — if they have an IT issue to report, they usually perceive it as high priority.
So how can service desks help themselves by reducing the number of high-priority tickets in their queues — allowing them to focus attention on the real priorities?
Having fewer IT failures that cause high-priority incidents is the obvious (and flippant) answer, but seriously — how can we alter end-user behaviour to make the lives of service desk agents a little easier?
What can end users influence?
Many, if not most, of the service desks I’ve worked with don’t let end users choose the priority of the incident ticket while they log their issue, but they do trust the end user to select the impact and urgency. In fact, impact and urgency can be commonly seen on self-service end-user submission forms (within service desk tools) these days.
Through this, the service desk hopes to accurately determine the priority of the incident tickets — usually through their priority matrix. And the higher the impact and urgency, the higher the priority. It sounds like a solid plan, doesn’t it?
But are end users best positioned to determine the priority with which their issue should be resolved?
The downside of letting end users influence the priority of tickets
If I’m an end user and I need my issue fixed ASAP, then I’m likely to go with this:
Whether it’s priority, impact, or urgency — it doesn’t matter — I’m going to choose the options I feel will get my issue resolved as quickly as possible. This makes ‘high’ the obvious choice. It really doesn’t make a difference to me, the end user, and I’m unlikely to think of my issue in the context of all the other, more important issues the service desk will be dealing with.
So the service desk receives lots of relatively simple tickets logged as high priority. But an office printer issue (unless the printer’s on fire) is rarely going to be a high priority!
How do we solve this?
One way to address this is for most expected issues, and the affected service(s), to have a standard priority that overrides what the end user states. But if this approach is used, why ask the end user their opinion at all? All it does is poorly manage end-user expectations.
My alternative is pretty simple. Let end users know what these fancy words actually mean — end users are never going to have heard of ITIL, let alone be ITIL certified. So, if you’re going to ask end users to state the impact and urgency of their issue, configure or customize the capture form to make things easier for the end user and the service desk alike.
The urgency field is likely to always be problematic, but it would be useful to add help text, or a tooltip, right next to the impact field to help the end user choose the most relevant option. You can also provide example situations to help them make relevant choices. Labelling the field as something that the end user better understands, instead of plain old ‘impact’ and ‘urgency’, is also helpful. Here’s a simple example:
You can also choose to rename the available options, from low-high, to something better suited to your needs.
An alternative to this is to provide end users with an impact and urgency cheat sheet. The example below is intentionally a little comical, but who doesn’t need an extra smile when reading ITSM blogs:
This sheet can be attached to IT equipment and displayed on boards, or even in the ticketing form itself. It’s up to you to get it in front of end-user eyeballs.
You can also do backend tweaks
To help prevent all self-service-logged tickets look urgent and priority 1, the ability to raise a high-urgency ticket could be limited to the service desk team. This follows the logic that if the issue really is urgent, the end user will most likely call rather than log their issue via self-service and wait patiently.
So there you go — a few incident priority tips from me. Do you have any more to suggest?
Blog originally posted on ITSM Tools.
