How to prioritize tickets in software companies


Priority. Urgency. Severity. It doesn’t matter what you call it. What’s important is how you classify tickets so that your organization knows how to address them and can leverage ticket classification to learn through metrics and analysis.

We have seen all sorts of approaches to classify and prioritize tickets: impact to the customer, number of impacted customers, order in which they are received, customer relevance, complexity and scope, political urgency, priority point algorithms, and on goes the list. Naturally, we have also seen various combinations of these approaches. Our conclusion? Most complex criteria end up causing more disruptions than helping the process.

Complex criteria usually rely at least in part on someone’s judgment. When you add business aspects for B2B products, or services and personal aspects for B2C solutions, the knowledge of external factors easily exceeds all measurable parameters that companies have within their organizations.

We often see companies who try to work with as many as 10 priority levels (we have even seen scales with one hundred levels!). Also, many customer services solutions in the market today come pre-configured with four levels of priorities, such as low, medium, high, and urgent. Analyzing the first case, it’s easy to think “how would I know the difference between a priority 6 and a priority 7?”. And in the case of using “Low” through “Urgent,” where theoretically you could work through a combination of factors such as “impact” and “workaround availability,” we end up seeing little benefit in differentiating a “high” priority ticket from an “urgent” ticket.

Many software companies use a pragmatic approach that we see as both practical and informative—the use of just three levels of priorities. Usually these are put simply as “high, medium and low,” which still gives people an intuitive feeling on how to classify issues between these three categories. Moreover, it’s easy to create clear parameters for analyses and classification. After working with many of these software companies, these are the classification parameters that we like the most:

  • Priority one – These are the “show-stoppers.” These are product defects or incidents that prevent your customer from performing a critical task that your product or service is supposed to help them with.
  • Priority two – These are “high impact, with a workaround.” In most cases a reasonably knowledgeable customer services agent can tell right away that a given issue creates a significant problem for your customer, but that they have a way to work around the problem.
  • Priority three – These are the “low impact items.” Agents identify those by simply thinking “yep, this issue should not be there, and we should fix it, but it’s not really hurting anyone.”

These simple, straight-forward categories, coupled with the order in which the tickets are created, are usually enough to provide a robust prioritization process that can be applied even to the most complex operations.

As with most processes and policies, ticket prioritization criteria should not try to cover 100% of the foreseeable situations. Instead, exceptions should be addressed by management on a case-by-case basis. It is quite reasonable to add room to the above classification so that you can address aspects such as the volume of customers that may be impacted by an issue, a possible political issue that an item might create, or a damage to the image of the company for external reasons—however, it doesn’t have to be addressed by complex algorithms or half a dozen specific fields on a ticket. Just saying “we better bump this one up” occasionally without too much discussion is perfectly normal!

What about the backlog? Ah, the backlog! We will leave that to another post…

Agree with the above? Have a different opinion? Have a particular issue with it and would like to exchange some ideas? Please leave a comment! We’ll be happy to learn or share more information and insights about the topic.

Leave your comment