When Documentation Answers Tickets: The Deflection Math
"Write documentation and your support volume goes down" is one of those claims everyone repeats and almost nobody quantifies. It happens to be true — but only for certain articles, written a certain way, and only up to a point. Let us do the actual arithmetic, then be honest about where it stops working.
The math of one good article
Take a question you answer three times a week. Nothing exotic — "how do I regenerate my API key," "why is my webhook not firing," "can I change my subdomain."
Each answer costs more than the reply itself:
- Reading the ticket and recognizing the question: ~2 minutes
- Writing or adapting a response: ~5 minutes
- The follow-up round ("that worked, thanks" or "still stuck"): ~3 minutes
- Context switching back to whatever you were building: hard to measure, real nonetheless
Call it 10 minutes per occurrence, conservatively. Three times a week is 30 minutes a week, which is roughly 26 hours a year — for one question. If you have five questions at that frequency (most products do), that is 130 hours a year, or more than three full working weeks spent typing variations of the same answers.
Now the other side of the ledger. A solid article on a question you already know cold takes maybe 45 minutes to write and 15 minutes a year to keep current. Even if the article only deflects half of those tickets — a realistic number, since some people will never search before asking — one hour of writing buys back about 13 hours a year. That trade keeps paying every year the question stays relevant.
The math is not subtle. What is subtle is which articles actually earn it.
Write the articles your tickets ask for
The classic failure mode is writing documentation top-down: sit down, imagine what users might need, produce forty pages of feature descriptions. Six months later the analytics show three of them get read and none of them changed ticket volume.
The alternative is to mine your actual tickets. Your support history is a ranked list of what confuses real users, in their own words. The process:
- Pull the last 60–90 days of tickets and group them by underlying question, not by how they were phrased. "Webhook not received," "no POST arriving," and "integration seems dead" are one question.
- Rank by frequency times cost. A question asked weekly that takes two minutes to answer matters less than one asked weekly that takes twenty minutes of back-and-forth.
- Write the top five. Not the top forty. Five articles aimed at your five most repeated questions will outperform a comprehensive manual nobody opens.
- Use the customer's words in the title. People search for the error they see, not your internal name for the feature. "Webhook returns 401" beats "Configuring endpoint authentication."
There is a compounding trick here, too: the moment you finish resolving a novel ticket is the best possible time to draft the article, because the confusion and the fix are both fresh. Some tools automate the nudge — Helmdesk, for example, has an agent that watches resolved tickets for recurring questions with no matching article and proposes a draft for review — but even a manual "was this the third time?" check at close time works.
Measure helpfulness properly
"We published 30 articles" is an output metric. The metrics that matter:
Deflection is measured at the ticket, not the pageview. An article with 5,000 views that never reduced its question's ticket count deflected nothing (or was answering a question nobody was going to write in about anyway). The honest measure is: ticket volume for that specific question, before and after publication. Tag tickets by topic and compare.
"Was this helpful?" needs both buttons to mean something. A yes/no vote at the bottom of an article is crude but useful — if you read it correctly. A high no rate is a gift: it points at articles that rank well in search but fail to answer. A high yes rate with unchanged ticket volume suggests the article helps people who were already going to figure it out.
Watch what people searched and did not find. Failed searches in your knowledge base are your next five articles, pre-ranked by demand. This list is usually more valuable than any brainstorm.
Expect the effect to be partial. Well-targeted articles reliably cut their question's volume, but never to zero. Budget for "fewer," not "none," and the numbers will stop disappointing you.
Where deflection genuinely fails
This is the part most knowledge-base marketing skips.
Edge cases don't deflect. Documentation covers the common path. The customer whose account is in a weird state, whose payment failed in an unusual way, whose data predates a migration — no article will ever cover them, and trying produces bloated docs that bury the common answers. These tickets are what your helpdesk is for. The goal of deflection is to clear the repetitive tickets so these get real attention.
Angry users don't search. Someone who just lost work, got double-charged, or hit a bug at the worst moment is not going to calmly browse your help center. They want a human acknowledgment, and pointing them at an article — even the correct one — reads as a brush-off. Deflection is for questions; it is actively counterproductive for grievances.
Anything requiring your access doesn't deflect. Refunds, account merges, plan changes you have not self-served, data exports behind a flag — an article can only explain that the user must contact you, which converts one ticket into one slightly better-informed ticket. (Sometimes that is worth it: a ticket that arrives with the account email and invoice number attached is half-solved. But count it honestly as triage, not deflection.)
Stale docs anti-deflect. An article describing last year's UI generates tickets: now the user is confused and distrusts your docs. Every published article is a small maintenance liability. This is the strongest argument for writing five great articles instead of forty mediocre ones — the maintenance budget is real.
The honest summary
| Situation | Does documentation help? |
|---|---|
| Same question, 3×+ per week | Strongly — this is the whole payoff |
| Setup and integration errors | Yes, if titled in the user's words |
| Rare edge cases | No — handle in the helpdesk |
| Angry or urgent users | No — they need a human, fast |
| Actions requiring staff access | Partially — better tickets, not fewer |
Documentation is not a support strategy on its own. It is a filter: it removes the repetitive questions so that what reaches you is the genuinely hard, genuinely human remainder. Run the arithmetic on your own ticket history — frequency times minutes times 52 — and write the five articles the numbers point at. Then measure at the ticket, not the pageview, and resist the urge to write the other thirty-five.
Your tickets already know what to document
Helpdesk and knowledge base in one place — see which questions repeat, draft articles from resolved tickets, and measure whether they actually deflect.