5 Steps Support Teams Can Take To Get Product Bugs Fixed
Bugs are inevitable. No codebase is perfect, and even the best engineers can’t predict with 100% certainty what will happen with each new release.
Though many bugs are caught shortly after deployment, many are also found by customers over time. Since customer support professionals are the main point of contact for customers, they’re often the ones who customers report bugs to — and who work on the customers’ behalf to get them resolved.
As a customer support professional, there are any number of things outside your control related to solving bugs. However, there are certain things you can do to improve your chances of getting them fixed.
In this article, we cover the steps you can take to make a stronger case, and we also offer some advice for the times when you can’t get a bug resolved.
Understand the bug
Some bugs are minor and cause a few quirks. Other bugs bring the wrath of Thanos to an otherwise peaceful world and have an unquenchable thirst for destruction. But most fall somewhere in between those two extremes.
No matter the case, in order to accurately report a bug, you first have to understand it. Some key questions to ask about any bug are:
What feature or functionality does it impact?
Does it limit total or partial functionality?
Can you recreate it?
Is it limited to a certain environment?
How many people are affected by it?
What types of customers are affected (enterprise, standard, free)?
Answering each of these questions will greatly improve your understanding of any bug and make it much easier for you to articulate it to a product manager or engineer. You may not be able to get answers to all those questions, but the more information you have, the better.
By going through these questions, you’re making less work for the product manager or engineer who ends up reviewing the bug. The more thorough you are, the easier it is for them to understand the issue.
Collect data
After you’ve answered the questions above, the next step is to collect data around each point. For example, you could do a screen recording of the issue happening in real time. You should also document the steps you took to recreate a bug (if you could).
From there, it’s important to know how many people have actually reached out about a certain issue or if there are any high-value accounts experiencing the issue.
Keep in mind that for every one person who reaches out to customer support about an issue, there are, on average, 26 who don’t. So even multiplying reported cases by 10 is still pretty conservative.
Hard numbers aren’t subjective, which makes them powerful when making your case. It’s the difference between someone saying “A ton of customers are complaining about X issue” versus “We have 15 reported cases of X issue in the last hour, and two of those cases are enterprise accounts.”
Focus on items like:
The number of accounts/people affected.
How long the issue has been happening.
The frequency of reports.
How much functionality it inhibits.
Where/when it’s happening.
Each of the above signal how severe the issue is and can help motivate a product manager or engineer to solve the bug sooner rather than later. And if you don’t have a standardized format to report a bug, you should create one.
Tools like JIRA and Trello are popular options for bug reporting, but they aren’t totally necessary. The most important thing is having agreed-upon criteria to include in a bug report. Though one team may lead the project, it should be a collaborative process between your support and product teams.
Try the customer support platform your team and customers will love
Teams using Help Scout are set up in minutes, twice as productive, and save up to 80% in annual support costs. Start a free trial to see what it can do for you.
Try for free
Know your decision-makers
Though there may be many people involved in fixing and reporting bugs, there’s usually only one person — or a couple of people — deciding which bugs to work on. And getting an issue fixed is much easier if you know who to talk to.
Traditionally, that role is filled by a product manager or a team leader. In larger organizations, there may be multiple engineering teams with their own product managers and leads, so it pays to know which team works on which products or areas of those products.
Consult your company org chart or check in with product leads who should be able to steer you in the right direction. Those assignments may change over time, too, so find a way to keep up to date.
At Help Scout, our product support analysts are assigned to particular engineering teams so as to maintain that close connection.
Build connections and knowledge with decision-makers
One recurring theme of our interviews was the importance of relationships. Product managers, leads, and customer support people all talked about how having strong relationships with others working in the bug process made a measurable difference.
So how do you go about building good, cross-functional relationships? There’s no single answer, but there are a few things you can try:
Get to know people personally. Many people we interviewed mentioned that personal relationships could affect how they chose to do certain things. For example, if a product manager really trusts someone, they may be willing to work on something sooner based on their read of the situation than they would be strictly based on the numbers.
Meet regularly. Having a regular meeting cadence means you’re more likely to stay in the loop about what’s happening with a person or team. Those insights can be crucial when making a case for your bug.
Share information openly. When you’re open with others, they tend to be more open with you. Sharing information can also foster more conversations, which can help deepen current relationships.
Have an intermediary. Here at Help Scout, we have product support analysts (PSAs). Among other responsibilities, PSAs act as an information bridge between the product and support teams. Having them as a resource helps keep both teams informed and up to date while avoiding tons of additional meetings.
Seek out joint projects: Shared projects are a great way to deepen connections as they tend to naturally increase communication. Since there’s a reliance on others, it also can help build trust between groups, further strengthening the bond.
Above all else, it’s important to stay consistent and be intentional with your efforts. As it is with any relationship in life, you’ll most likely get out of it what you put into it.
Understand the larger business needs
Most engineering teams' primary function isn’t solving bugs. Though the amount of time they spend on solving bugs does vary, most people we talked with put the range at around 10%-20% of their time. The rest is spent on new releases and general codebase maintenance.
With limited time, they need to carefully prioritize their work and clearly understand the effort needed to resolve a given issue. What’s key to know is that most teams have an internal roadmap — a breakdown of what they’ll be working on in the next quarter — which is informed by larger company goals.
Build a stronger case for fixing your bug by relating it back to those larger goals or projects, which may mean it takes less effort to resolve than it usually would.
If it doesn’t work out…
The reality is that not every bug you submit will be solved. There’s simply not enough time and resources to do so (generally speaking). However, just because a bug isn’t solved doesn’t mean it’s wasted effort.
The three tips below can help ensure the majority of your bug-related interactions are net positive — even if the bug isn’t solved.
1. Learn from it
Though it may not always feel like it from the submitter’s side, if engineering rejects or backlogs a bug, there’s almost always a reason. If it is not provided to you, ask for an explanation.
Even a few sentences of explanation can be really useful when a bug gets rejected. It can shed light on something to do differently in the future, or it might reveal that something isn’t a bug at all and is expected behavior.
Feedback could also reveal you didn’t properly represent the issue in the initial report. Since engineers and product managers are generally coming into a bug report without the customer interaction you’ve had, it’s possible you missed something in the report.
Without asking for their feedback, you could miss out on vital information. You should even consider making it part of the overall bug process so it’s automatic and keeps an open line of communication between teams.
2. Deal with it in the meantime
In most cases, even if a bug isn’t properly solved, there should be some action to limit its impact. Often that means looking for a workaround for the issue. While workarounds aren’t a perfect solution, they are still very useful.
There are a few things to think about when looking for a workaround:
Focus on what the customer wants to accomplish. Getting to the core of what they’re really after can help guide you when looking for a workaround.
If the workaround is more of a hassle than the bug, find another solution. Though workarounds are sometimes a bit quirky, they shouldn’t be so cumbersome that they frustrate the customer as much — or more — than the actual bug.
Clearly document each step. Since a workaround means doing something unfamiliar, it’s very important you clearly lay out each step to implement it. Including things like screenshots can be a big help, too.
3. Persist
A lot of customer service is focused on immediacy. Obviously, most customers want issues solved ASAP. Even a lot of metrics are focused around immediacy — first reply time, average handle time, and so on.
Since we tend to be wired that way, if a bug isn’t solved immediately, it can feel like a loss — or like it won’t ever happen — but that’s not necessarily true. If the number of reported cases or level of impact the bug has continues to grow, so do your chances that it will be solved.
That said, the only way anyone will know about changes is if you continue to update the bug report and stay persistent. It can feel like spinning your wheels a bit, but it can pay off in the long run.
However, you should always err on the side of caution when setting any expectation for a customer. Even if you think cases for a certain issue will grow and eventually cause the bug to get solved, hold off on communicating that to a customer until you’re 100% certain.
In other words, to borrow a phrase from sales, “underpromise and overdeliver.”
A lasting solution
Bugs are simply a reality of working in software. Though it’s not possible to prevent them entirely, it is possible to manage them, and customer service folks play a huge role in that process. Though getting a bug fixed is far easier said than done, the effort you put in will pay off in the long run.
Jesse Short
The Supportive Weekly: A newsletter for people who want to deliver exceptional customer service.