How to Reduce the Number of High-Priority Incident Tickets

A fire is a high priority incident!
Share on facebook
Share on twitter
Share on linkedin

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…

Priority Incidents

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:

Incident Effects
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:

Impact
LowThe office printer isn’t working/my laptop seems slow to boot/I can’t get the battery out of my wireless mouse
MediumInternet is slow and it’s affecting my work/there’s smoke coming out of my monitor
HighNetwork failure/someone has stolen all the PCs in the building
Urgency
LowWill affect me and the business sometime next December
MediumWill affect the business later today or tomorrow
HighHas 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?

Sales Engineer at Freshworks

Sanjeev is a Product Evangelist with Freshservice (a Freshworks product), an easy to use ITSM solution based in the cloud. Prior to working with Freshworks, Sanjeev led a team of support engineers in a high-intensity service desk environment at Capgemini.

He's also a passionate trainer and enjoys creating his own non-conventional training content that includes memes, comics, and puns. In his free time, Sanjeev can be seen reading, writing, coding or playing; all on his computer. He's currently on a mission to ensure every customer support interaction yields the best possible experience!

Want ITSM best practice and advice delivered directly to your inbox? Why not sign up for our newsletter? This way you won't miss any of the latest ITSM tips and tricks.

nl subscribe strip imgage

More Topics to Explore

2 Responses

  1. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *