ITIL defines priority as impact X urgency, which means that the priority of an incident is determined 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 a priority to an incident based on the impact and urgency. But end users don’t care about this – if they have an IT issue their perceived priority is usually “high.”
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 behavior 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 – 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 ultimately determine the priority with which their issue should be resolved?
The downside of involving the end user
If I’m an end user and I need my issue fixed ASAP, then I’m likely to go with…
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. With “high” being the option of choice. It really doesn’t make a difference for 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 issue!
How do we solve this?
One way 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? 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.
Adding help text, or a tooltip, right next to the impact and urgency fields should help the end user determine the right option – if only for impact, as the desired urgency might always be problematic. You can also give example situations that help them decide. Labelling the field as something that the end user 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:
|Low||The office printer isn’t working/my laptop seems slow to boot/I can’t get the battery out of my wireless mouse|
|Medium||Internet is slow and it’s affecting my work/there’s smoke coming out of my monitor|
|High||Network failure/someone has stolen all the PCs in the building|
|Low||Will affect me and the business sometime next December|
|Medium||Will affect the business later today or tomorrow|
|High||Has already affected the business (CODE RED everyone!)|
This sheet can be attached to IT equipment, displayed on boards, or even in the ticketing form itself. It’s up to you to get this in front of the eyes of your end users.
You can also do backend tweaks
To help prevent all self-service-logged tickets looking like urgent and priority 1 tickets, raising a high-urgency ticket could be limited to the service desk team. And this follows the logic that if the issue really is urgent, then the end user will most likely call rather than logging their issue via self-service and waiting, and waiting…
There you go! A few incident priority tips from me. What would you offer up?