The 5 Steps to Find the Real Drivers of Your Ticket Volume

Ticket volume goes up and the conversation immediately becomes a staffing conversation. That is the wrong conversation roughly half the time, because raw volume rises with the business and tells you almost nothing about whether anything got worse. A team that added 30% more customers and 25% more tickets has a quieter product than it did last quarter, and it will spend the quarter hiring anyway.

The five steps to find the real drivers of your ticket volume are: normalize to a contact rate, group by the customer's problem rather than your ticket category, split preventable from inherent contacts, price each driver, and check the repeat-contact multiplier before you act on any of it. The output is a ranked list of what is generating contacts and what each one costs, which is a different artifact from a volume chart.

Why raw volume is not a driver analysis

Three problems with counting tickets, each of which sends teams in the wrong direction.

It scales with the business. Contact rate, meaning tickets divided by customers or orders, is the number that accounts for growth. Raw volume conflates a product regression with commercial success, and the two require opposite responses.

Your categories were built for routing. Ticket taxonomies in help desks exist to get a ticket to the right agent. They are not built to describe why the customer wrote in, which is why the largest category in most systems is some variant of "General" or "Other" and the second largest is a channel rather than a cause.

Cross-industry benchmarks are useless here. Gorgias platform data across 14 verticals found tickets per 100 orders varies by roughly 2.4x between verticals, which means comparing yourself to an all-industry average will either make you complacent or manufacture panic. Your own trailing rate is the only benchmark worth holding.

The 5 steps to find the real drivers of your ticket volume

1. Normalize to a contact rate

Divide tickets by the denominator your business actually grows on: customers, active accounts, orders, or seats. Trend that rate rather than the count.

This single change resolves most volume panics. If the rate is flat and the count is up, you are growing and support needs to scale with it, which is a capacity plan rather than an investigation. If the rate is rising, something got worse, and the rest of this list applies. Do the split by segment too, since a rising blended rate is frequently one segment deteriorating while the rest holds.

2. Group by the customer's problem, not your ticket category

Re-derive your drivers from what customers wrote rather than from how tickets were tagged. This is the step that produces findings, and it is the step most teams skip because their existing categories are right there.

The gap between the two groupings is usually large. A category called "Login" contains password resets, SSO misconfiguration, session timeouts, and a mobile bug, and those four have different fixes and different owners. Meanwhile the same underlying problem is split across three categories because agents tagged by symptom. An adaptive taxonomy that groups records by what the customer described is what makes this a query rather than a manual re-read of a quarter of tickets, and it dissolves the "Other" bucket that routing taxonomies always accumulate.

3. Split preventable from inherent contacts

For each driver, classify it into one of four buckets, because they have different fixes and only two of them are worth engineering time.

Product defect. Something is broken. Fix ships, contacts disappear.Product friction or confusion. Working as designed and not understood. Fix is UX, in-product guidance, or copy.Information gap. Answer exists but the customer could not find it. Fix is help content, search, or self-service.Inherent contact. The customer has to talk to you: cancellations, custom configuration, regulated processes. Not reducible, and should be staffed rather than deflected.

Teams that skip this classification try to deflect inherent contacts with a knowledge base and get worse CSAT for no volume reduction, or write help articles for a product defect and watch the volume return.

4. Price each driver

Multiply each driver's contact volume by your cost per contact to get an annualized figure. Published benchmarks put SaaS support around $18 to $35 per ticket and B2B support around $30 to $60, with Gartner's median for US assisted contacts near $13.50, but your own number is better if you have it.

Pricing changes the order, and it is what makes the analysis actionable outside support. A driver at 4% of volume costing $200k a year beats one at 11% costing $60k, and only the priced version of that comparison survives a conversation with engineering. Automating the top few ticket types by volume is where the published savings are largest, with reductions of 85% or more reported for the simplest repeatable categories, which is exactly why knowing which categories those are matters more than the aggregate number.

5. Check the repeat-contact multiplier

