Improving customer
bug reporting

Based on a true case
Scroll down

Oh no! A bug.The Challenge

A frustrated customer called. They want to know when a bug he reported a month ago would be fixed. Unfortunately, there was no way for my colleague from customer care to know the status of the reported bug besides asking someone from the development team.

To help my colleague respond to the customer, I looked up the status of the bug in Jira. Turns out the development team already tried to fix the bug two weeks ago but needed more information.

For me, this was a good reason to see what’s going on and how we can improve this.

The frustrated customer

…but why?

To understand more, my colleague and I searched Zendesk looking to find more customers that have reported a bug.

Reporting a bug was easy, press a button, fill out the form ‘it doesn’t work’, and done. But after a month he didn’t get any response, and he needs this bug fixed else there will be an issue with doing taxes!

The customer is half the story, I also needed to know how we handled the bug reports from customers. So I asked around to get to know even more.

The annoyed service employee

…but why?

Getting the ticket from Zendesk to Jira is easy. There is a form that creates a ticket, fills in the form and the bug is in Jira. But there’s no way of knowing when a reported bug is fixed in Jira besides when the bug is fixed.

The impatient developer

…but why?

When a bug gets fixed the developer most of the time needs more details to get a good understanding of how to reproduce the bug.

After talking to the involved people I collected enough information on the ‘bug-fix process’ and created a service design flowchart.

What to solve?

Opportunities and gains

Using this technique it was easier to have an overview of the flow and to see what could be improved. There were some improvements found for the customer but also for the employees.

The customer

Opportunity

In the automated response e-mail, inform the customer about webinars and live events coming up. Sometimes a bug is something that needs to be explained on how to use it.

Opportunity

Providing the customer with the right tools to record a video of the bug and the steps to report a bug, would save a lot of time when details are needed.

Pain point

Sometimes the automated response email goes into the spam folder. Communicate with the customer via other channels like the portal or Zendesk widget.

Service employee

Pain point

Has to work in four applications, Jira, Zendesk, Mail, and sometimes Slack. Can everything be managed from Zendesk?

Pain point

Doesn’t know the current status of an issue in Jira. This way has to communicate with the tester/developer to know if the bug is being fixed. Can this somehow be shared with Customer Care?

Developer

Pain point

A bug reported a long time ago can be already fixed or needs more details. When a bug needs more details it can take a while before it’s fixed. Some issues are:

  • Can’t remember how to replicate the bug
  • No reply from the customer

Can there be a direct way to communicate with the customer or can we improve the way customers report bugs?

Technical research

Can this be automated?

Because Jira and Zendesk are already well integrated into the different teams, instead of designing something awesome, I did some technical research. Is it possible to connect these platforms so both teams could keep using these and how can we improve reporting back to the customer.

Working from one application

…better care

Using the Jira and Zendesk integration app, it would be possible for support to get insights into the Jira ticket and get the issue in Jira all from Zendesk. By automating Jira, an automated response could be added within Zendesk keeping the customer up-to-date.

Improved bug reports

…what do we need?

To let the customer record a video with ease and explain what is needed to replicate the bug a plugin could be used for insights.

Fixed bug feedback

The Solution

By automating and using the integrations with some trial and error, the customer gets a mail when input is needed for the developer and when the bug was fixed. Furthermore, employees could work on the one tool they already know without the need to contact via different channels.

Looking back at this, I could have used the Zendesk API to also send a message to the customer in the Portal used by the customer.

What I’ve learned

Instead of immediately designing something that would help the customer, it was good to see what was already available and research if there are solutions in place, making the job of the employees easier.

Next time I would brainstorm with my colleagues. Including them in solving this issue would probably solve more also outside the bug reporting.

We will be happy to hear your thoughts

Leave a reply

Lexvd