All about priorities and severities

A big thank you to Mark Schnegelberger for suggesting this topic.

Vendors frequently define priority and severity levels for cases and bugs, and assign different treatments to different levels. The idea is that some issues are more urgent, or more important than others, and should be treated faster.

Semantics: Priority vs. Severity

Some vendors adamantly maintain that priority captures the customer’s view, while urgency refers to the internal (vendor’s) view. Others, just as adamantly, maintain the opposite. There is no general agreement on the respective meanings of priority and severity, so expect to clarify your definitions for your customers.  In this discussion, we will use priority to mean the customer’s view and severity as the internal view.

What are priorities used for?

The priority of an issue captures its impact on the customer, hence the urgency of a resolution. Priorities are useful to define what cases get handled first, and, sometimes, by whom. They can also be used to govern the frequency of updates, escalations to higher levels of management, and the availability of certain types of fixes.

Do I need priorities at all?

Not all support organizations need priorities. If your customer issues have roughly similar importance, and especially if they don’t reach critical levels, you may not need priorities.

How many priorities do I need?

Most organizations have too many priority levels. In many support organizations, simply distinguishing between urgent and normal will do; otherwise, three levels are usually sufficient. The whole point of priorities is to set different response times (and, sometimes, resolution times) for different levels: if there is no difference in treatment between two priority levels, merge them.

How do I define priorities?

Just as there is no unified terminology for the concept of priorities, there is no universal scheme for setting priority levels, so you need to publish clear definitions. For instance:

• Priority 1, emergency. The product has a serious problem, causing severe impairments to the customer’s business operations.
• Priority 2, urgent. There is a problem with the product that has a noticeable, but not devastating business impact.
• Priority 3, regular. There is a problem with the product that is not significantly impacting the customer’s business, or the customer has a how-to question.

Make the definitions as clear and as straightforward as you can, as customers will follow clear guidelines more closely than complicated ones. Provide specific examples appropriate for your products and customers.

Should I let customers set priorities?

Yes, since they are the best judges of the business impact. Some customers will abuse the system, but the vast majority will not. Avoid arguing with customers about priority at the start of a case, as it will bring nothing but hostility for the support engineer. Meet the target response time according to the priority set by the customer and have a manager reach out to the abuser later on. If you have lots of abusers, you probably have a chronic throughput issue that needs fixing rather than an abuse issue.

Should I change priorities over the life of a case?

If priorities only determine the initial response time, they don’t need updating. If they drive other aspects of case management such as case updates, bug fixes, or visibility to the executive team, they can and should change over the life of the case to reflect the current impact on customer operations. Many times, an issue that starts as red hot cools off quickly with the availability of a workaround, but may linger on waiting for a permanent bug fix. That can be reflected in a lower priority level, as the customer is no longer “hard down” and we don’t need to give them hourly updates or keep the engineering team up all night working on a patch.

I am a great fan of being completely transparent with customers when changing priority levels. Many vendors prefer to privately, silently adjust an internal severity rating for the case to whatever they feel is the “correct” level: this is wimpy and counter-productive. If you think that the case is no longer a P1, tell the customer.

When you adjust the priority level over the course of case resolution, you will have difficulties running accurate case metrics that show the original priority. This is a valid reason to maintain a parallel priority/severity model — but not a good reason to hide the severity from customers!

Should the case priority match the bug severity?

If a case is linked to a bug, the case priority often matches the bug severity, but not always. For instance, a customer could be hard down (high priority case) but be fine after a simple reboot (low severity bug, and perhaps no bug at all!), while a customer with a how-to question (low priority case) may have stumbled into a major architectural bug (high severity bug). Also, bug severity is often influenced by the number of customers experiencing its effect, so the severity could be high while the impact on any individual customer is moderate.

What is your approach to priorities and severities? Please share!