Learn how to triage customer issues, prioritize bug tickets, and handle bugs effectively with practical, real-world strategies.

All software has bugs, unfortunately. That’s because software is invisible, and you can ship a problem as big as shipping a car with three wheels. In contrast to the flawed car, you don’t see the flaw in the software. 

Even if you take testing and quality assurance seriously.

Not all issues reported by customers as bugs are bugs. But all customer issues must be taken care of — ideally instantaneously, realistically within a reasonable time.

How can you deal with bugs that impair the quality of your software product?

At Yonder, the B2B SaaS company I co-founded, we have come a long way in improving bug handling. Once upon a time, we used to have a CTO who bluntly said that bugs don’t matter, only features matter. As a consequence, I stepped in and declared myself the Chief Bug Officer of the company.

Things have evolved since. I am still involved in handling bug tickets, but I am no longer the Chief Bug Officer.

Here is what we did.

1. Not every help desk ticket is a bug ticket

We use a tool called Freshdesk as our customer help desk system. Not every issue reported by customers is a bug, even if the customer says it is a bug.

Before we scream “urgent bug!”, our customer team tries to solve the customer issue without creating a bug ticket. In many cases, this works well.

In some cases, the reported problem is indeed a bug or another issue the dev team needs to step in. That’s when the customer team creates a JIRA ticket for the dev team.

2. Talk about bug tickets, several times a day

Ticket systems are great, and they were designed to facilitate asynchronous working. Asynchronous working is often a synonym for working whenever, wherever, without talking to each other.

Wrong.

The Chief Customer Officer and I talk several times a day about bugs. Whenever there is the slightest uncertainty about a bug ticket, we talk at the coffee maker or jump on a quick Teams call. It’s those discussions that make the JIRA tickets more accurate, which helps the dev team fix the underlying issue fast.

3. Prioritize bug tickets in the sprint

Some customers report every edge case as a bug; some other customers only report grave bugs. Therefore, we have to prioritize bug tickets. This is done in my weekly one-on-one meeting with the Chief Customer Officer — or if there is a high-priority issue, anywhen between those one-on-one meetings.

Last but not least, I resort to a very simple trick in JIRA. All bug tickets are assigned to the JIRA epic “customer bugs” if the customer reported it, and to the JIRA epic “bugs discovered by Yonder” if we discovered the bug. The labels for those epics are red, and I move the bug tickets to the top of the list of all tickets in the sprint. In this way, they appear first on the sprint board. As simple as that.

Conclusion

Some customers might still say that bug fixing takes too long. Before arguing with a customer, let’s put bug-fixing cycles into context.

I would totally agree that bug fixing takes too long in the case of edge case bugs. Those get lower priority than other bugs, or they might not even get fixed at all. On the other hand, I think our bug-fixing process for higher-priority bugs works quite well.

And here you have it: A bug isn’t a bug. Even if you measure resolution time in the customer portal the same way for all bugs.