How to prioritize “internal tickets”

How to prioritize “internal tickets”

What is the top offender in the customer support process of a software company? 

When our team at Movidesk asks this question to customer service managers or customer support managers, the answer usually isn’t employee turnover, lack of knowledge, product complexity, poor user training, lack of documentation, or poor product usability. Rather, the top item we see consistently is software defects (yep, bugs!). In fact, most of them estimate that a theoretical product with “zero defects” would reduce at least 50% of the entire customer support effort!

If identifying the bug is the first and most important step to have it fixed, then having testers, consultants, technical writers, demonstrators, and anyone else finding bugs during their regular activities before customers do should be good news. Instead, many customer services agents and managers look at the so called “internal backlog” with dismay. Too often, the reason we hear is that “those bugs just sit there, since they weren’t found by a customer.”

The negative effect of this perception isn’t easy to notice, but it is quite harmful. People from different departments stop logging “internal bugs” since they feel those bugs don’t get fixed. Others create tickets in the name of customers because “only then they’ll get fixed.” Departments argue about the prioritization of these bugs: while some say they must be fixed because it’ll be bad if a customer sees it, others postpone the effort because they don’t see customers complaining about those bugs. They often don’t take advantage of the situation to avoid making a customer unhappy tomorrow.

It’s important to consider that bugs harm the perception of quality for customers, increase customer support costs, and are the major contributor to customer churn—research shows that bugs are second only to customer fit as a cause for customer churn. When we take all of these into account, it’s clear that—for most companies—the best business approach is to address and fix “internal bugs.” But managers and companies who agree will sure face next question: how should those bugs be prioritized?

We found that the main hurdle to answering this question has more to do with sharing information and aligning stakeholders on company strategy, than with establishing a simple and effective process. Departments must reach a common understanding, either by interacting with one another or through top management facilitation. Once there is a common understanding about the importance of addressing bugs before customers “bump” into them, there are two simple steps to organize everyone involved with defects that are found internally.

The first step is communicating to all stakeholders. From customer support to product management and field services, everyone should be informed of a company-wide decision: bugs should be treated according to these questions:

  1. What problems is it causing for customers? 
  2. What problems could it cause for customers?

Once that’s communicated, everyone involved with bugs should classify them by considering both of these questions.

Process-wise, a simple approach is to use the same bug classification for both “external bugs” (found by customers) and “internal bugs” (found by employees and business partners). For example, if using the classification suggested in our article How to prioritize tickets in software companies, agents would ask themselves about a customer-reported bug: “Is this bug a showstopper?” When the answer is yes, they will classify it as severity “1.” Similarly, the question for an “internal bug” would be: “If a customer runs into this bug, would it become a showstopper?” If the answer is yes, agents should also classify that bug with a severity “1.”

After the first step of classifying individual bugs, the obvious challenge is how to prioritize the now mixed “external bugs” and “internal bugs.” The most straightforward and practical approach, which we usually recommend, is driven by the following rationale:

  • Always fix a severity “1” bug before a severity “2” bug and so on, no matter if the bug was found by a customer or by an employee.
  • Between bugs of the same severity, it does make sense to prioritize the bug found by a customer, since that customer is already in pain.

A prioritization process following the above criteria, would respect the order depicted by this diagram:

The above approach is proven to simplify cross-functional alignment, automate prioritization, and make customers happier. Unless your company is past these problems by using another approach, trying the above method may save your company countless hours of company-wide discussions—and unpleasant experiences for your customers!

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