guide

Support Documentation That Actually Deflects Tickets

Most help centres are written for the company, not the person stuck

By AR · Published 4 August 2026 · 10 min read

The first organic result for how to reduce support ticket volume is a Reddit thread. When a forum post outranks eight vendor blogs, the SERP is telling you those blogs are not answering the question.

What follows is the part they skip: which documentation deflects, which does not, and how to tell yours apart.

Freshness beats coverage, and it is not close

The single largest finding in this area: knowledge bases refreshed within 30 days show around 45% deflection, against 18% for those left six months — on identical software.

That is a bigger difference than any platform choice, any writing technique and any AI layer on this page. A team with sixty current articles will deflect more than a team with four hundred stale ones, and the four-hundred-article team will spend the year wondering why their investment is not paying back.

It also reframes the work. Documentation is not a project that completes; it is a maintenance obligation. If nobody owns it, coverage grows and deflection falls, which looks paradoxical on a dashboard and is entirely predictable.

The four types that deflect

The one-step answer

How do I change the email on my account. One screen, one path, no preamble. These are boring to write, nobody links to them, and they carry most of the deflection in any help centre.

The status page

During an incident it is the highest-deflection page you own by an enormous margin, and it only works if customers already know it exists. Linked from the help centre header, not discovered during the outage.

The error message page

One page per error string a customer can actually see, titled with the exact string. People paste error text into search verbatim. If your page says troubleshooting connection issues and the error says ERR_TUNNEL_FAILED, the page does not exist as far as that customer is concerned.

The honest limitation

A page that says the product does not do this, here is what people do instead. Uncomfortable to publish and it deflects permanently, because the alternative is a ticket that ends with an agent saying the same thing more slowly.

The three that never deflect

TypeWhy it fails
The feature tourAnswers what the product does. Nobody in the queue is asking that
The long getting-started guideAnswers twelve questions for someone with one. They leave and open a ticket
The marketing FAQQuestions written by whoever wanted them answered, not questions anyone asked

The last one is the most common failure in the category. A genuine FAQ is built from ticket data. Anything else is a landing page with a chevron.

Writing from tickets, not from the roadmap

The method that works is unglamorous. Export ninety days of tickets, group by what the customer was trying to do rather than by product area, sort by volume, and write the top twenty. Use the customer's words in the title — including the wrong words, because those are what gets searched.

Product-area grouping is where most help centres go wrong. Customers do not think in your information architecture; they think in the thing that went wrong. A section called Billing is worse than five pages titled with the five billing questions people actually ask.

Measuring which ones work

Views are not deflection. The measurement that matters is the ticket that follows.

  • Track whether a ticket was opened within thirty minutes of a help centre session. That ratio, per article, is the only honest deflection figure available without instrumentation you do not have.
  • Track searches that return nothing. This is the highest-value list in your help centre and almost nobody reads it — it is your customers telling you exactly what to write next, in their own words.
  • Track searches that return results and end in a ticket anyway. The article exists and fails, which is a different fix from the article not existing.
  • Review escalation reasons weekly. The recurring ones are documentation gaps wearing a different hat.

Where AI changes this, and where it does not

An AI layer answers from what you have written. It does not know things you have not documented, and it will state your six-month-old refund policy with complete confidence — which is worse than a stale article, because nobody reads an AI answer before it sends.

So the sequence matters. Documentation first, AI second. Teams that do it the other way round buy a platform, see 12% resolution, blame the platform, and the constraint was never the software.

What AI genuinely adds is retrieval. It finds the right paragraph in a badly-organised help centre far better than site search does, which means the AI layer forgives poor structure and does nothing at all for poor content. That distinction is worth holding on to before any purchase.

The 30-day and six-month deflection figures are from published research and dated in our deflection benchmark piece. The article typology is our analysis, drawn from what recurs in support-team discussion rather than from any published study.

Frequently Asked

How do I reduce support ticket volume?

Refresh documentation before adding to it. Knowledge bases updated within 30 days show around 45% deflection against 18% for those left six months, on identical software — a bigger effect than any platform choice.

What makes a help centre article deflect a ticket?

One question, one answer, the customer's words in the title, and no preamble. The highest-deflecting articles are the boring one-step ones nobody links to.

Which help centre articles do not deflect?

Feature tours, long getting-started guides, and marketing FAQs built from questions nobody asked. All three answer what the product does rather than what the person stuck is trying to do.

How do I know which articles are working?

Track whether a ticket is opened within thirty minutes of a help centre session, per article. Views are not deflection.

What should I write first?

Export ninety days of tickets, group by what the customer was trying to do, sort by volume, write the top twenty. Not by product area — customers think in what went wrong, not in your information architecture.

Should I write documentation or buy AI first?

Documentation. An AI layer answers from what you have written, so buying first produces a low resolution rate that gets blamed on the platform when the constraint was always the content.

What is the most under-used help centre report?

Searches that return nothing. It is your customers telling you exactly what to write next, in their own words, and almost nobody reads it.

How often should help centre articles be reviewed?

Within 30 days for anything covering pricing, policy or a changing flow. Documentation is a maintenance obligation, not a project that completes.

Does more coverage mean more deflection?

No. A team with sixty current articles will deflect more than a team with four hundred stale ones, which is why coverage growing while deflection falls is predictable rather than paradoxical.

Should I document things the product cannot do?

Yes. It is uncomfortable to publish and it deflects permanently, because the alternative is a ticket that ends with an agent saying the same thing more slowly.

Tools Mentioned

Full reviews, pricing tiers and where each one breaks.

You Can Also Look Into

WRITTEN BY AR · UPDATED 2026-08-04

I read the fine print. Vendor pricing pages, billing definitions, terms, funding filings and acquisition notices — then I do the arithmetic nobody publishes: what a platform actually costs at your volume, what its headline metric is really counting, and who owns it now. I do not run benchmarks, and no page here pretends otherwise.

How we work · About the author