Quick Hacks | How to define Priority?

  • 28 June 2021
  • 4 replies

Userlevel 7
Badge +9

How often have we all fell into the rabbit hole of endless "high-priority" tickets? Who actually defines the priority or an incoming ticket and how can we effectively prioritize them?

Here's a quick ITSM Hack from our very own Freshservice Team that can help in answering this very question!



4 replies

Do we have some tangible best practices to share on how we can make priority setting work by design?

I’m thinking along the lines of business rules for forms, using quantitive validation of urgency and impact, e.g. # of users affected, etc. I think this would be a good topic to start building on. 

Userlevel 7
Badge +9

@joey.domhof thanks for bringing this up! It’s indeed a great idea to collect quantifiable data that will help in differentiating between urgent and important tasks and it’s indeed a very fine line.


Would like to hear from @manns@BarclayRae@vishnu.selvaraj and others from the community!

Userlevel 4
Badge +2

Impact and Urgency have long been used as a simple tabular calculation to define levels of priority and to set out particular routes and targets for resolution and fulfilment.

The challenge here is on how to use context, for setting out and then applying suitable levels of priority. What is urgent today my not be tomorrow, or on a particular time of day etc. Setting out business-based context is the key to making this successful, and too often these impact/urgency matrices are used inflexibly and too prescriptively, when common sense and context would deliver a much better result and experience for consumers. 

Userlevel 7
Badge +10

A priority matrix is commonly used to calculate priority - a Freshservice version is shown below - with organizations deciding what H/M/L are for urgency and impact. But to echo @BarclayRae’s point, so much depends on context. Especially when priorities are simply applied to incident types such that categories or similar influence priorities. The example I usually give is that if printer issues are P4 but the printer that’s affected is critical to business operations then it’s likely viewed as a P1 by business operations.

There’s also the employee/end user perspective to consider - especially where IT has created priority levels based on what they know and think rather than canvasing the opinions that really count. So the standard priority levels might be off the mark too, or need updating to reflect changes to ways of working, e.g. the priority when it’s a home worker.