Analyse a support queue by exporting your last thousand tickets, grouping them by topic, recording average handling time per topic, and ranking topics by volume multiplied by handling time. That ranking tells you where your support cost actually goes, and it is almost always surprising.
Key takeaways
- Volume alone misleads. Rank by volume times handling time.
- Support cost is usually concentrated in a handful of topics.
- Handling time and reopen rate together reveal which topics are badly documented.
- Do this before any tooling or automation decision.
Most support decisions are made on intuition about what the queue contains. This is a method for replacing that intuition with data, using only what you already have. It takes an afternoon.
The method
Step 1: export a representative thousand tickets. Not a peak week, not a quiet one. A normal month is ideal. Include the conversation, the resolution, and any timestamps you have.
Step 2: group them by topic. If your tagging is reliable, use it. If it is not, which is common because manual tagging degrades under time pressure, sort them by hand or by classification. Aim for fifteen to forty categories. If you cannot state what you would do differently for two categories, merge them.
Step 3: record average handling time per topic. Include after-contact work, which is routinely excluded by accident and is a meaningful share of the total.
Step 4: multiply and rank. Volume times handling time gives you total time per topic. Rank descending. This is the list that matters.
Step 5: add reopen rate per topic. A second dimension that changes the interpretation considerably.
What the ranking usually shows
Three patterns appear in nearly every queue we have seen described.
Concentration. A short list of topics accounts for a large share of total time, with a long tail of genuine one-offs. The specific topics differ by business. The shape does not.
Volume and cost diverge. The highest-volume topic is frequently not the most expensive one. Password resets are numerous and fast. A confusing integration is less numerous and takes forty minutes each. Ranking by volume alone points you at the wrong intervention.
Surprises. The topic people assumed dominated usually does not, and something unglamorous consumes more than anyone expected. This is the single most common outcome of running the analysis, and it is why running it matters more than any framework.
The second dimension: reopen rate
Once you have topics ranked by cost, add reopen rate for each.
A topic with high volume and high reopens is a documentation problem. The first answer is correct but incomplete, missing a step or a follow-on condition the customer hits immediately. Read twenty of those conversations end to end and the gap is usually obvious within the first five.
A topic with high volume and low reopens is a clean automation candidate. The answer works, it just costs a human to deliver.
What to do with each quadrant
High cost, low reopens, documented. Automate. These are questions being answered correctly and repeatedly by expensive people. This is where capacity comes from.
High cost, high reopens. Fix the documentation first. Automating an incomplete answer scales the incompleteness.
High cost, product-caused. Take these to engineering monthly with the customer wording attached. An unclear error message or an unexplained invoice line frequently generates an entire category, and the fix is small.
Low cost, long tail. Leave alone. This is what your team is for, and it is the work worth having people do.
The mistakes that ruin the analysis
Trusting bad tags. If four inconsistently applied tags describe the same underlying topic, your report shows four small categories instead of one large one, and the biggest driver of your volume is invisible.
Counting tickets instead of issues. A customer contacting three times about one problem is one issue and three tickets. Counting tickets makes a poorly resolved issue look like three cheap successes.
Using a peak period. Peak volume is differently distributed from baseline. Analyse both if you can, and never generalise from one.
Excluding after-contact work. It is a real part of handling time and leaving it out understates your expensive topics disproportionately, because they tend to have more of it.
Turning it into a plan
The output should be a ranked list with an action against each of the top ten entries. Something like:
- Access and login questions. High volume, low reopens, documented. Automate.
- Invoice line queries. Medium volume, high handling time. Fix the invoice, then automate.
- Integration setup. Medium volume, very high handling time, high reopens. Documentation gap. Write it properly.
- Refund requests. Medium volume, high emotion. Publish the policy, keep humans on exceptions.
That is a support strategy, derived from your own data, in an afternoon. It is more useful than any vendor comparison you could run first, and it changes which vendor comparison you would run.
Doing it continuously
The one-off analysis is valuable. The continuous version is better.
If your classification is automated and consistent, this ranking updates itself and you can watch topics grow before they become a problem. Emerging topic detection, catching a new issue at thirty a week rather than three hundred, is the highest-value thing this data produces and the least used.
Fidiora classifies every conversation as part of handling it, including the ones it resolves without a human, which is volume traditional analytics never sees because it never became a ticket. That said, the method above works with any tooling and with none, and it is worth running before you change anything.
Frequently asked questions
How do I analyse support ticket data?
How many tickets do I need to analyse?
What does a typical support queue look like?
What should I do with the results?
Resolve, don't deflect.
See Fidiora resolve a ticket, capture a lead, and keep the bill predictable.