Ticket deflection for SaaS: measuring the “how do I…” tax

“Ticket deflection” is one of the most quoted and least measured numbers in support software. Vendors publish impressive percentages; few teams can reproduce them on their own data. This is a method you can run in an afternoon to size the problem first, and a fair way to measure any fix afterwards.

Step 1: define the “how do I…” tax

Some tickets need a human: a bug, a billing dispute, a judgment call. Others have an answer that is a location in your product: a menu, a tab, a button. We call the second group the “how do I…” tax. The feature exists; the user couldn’t find it.

A ticket belongs to the tax if a correct reply could be “Go to X, then click Y” and nothing else.

Step 2: sample and tag

Export one recent, typical month of tickets. Avoid launch weeks and seasonal peaks for the baseline.
Take a random sample of 200. That is enough for a useful estimate, and small enough to tag by hand in a couple of hours.
Tag each ticket: location (answer is a place in the app), how-it-works (needs an explanation), problem (bug, data issue, access), or other.
For location tickets, also note the page or feature involved.

Two people tagging the same 30 tickets is a good check: if they disagree often, tighten the definitions before tagging the rest.

Step 3: put a number on it

With the sample tagged, estimate:

Share: location tickets divided by sample size.
Volume: share times monthly tickets.
Cost: volume times average handling time times loaded cost per support hour.
Hot spots: the five pages or features that produce the most location tickets.

The hot spots matter more than the total. They tell you where to put guidance first, and often reveal a UI problem worth fixing directly.

Step 4: measure deflection without fooling yourself

Once you add self-service guidance (a guide like Wayhint, better help content, or a UI fix), measure like this:

Normalise by active users. Tickets rise with growth. Track location tickets per 1,000 active users per week.
Watch a control group. Problem and how-it-works tickets should stay roughly flat. If everything drops, something else changed (a holiday, a pricing change).
Compare like with like. Same season, same tagging rules, same sampling.
Count resolutions, not opens. A guide opened is not a ticket avoided. The useful signal is goals completed without a ticket on the same topic within a few days.

Common traps

Counting help-article views as deflections. Many readers file a ticket anyway.
Moving tickets to chat. If the chatbot hands over to a human, the work moved; it didn’t go away.
Hiding the contact form. Making it harder to ask lowers tickets and raises churn. That is not deflection.

Where in-page guidance fits

Location tickets are the best case for a guide that points at the actual control. The user asks in their own words, and instead of an article they get walked to the button on the screen in front of them. For how-it-works questions, a good explanation still matters; for problems, a human does.

If your tagging shows a large location share concentrated on a few pages, start there. Here is how Wayhint handles it, and the free plan covers 500 monthly users who ask for help.