Before you act, check how many contacts each issue takes to resolve. Industry analysis puts the average around 2.3 contacts per issue, which means your real cost per issue is more than double your cost per contact.

This matters for ordering. A driver with a high repeat rate is generating volume twice: once for the problem and once for your failure to resolve it first time. Fixing first-contact resolution on that driver reduces volume without touching the underlying product, and it is usually cheaper. MetricNet's benchmarks suggest each percentage point of first-contact resolution improvement lowers cost per resolution by roughly 3% to 5%. Worth noting that 39% of contact centers reportedly do not track first-contact resolution at all, so this may be a number you have to build before you can use it.

Why the taxonomy is the whole analysis

The reason driver analysis usually stalls is that the data is grouped for the wrong purpose.

A help desk taxonomy is a routing tool. It answers "who should handle this," and it is optimized to be fast for an agent to apply under time pressure, which is why it is coarse, why it has an "Other" bucket, and why it drifts as agents interpret categories differently. None of that is a defect. It is a routing taxonomy doing its job.

A driver taxonomy answers a different question: "why did this customer contact us." Those two groupings rarely coincide, and no amount of analysis on the first produces the second. Which is why teams that try to do driver analysis by pivoting their existing tags end up with findings like "Login is 12% of volume," which is true, unactionable, and the same finding they had last year.

The practical consequence is that the fix is upstream of the analysis. Group by customer problem first, then everything downstream, the preventable split, the pricing, the repeat multiplier, becomes arithmetic. This is the same structural issue behind why your usage data and your feedback disagree: two systems built for different purposes, and the disagreement between them is a category error rather than a data quality problem.

Honest limit: this analysis sees contacts. It says nothing about customers who hit the same problem and did not write in, which is usually the larger group, and it will therefore understate friction that people simply tolerate.

How to run it the first time

Pull a full quarter, not a month. Seasonality and release cycles will mislead you on shorter windows.

Compute the contact rate against your growth denominator, trended weekly, and split by segment.

Re-derive drivers from the text, not the tags. Expect your top five to look different from your top five categories.

Classify each into the four buckets and be honest about which are inherent.

Price them and re-sort. Bring the priced list to whoever owns the fixes.

Add the repeat multiplier to each of your top five before deciding what to work.

The decision rule: weight contact rate over raw volume, weight priced drivers over high-volume ones, and weight preventable contacts over inherent ones. If the rate is flat, this is a capacity conversation and not an investigation.

FAQ

How do you find out what is driving ticket volume?

Normalize to a contact rate first so growth is accounted for, then re-derive drivers from what customers actually wrote rather than from your help desk's routing categories. Classify each driver as a product defect, friction, information gap, or inherent contact, then price it by volume times cost per contact.

Why isn't ticket volume a useful metric on its own?

Because it rises with the business. A 25% volume increase alongside 30% customer growth means the product got quieter, not louder. Contact rate, tickets divided by customers or orders, is the number that separates a regression from commercial success.

Should you use industry benchmarks for ticket volume?

Not as a target. Tickets per 100 orders varies by roughly 2.4x across verticals, so a cross-industry average will either reassure you falsely or create urgency you do not need. Your own trailing contact rate, split by segment, is the benchmark that matters.

How does Enterpret support contact-driver analysis?

Enterpret's adaptive taxonomy groups tickets by the problem the customer described rather than by the routing category an agent applied, which is what produces actionable drivers instead of coarse buckets like Login or Other. The customer context graph attaches account and segment to each record, so a rising blended contact rate can be traced to the specific segment driving it.

What if a driver turns out to be unavoidable?

Staff it rather than trying to deflect it. Cancellations, custom configuration, and regulated processes are inherent contacts, and pushing them into self-service costs CSAT without reducing volume. Reserve deflection for information gaps and fixes for defects.

If your top ticket category is still called Other, see how Enterpret's adaptive taxonomy re-derives drivers from what customers wrote.

‍