Documentation decays in the dark: written once from the author's mental model, aging as the product ships, gaps invisible until you count the tickets they cause. Live support sessions flip the lighting, every resolution is evidence about what the docs failed to do, and a knowledge base wired to that evidence starts healing instead of rotting.
Why docs rot, structurally
Three blind spots. Authors write from the expert's model: the doc describes the system as its builder understands it, while users arrive with tasks, vocabulary, and confusions the author can't simulate. Feedback barely exists: a "was this helpful?" widget collects shrugs; the users who couldn't find the page never vote at all. And drift is silent: the product ships weekly, and no alarm rings when a screenshot's button moves or a procedure gains a step. The result is a corpus that's simultaneously large and unhelpful, and a support queue quietly paying the difference.
What live sessions reveal that analytics can't
A screen-aware support session captures the whole failure, not just the search query: what the user was trying to do, what the doc said, where the described path diverged from the real one, what actually resolved it. Aggregated, that's a ranked repair list with unprecedented precision, this article's step four no longer matches the interface; this error message needs its three causes distinguished; this workflow has no doc at all and generates weekly sessions; this doc is fine but unfindable under the words users actually use. The sessions also capture the fix that worked, phrased in the user's vocabulary, which is exactly the raw material the repair needs.
The healing loop, run honestly
Humans stay the editors; the sessions supply the evidence. Monthly: rank doc-implicated sessions by volume and cost, repair the top offenders using the session-derived fix language, and route the no-doc-exists clusters to whoever owns new content. Verify healing the only way that counts: sessions and tickets caused by that doc, before and after. Two disciplines keep it honest, don't auto-publish (session-derived drafts are inputs; editorial judgment and confidentiality review remain human), and watch the vocabulary gap (many "missing" docs exist under words users don't search; retitling is the cheapest repair in the program).
The compounding endgame
A healing knowledge base makes every layer above it better: the support agent grounds on cleaner sources, deflection at the knowledge layer improves for the documented questions, and the sessions increasingly concentrate on genuinely novel problems, which is what your experts wanted to work on anyway. (Disclosure: Skippr's support agent documents sessions and escalations as a matter of mechanism; pointing that record at your docs backlog is the loop this post describes.)
Questions buyers actually ask
Does the AI rewrite the docs itself?
It supplies evidence and drafts; humans edit and publish. Auto-published docs trade one decay mode for another.
How is this different from ticket-driven doc requests?
Tickets name topics; sessions capture the exact divergence between the doc and reality, plus the working fix in the user's own words.
What's the first thing to fix?
Usually titles and vocabulary, the docs that exist but hide. Cheapest repairs, immediate ticket impact.
See it handle a real question
A support answer either resolves the thing or describes it. Fifteen minutes is enough to see which one you are getting.