Support prioritization, part one

This blog post is based on a workshop that Brian presented at Support Driven Expo in Portland, Oregon, titled "Turning Feedback Into Action."

Your support team is often one of the first (and sometimes only) point of contact people have with your company. When people have problems with your product, are confused by your website, or want to request a new feature from you, they typically contact the support team. A common process for these interactions looks something like this:

  1. A user emails about a defect they found in the product. They're frustrated but communicative. They just want the product to work.
  2. A support engineer receives the email. They get as much information as they can from the user and do everything possible to reassure them that the problem will be resolved.
  3. The support engineer reproduces the issue and opens an internal bug report for the engineering team. They include all relevant information about the problem, how it happened, who it affects and how, and possible remedies.
  4. They wait
  5. There is no five.

All support engineers have been in situations where they've done everything they can to help users through their problems, to get to the root cause of an issue, and to help the problem get fixed only to have the bug report sit silently for days or weeks. It's frustrating. In their frustration, they often get upset with the engineers or the product team for ignoring support and, most importantly, ignoring the people using their product.

Let's look at this from the other side and consider how engineers manage their work and prioritize their projects.

In many cases, engineers prioritize their work in this order:

  1. What management tells them to work on.
  2. What they think is most important to the business
  3. What they think is easy or fast
  4. What they think is fun

In the absence of direct instructions from management, most people will fall back on what they think is important to the business. Everyone at a company has their own ideas about what is most important, even if not everyone agrees. When people wrap up work on high-value projects, it feels good to cool down a bit with something easy or fast, even if it's not necessarily important work. And every now and then, when time allows, everyone wants to work on something that's just simple fun–whether that's experimenting with a new framework or language, or hacking on a personal side project.

When a support engineer adds details to their bug report or feature request, they're trying to pull on these levers, usually the second and third on that list. They add user quotes to show how important a feature is to customers. Theoretically, in-depth research to reproduce an error and pinpoint the cause makes it easier and faster for an engineer to jump in and resolve the problem. While all of these details are helpful, multiple support engineers flailing wildly at these levers individually is not a reliable way to get attention or prioritize work. Support teams need a more methodical approach that engineering, product, design, and marketing teams agree on.

The Prioritization Matrix

Over the past couple of years, I've worked out a Prioritization Matrix. It's not complicated and it's not super original; I used similar methods to prioritize work at the U.S. Department of Defense. Here, you take a decision matrix approach and apply it to support and engineering issues. First, you define a problem using two axes–impact and severity.


When you think of impact, it's helpful to think in terms of the number of individual people affected, rather than teams or businesses. If you support a business product, you might think of problems affecting clients, but I've found scoping the impact in terms of end-users to be more meaningful. For example, if you have one client with 100 users and another with 1000 users and the smaller client reports a bug that affects only their account, the impact of the bug is 100 people. If the larger client reports a bug that affects only their account, the impact of that bug is 1000 people. As a result, your company may consider the bug a more important problem. Scoping impact in this way allows you to account for the size of the clients you're working with, and helps you and your team think about problems in terms of real humans.

We'll break impact down into four categories: small, medium, large, and huge. You can define these groups in terms of either a percentage or raw numbers. In either case, don't use equal sized groupings, such as equal 25% increments. Once a problem affects 50% of your end users, you should consider it a very high priority, not medium. Instead, use groupings like 0 - 1%, 1% - 10%, 10% - 50%, and 50% - 100%. The exact numbers you use, and whether you use percentages or raw user quantities, depends on your product and your business.


The severity of a problem describes how the problem affects people. Similar to impact, break this down into four categories, like low, medium, high, and critical, again depending on your product and your business. For Yetto, we can define them as:

  • Low: A cosmetic bug that does not affect the usability or functionality of the product or site, such as a typo or CSS layout issue.
  • Medium: A bug that affects a non-core function or feature of the product, like when custom email names can't be updated in Settings.
  • High: A bug that affects a core function or feature of the product, like when inbound emails aren't routing to GitHub issues.
  • Critical: A bug that affects user security, privacy, or a loss of data, like when emails are routed to incorrect GitHub accounts.

The Matrix

Once you have definitions for Impact and Severity, use them as axes in a Prioritization Matrix. We'll fill in the grid with a set of Support Priority values ranging from SP0 (highest priority) to SP4 (lowest priority).

prioritization matrix with impact on the x-axis and severity on the y-axis
Prioritization Matrix

The grid numbering here is a starting point that you can modify to reflect how you want to prioritize issues for your product and your company. For example, for your product, all critical severity issues may be SP0. This is something you'll need to work through with your team, and will likely be where you spend the most time setting up your matrix.

Once you define these priority levels and get consensus with other functional teams in your company, you can use them to communicate an issue's importance to those other teams. If you use GitHub, use labels to denote the priority. This lets you sort issues by support priority levels and track progress on them over time.

Beyond using labels to communicate with other teams, with the help of GitHub's API, they can be useful for seeing how quickly your organizations resolve issues or implement features. Pull and sort issues by Support Priority level and automatically count things like how many issues have been opened and closed over a recent period, how long they stayed in an "open" state, and how resolution time has changed month over month or year over year. Watching those numbers drop over time can be a significant morale boost for every team, as they can see the direct impact of their efforts.

The key to this methodology's success is the clarity that it brings to cross-team communication. Alliteration aside, this works best when all teams are invested in and involved in the process from the beginning. In part two of this series, we'll talk about how to get other teams on board with this approach and how to iterate on it.