It’s a tale as old as time…or at least as old as the SaaS world: a bug is reported or a feature requested, only to have it lost in the never-ending abyss of the backlog.
What can be done? How can you better capture, track, and (internally) promote feature requests and bug reports?
In this article, I’ll dig into four common issues with handling bug reports and feature requests and provide expert fixes.
Issue 1: Too many bug reports to keep up with
Let’s say there’s a sudden widespread issue with your product.
Users will immediately begin to contact you, and some will do so over and over…and over…and over… reaching out via every contact point available – email, chat, contact forms, phone, socials, and more.
Or maybe someone asked for a feature many months (or years) ago. Numerous people have made the same request, but a handful have gotten in touch several times, wondering if there is an update about when it’s coming. If you’ve ever checked out the community forum pages for big enterprise products, you know this is a common experience.
In both scenarios, the support team has more than one report from each customer, leading to several problems.
In the first scenario, a flood of repetitive submissions over a short interval backs up your entire support queue. This creates an overload of work for your team and contributes to a false sense of the issue’s severity.
In the second scenario, recurrent requests over time for the same feature lead to misunderstanding the perceived demand.
How to fix it: automatically merge duplicate tickets
The easiest fix for the first scenario described above is to merge duplicate tickets. When doing this manually, you’d have to check each customer profile to see if they have any open or pending tickets, investigate what each ticket is about, and merge anything about the same subject.
This leaves a lot of room for error, and it's easy to forget about during a period of high support volume.
So do it automatically.
Using the Swifteq Zendesk app, you can Merge Zendesk Tickets automatically. You can choose what is merged by selecting the time window for ticket creation and the criteria to search for.
For example, you can create an automation that merges all tickets submitted by the same customer if they are made within 1 hour of each other and they include the words “not working” or “bug” in either the subject or description.
You can even prevent certain tickets from merging based on your chosen exclusion requirements, such as choosing not to merge tickets from a specified client list, giving you more immediate insight into your high-value customers.
Issue 2: Slow initial response time or no followup
Early-stage startups don’t tend to automate things right away. There’s often value in doing tasks manually in the early days, especially when it comes to customer communication.
But when your customer base begins growing exponentially, you find that you don’t have the staff to handle things manually anymore. Whenever there’s a bug or a feature request, some reports are inevitably lost or tickets aren’t followed up on.
Although a logical step, introducing automation at this stage often comes with its share of troubles. A typical scenario might involve myriad tools operating in a chain.
For instance, a chat on Intercom triggers a process on Zapier, which in turn creates a report in Jira and, upon resolution, triggers another Zap to reopen the Intercom conversation for follow-up.
The snag here is the dependency on multiple tools: a failure in any one of them could lead to a lapse in follow-up, recreating the initial problem.
Add to this the fact that a large number of SaaS companies provide email-only support to their lowest-tier customers, often promising a one business day turnaround. And typically speaking, most of your users will be on your lowest-cost pricing plan.
This model is fine 95% of the time since it encourages using self-service support methods like your knowledge base and forums. But for bug reporting, it falls short.
Consider this: if 80% of your customers are on your lowest pricing model with only email support at their disposal, the odds of quickly finding a report of a critical bug become slim. The first report is likely to get buried amidst low-priority emails, surfacing hours after submission, by which time the support team may have already stumbled upon the issue independently.
Meanwhile, your customers who’ve been left in the lurch start contemplating alternative products.
How to fix it: create ticket automation through ChatGPT
ChatGPT can do far more than help you pump out blog content and help you write your wedding vows (yes, I did do that).
Many companies have used its API to help non-developers automate repetitive tasks.
Through the Swifteq Zendesk ChatGPT Automation, you can create a system where ChatGPT scans your inbound tickets for certain terms (such as ‘bug’ or ‘not working’) and tags each one accordingly. You can then create Zendesk triggers which use those tags to change the priority or reassign those tickets.
This way, your tickets get to the right team quickly, decreasing first response times and increasing customer satisfaction.
Issue 3: Items are addressed first-come-first-serve
In 1792, Baron Dominique Jean Larrey, the Surgeon in Chief to Napoleon's Imperial Guard, developed a sorting technique for dealing with war casualties. Rather than the first-come-first-serve method that was previously popular, Larrey chose to sort patients into immediate, urgent, and non-urgent injuries.
Doing so saved countless lives, and as a result, this concept of ‘triaging’ became popular globally. It’s still in use today in hospitals around the world.
Many new software companies make the mistake of dealing with bugs and feature requests in the order they are brought to the team’s attention. While it’s unlikely your software will cause a death if it errs (unless you sell pacemakers), you may see contracts dying if bugs and feature requests aren’t tended to appropriately.
Dead contracts mean a loss of revenue that you can’t afford.
How to fix it: use a priority system for dealing with requests
Create a triaging method for your bugs and a separate method for feature requests. The two may overlap, but they shouldn’t be treated the same.
Just as babies should (almost) always be given higher priority than adults with medical issues, bugs should (almost) always be given higher priority than feature requests.
To be frank, customers often view it as unacceptable for you to launch a big new feature before fixing that painful bug that was reported over a month ago. Consistently doing so can shoot your growth efforts in the foot.
A basic triage system groups each incoming ticket into High, Medium, or Low priority. But I recommend including a ‘critical’ level for those rare incidents that are more urgent than the other high priorities (it’s a high priority if customers can’t change their payment method, but it becomes critical if new customers can’t make a first payment).
You can even create a “Lowest” priority for that never-ending list of things that always seem left on the back burner.
Issue 4: There are disagreements around triaging
The 1% rule of engagement on the internet, also known as the 1-9-90 rule, states that 1% of users are actively engaged, 9% are somewhat engaged, and 90% are not engaged at all.
In product usage, that translates to 1% of customers actively voicing (dis)satisfaction with your product, 9% occasionally voicing opinions, and 90% staying quiet.
The problem here is that it can create a false sense of reality around the severity of a bug. For starters, it’s important to remember that your support team will likely feel that a problem is infinitely worse than it is.
Let’s say you have 10,000 customers, and 5% of them are affected by a medium severity bug. Then, let’s say that 8% of the affected customers choose to report the issue. That’s 40 bug reports for one issue.
If your team is accustomed to receiving 100 tickets per day, that means 40% of the tickets that day are about this one problem. It’s natural for support to assume the bug affects almost half of the user base because that’s what it feels like to them.
How to fix it: use a scorecard for data-driven prioritization
Come up with a data-driven system to help determine priorities, such as a scoring system that assigns a set number of points based on certain criteria. This way, no person is deciding the priority – the system is.
Create a few categories that will play a role in every request, such as the percentage of customers affected, the percentage of end users affected, the effect on usability, and the time since it was first reported.
Next, give each category three to five buckets into which you can group each report. If we’re talking about the percentage of customers affected, you might create five groups such as > 1%, 1-10%, 11-25%, 26-50%, and 51%+.
Finally, assign a score to each bucket, with 0 being the least important and a high number of your choosing be the most important. If referring to the percentage of affected customers, > 1% would score a 0, while 51%+ would score a 10.
Here’s a quick example scorecard:
Based on this table, a bug with least priority has 0 points, while one with highest priority has 30 points (in the real world you’d have more categories and buckets more specific to your business).
For a bug where every customer is affected (10 points) that makes the platform impossible to use (10 points), has no workaround (5 points), and was reported 30 hours ago (2 points), this bug would receive a 27 out of 30 points. This would fall into the “critical” priority list.
When a report is received, tally up the score from each category to determine the total score. In a scenario where the least points possible is 0, and the most possible is 20, a bug that scores a 20 would get a “Critical” priority level, while one that scores a 0 goes to the back burner until it gets enough points to move up in priority.
It’s worth noting that bugs and feature requests should have different scorecards. Feature requests have other factors to consider (such as cost/benefit analysis) that will play into their score.
You can even use custom fields and triggers so Zendesk can automatically score your incidents for you.
Better bug and feature request handling benefits everyone
In the fast-paced realm of SaaS, efficiently handling customer feedback is paramount. When faced with many challenges – from overwhelming volumes to the prioritization conundrum – companies can easily falter without the right strategies in place.
By automating processes like merging duplicate tickets and ensuring faster response times through ChatGPT automation, businesses can efficiently tackle high-volume periods. Borrowing the principle of triaging and complementing it with a data-driven scoring system ensures that issues are addressed based on their actual impact, rather than a biased perspective or as an emotional reaction.
When you get your bug and feature request processes nailed down, your customers are happier, your support team is less stressed, and your product and engineering teams know exactly what they need to prioritize. It’s a win-win-win.
If you’re ready to get started, start your free 14-day trial of the Merge Duplicate Tickets or the Triggers+ChatGPT app today!
 | Anne-Marie is a customer success executive focused on communications and scalability. She specializes in driving process & product improvements, creating thorough and easy-to-understand product documentation, and teaching others how to communicate more effectively through the written word. You can find her on LinkedIn |