How do you deal with tickets about bugs in your software?

'On-Hold' status would be the way to go with your tickets while waiting for feedback from your dev team.

We had a similar issue. Some bug can take a while to fix and we didn’t want to have tickets open for that long. We’d never know if they were fixed anyway and didn’t want that manual step to have to keep looking.

What we did is create a section in the Help Centre and called it a bug database. Then we provided the customer with the link to the article that described the bug. We sync our engineering database where the bugs are stored to the Help Centre, so as soon as a bug is fixed, the customer gets an email.

It took some effort but it works well.

We just let the customer know that we've logged the bug in our SDLC system and close the ticket.  If it's a situation where the customer needs a fast turnaround on the issue and we would create a system patch to resolve the issue, we might keep the ticket open until the patch is installed.

Hey All,

Many thanks for all the suggestions, it's very helpful.

Lester I really like this idea, out of interest how did you sync the articles with the dev system? Did you use the Zendesk API? Or was it something more manual?

Thanks,

@James

Yes, we used the Zendesk API.  First off we created a cron job to sync the bugs from our Engineering system and create the articles in Zendesk. We stored the Zendesk article reference in the bug in our Engineering system so they were linked. We then created a cron job that runs every hour looking for new bugs and changes in our Engineer system, if there was a change on a field we were interested in (bug moved from Open to closed, assigned to a release etc), we use the Zendesk API to update the article. 

Because changing the article text doesn't force the email to go out to customers, we also put a comment on the article showing what changed. 

Hey there - just thought I'd weigh in with another option on this. We experienced a very similar issue - we wanted to keep bug tickets open within our system, and close them when we knew the bug had been fixed. This let us provide really good customer service, and allow our users to understand exactly which of their issues were resolved, and which hadn't. Our issue was that it caused a MAJOR amount of work for our support team each time we released a version as we had to manually check tickets against the development system.

Our development team make use of Jira for bug tracking, so we used the native Zendesk/Jira integration to automate this process. In essence, what happens is:

1. A defect is identified.
2. A Jira ticket is raised, and linked using the Jira app in Zendesk.
3. A tag is then applied to the ticket, so we know it relates to a bug.
4. A workflow is triggered in Jira on release, which back-fills a Tag in to Zendesk stating that the bug is resolved.
5. An automation runs to pick up these tickets, e-mail the customer to advise, close the ticket, and remove the tag.

Hope this is helpful!

Paul.

Since no one seems to have mentioned it. Ensure you are using problem/incident tickets correctly. If many tickets are for the same bug, this will simplify handling tickets.

@James Wilson We have a similar issue. We prefer to keep the ZD open until the issue is resolved. How did you communicate with clients that it may be weeks or months before some of those are resolved, so there expectations were not constant updates of "there are no updates"?