Issue Tracking in Customer Support: How to Tame Recurring Problems

Last week the payment gateway went down for an hour and 40 people messaged support. Today the same thing happened again. If your team only answers conversations one by one, you start from zero every time, and nobody knows this is the third time the same problem has occurred.

That's what issue tracking is for: seeing problems instead of conversations.

What is an issue, and how does it differ from a tag and a ticket?

• A tag is a broad category ("payments"). It tells you what a conversation is about.
• A ticket is a specific request from one customer that must be followed up and closed.
• An issue is a specific problem ("payment gateway outage") that can link dozens of conversations and tickets from different customers.

With a tag, you learn that 40 conversations were about payments. With an issue, you learn that they all came from one problem, and how much that problem cost you.

The occurrence concept: the same problem, the second time

Many problems come back: a gateway outage, a bug in one app version, a courier delay. If you create a new issue every time, you can't see the pattern; if you dump everything into one issue, you can't tell whether the second time was handled better or worse. The solution is the occurrence: each issue has several occurrences, each with its own time window. You can see the numbers for each occurrence separately, as well as the total.

What should we measure?

For each issue (and each occurrence), track the following:

• Linked conversations: the size of the problem's impact.
• Satisfaction survey: how many customers were satisfied (CSAT) and how many were dissatisfied (DSAT). What Is CSAT?
• SLA compliance: what percentage of conversations got a reply within the deadline. SLA in customer support
• First response time and resolution time.
• Recurrence: how many times this problem has come back in the selected period.
• Mean time to resolve (MTTR) and recurrence rate: see how long a problem usually takes to fix and how often it comes back. Hodhod shows MTTR as mean, median and 90th percentile, along with the mean time between recurrences (MTBR), the recurrence rate per 30 days and a list of chronic issues (at least three occurrences in 90 days).

For more general metrics, see customer support KPIs.

A suggested workflow for your team

1. Name it clearly. The issue title should make sense to someone who wasn't in the meeting: "Payment gateway outage", not "Problem 12".
2. Link it from the conversation itself. The agent who sees the first message links the conversation (or ticket) to an issue or creates a new one. Once an issue has settled, add an automatic linking rule so similar conversations link themselves.
3. Set the occurrence. If the problem has just started or has come back, start a new occurrence; otherwise link to the current one.
4. Close the occurrence. When the problem is fixed, close the occurrence and write a note on the cause and the solution. If no new conversation is linked for a while, the occurrence is also closed automatically.
5. Review weekly. Open the issues report and read the "recurring issues" section.

A ten-minute weekly review

• Which issues received the most conversations?
• Which issue came back in this period, and why?
• Did customer satisfaction and SLA get better or worse in the new occurrence compared with the previous one?
• For high-frequency issues, who is responsible for fixing the root cause? (Hand the topic to the engineering or product team.)

Common mistakes

• Issues that are too broad ("payment problem"). After a while, everything ends up in them.
• Issues that are too granular, with one per conversation. You can't see the pattern.
• Forgetting to close occurrences. Resolution-time numbers become meaningless.
• Using issues instead of tickets. An issue tracks the problem and a ticket tracks the customer's request; you need both.

To see this workflow in the tool, check out the issue tracking page and the Hodhod ticketing system.

Frequently asked questions