Ticket Deflection

Support work was understood for a long time as handling what arrives well. So the numbers measured the handling: how many hours until the first reply, how many days until a case closed.

Inside that frame, growth had only one answer. Twice the users means twice the questions, so hire twice the people. In a 45-person company, support going from two people to four to eight eats the money that would have built the product. And still the effort went into shaving time per question — turning a three-minute reply into two minutes thirty.

Companies did write help documents, but there was no way to talk about the effect. Tickets dipped slightly in the month the documents went up, and nobody could separate that from the fact that no major outage happened that month. Ticket deflection puts a number in that gap. Instead of whether arriving questions were handled well, it asks whether they were kept from arriving. With the number in hand, the hours spent on documentation and chatbots can be converted into payroll saved.

There are three ways to count it. They differ in what goes into the denominator, and one company often runs two of them side by side.

1. By help-center visits. The share of visits to a help document that didn't turn into a ticket. With 4,000 document views in a month and 400 of those visits ending in a submitted question, that's 90 percent.
2. By tickets per user. Track monthly questions per 1,000 active users and treat the decline as deflection. Going from 42 per 1,000 to 27 over six months is a 36 percent reduction.
3. By chatbot session. The share of chatbot conversations that ended without a handoff to a person. A chatbot is the automated responder sitting in a chat channel. This one counts the most cleanly, and it misses everything that arrives by email without touching the bot at all.

Method 1 has a trap in it. Visits that didn't produce a ticket get counted as resolved, but a visitor who gave up without finding the answer lands in the same bucket. Separating the two requires other signals: whether the same person reopens the same document three times in three days, whether that visit is followed by them stopping use of the product, and how they answer the "was this helpful" control at the end of the page.

Whichever method is used, the support ticket history provides the baseline — one logged question, carrying a number and a status. Without six months of counts by category, there's nothing to call a reduction.

There's no absolute benchmark. A complex product configured differently at every account simply has a lower share of questions a customer could resolve alone. A simple single-user tool produces questions that mostly already have documented answers, so the figure comes out high. Comparing against another company's number is close to useless.

Read the trend in your own number instead, which is what the second method is for. Questions per user lower than six months ago means improvement, and holding that figure steady while users grow already means support headcount doesn't have to grow in proportion. That second case is the one worth naming in a plan, because it is the difference between support being a fixed cost and support being a tax on every new customer.

Splitting by category matters more than the headline. One overall rate doesn't tell you what to write next. Pagedeck has seven question categories; account invitations and invoice reissues resolve from documentation about 90 percent of the time, while questions about integrations that got stuck resolve under 20 percent. More documents won't move the second group — the product has to change there.

The figure to read alongside it is first response time, the hours between a question arriving and a person first replying. As deflection rises, time freed up on the remaining questions pulls that number down. Deflection up with first response time flat means either only the easy questions went away, or headcount was cut before anything else changed.

"Twelve help articles last quarter, and questions per 1,000 users fell from 42 to 34."

Reporting the effect of documentation work as a number.

"A 92 percent deflection rate might not be good news. Let's check we haven't buried the contact button."

Treating a high figure as something to question.

"Integration questions don't respond to documentation. That one has to be fixed in the product."

Sorting categories into what documentation can and can't reach.

At Pagedeck, Mia counts questions by category each quarter and decides which category gets documentation. Two conditions: high volume, and an answer that's always the same. Last quarter, account invitation questions ran at 180 a month with nearly identical answers, so three articles and six FAQ entries went up. An FAQ is a short collection of recurring questions and their answers.

Two months later that category was down to 60 a month. What Mia checked alongside it was the completion rate of the invitation feature itself, which held. If questions fall while completion falls with them, people stopped asking rather than succeeding — and the fix then belongs to the screen, not to the documentation.

The most common mistake is reading a high rate as unambiguously good. Fewer questions looks like a better-built product, so the assumption is natural. But this number also rises when asking is made harder. Bury the contact button three clicks deep, or require reading the help center before it unlocks, and logged volume falls. What fell is the questions; what remains is the unresolved problems, and they come back at renewal as customers leaving for no stated reason. Which is why this figure gets read next to satisfaction and renewal rate rather than on its own.

The other mistake is expecting more documentation to produce deflection. More articles sounds like more answered questions. But a document nobody can find is the same as a document that doesn't exist. Customers search in their own words without knowing the product's feature names. An article titled "member permission management" never surfaces for someone who searched "how to invite someone." So the wording from actual tickets goes straight into titles and body text. Writing fifty articles without moving the number usually means the titles were written in the company's vocabulary.