Let’s talk about high-priority incident tickets. ITIL defines incident priority as impact x urgency, which means that the priority of an incident ticket 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 in IT service management (ITSM) which lets IT service desk agents assign a priority to incident tickets 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 IT service desks help themselves by reducing the number of high-priority incident tickets in their queues – allowing them to focus attention on the real priorities?
Having fewer IT failures that cause high-priority incident tickets 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 with incident tickets?
Many, if not most, of the service desks I’ve worked with don’t let end users choose the priority of the incident tickets 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 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 incident 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 incident ticket issue?
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 of their incident tickets.
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 incident ticket priority 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:
Impact | |
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 |
Urgency | |
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 incident 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 ticket priority tips from me. What would you offer up?
This 2017 IT service desk article was updated in 2024.
Please use teh website search facility to find more helpful ITSM and IT service desk articles on topics such as developing team members, customer satisfaction, knowledge bases, ticketing systems, improving business processes, measuring customer experiences in real-time, IT support teams, the IT service desk as a single point of contact, service portals, reducing resolution times, service management processes, service management systems, managing software changes, service delivery, setting priority levels, managing ticket volumes, resolving incidents using best practices, and ITIL processes or practices.
Sanjeev NC
Sanjeev NC started his career in IT service desk and moved to ITSM process consulting, where he has led award-winning ITSM tool implementations. Sanjeev was also a highly commended finalist for Young ITSM Professional of the Year in itSMF UK’s annual awards. Sanjeev is currently creating IT content for Stitchflow, a platform that takes a visibility-first approach to IT automation.
2 Responses
Great thought Sanjeev ! I second you with respect to providing tooltip which would basically educate the end users in order to choose the appropriate option, ultimately leading to lesser high priority tickets.
Thank you, Padma! If the end users don’t do something, it doesn’t mean they don’t know. it means we haven’t told them how to 🙂