Support chatbot
Support answers your
customers can trust
Every answer comes from documentation that was generated from your code and
checked against your running system — with a link to the exact section it came from.
And every question it can't answer goes back into Git2Docs, so the
gap that failed one customer is closed before the next one asks!
On every page you publish, in your brand colour.
Where the answers come from
A stale page doesn't just mislead one reader
It gets repeated, confidently, to every customer who asks — in a channel where nobody checks the "last updated" date. Documentation drift is an annoyance on a page and a support incident in a chat window. Which is why what the assistant is allowed to read matters more than how it answers.
Answers come from committed source
Derived from your repository, not uploaded to a knowledge base — so it can be checked against the code.
Documentation that failed its check can't answer
A section whose last validation failed is excluded from retrieval until it is fixed.
No second knowledge base to keep in sync
Sections index on publish and stay scoped to the published version — an AI knowledge base your team doesn't maintain, with nothing to re-upload after a release.
Verified and generated content are labelled
Each section carries what it is, so the assistant hedges where the evidence is thinner.
Product claims are cited, background isn't faked
Anything specific to your product links to its section. General knowledge can bridge, never assert.
Small products skip retrieval entirely
When the documentation fits in one prompt, the assistant reads all of it. Perfect recall, nothing missed.
The eligibility rule
What your customers never see
Most of the work of a trustworthy support answer is subtraction. Four categories of content are held back, and two are let through.
Sections that failed validation
A documented command, flag or endpoint that didn't behave as written when it was last exercised against the running system.
Contested sections
Where a human edit and a regeneration disagree and nobody has resolved it yet. An unresolved disagreement is not an answer.
Low-confidence generated content
Generated content reasoned across files rather than read from the code keeps its confidence tier, and the lowest tier doesn't answer customer questions.
Anything not in the current version
Retrieval is scoped to the published version a reader is on, so superseded pages don't surface as current behaviour.
Verified and high-confidence sections
Author-verified content, agent-corrected content, and generated content extracted directly from the code — the documentation that earned the right to answer.
General domain background
Bounded general knowledge about the platforms your product is built on, used to bridge a reader to an answer, never to assert what your product does.
The honest part
Saying "I don't know" is a feature, not a failure
The expensive failure in support isn't the deflection you miss. It's the answer that sounded right, cost someone an afternoon, and arrived as a ticket anyway — angrier. Every reply here is tagged by what it actually did — which is also where the honest line sits between what AI can take off an L1 queue and what belongs with a human.
Can I pin a worker to a specific availability zone?
Scheduling constraints are documented for node selectors and taints §4f2a91, but the documentation doesn't cover pinning by availability zone specifically. The closest page is Deployment → Scheduling.
no_answerThe compounding part
Every question it can't answer belongs to someone
Support traffic is the highest-signal research your company will ever get: real users, their own words, at the moment they are stuck. Most of it dies in a transcript nobody opens. Here it is grouped by meaning, ranked by how many people asked, and sorted into the three things an unanswered question can actually mean.
A documentation gap
The answer was derivable from your code and the page didn't carry it. Each cluster links to the section retrieval came closest to — usually the fastest page to fix. Close it at the source and the page regenerates, validates, and answers the next person who asks.
Owned by docs
A product signal
Sometimes the documentation is fine and the product is the gap — people are asking for something it doesn't do. Those clusters are separated out and kept as a capability request with evidence attached: how many distinct people asked, which versions they were on, and their own words.
Owned by product
A knowledge gap
Some answers were never in the code to begin with — a compatibility matrix, a migration caveat, the reason behind a default. These surface as the content your team knows and has never written down, authored once and then maintained alongside everything generated.
Owned by support and engineering
What you can actually report
The numbers a support lead needs in a QBR, without instrumenting anything.
Answer quality
Answered, partial and unanswered over 30 days, with thumbs and volume beside it.
Which documentation carries support
The sections cited most often — the pages doing the deflection, rarely the expected ones.
Where it's falling short
The most-asked questions it couldn't answer, each pointing at the page that closes it.
Documentation health
Ownership, confidence tier and validation status across your current sections.
Freshness
When documentation last regenerated, and the gap before that.
Demand signals
Capability requests from real support traffic, rolled up by how many asked.
Four questions to ask any documentation chatbot
Including this one. They're the questions that separate a retrieval layer from an accuracy claim — and they're worth asking of a documentation MCP server too, since agents query the same sections your customers do.
Ask it something that doesn't exist.
Invent a flag and ask what it does. A bot grounded in checked content tells you it isn't documented. A bot grounded in plausibility describes it for you.
Can an answer tell you where it came from?
Not a link to a page — the section. If a claim can't be traced to a specific piece of content, nobody can audit the answer after a customer acts on it.
What happens to content that's known to be wrong?
Ask whether a page flagged as inaccurate is still eligible to answer from. For most tools it is — the flag lives in a dashboard, not in the retrieval path.
Where do the questions it couldn't answer go?
If the answer is "a transcript", the bot is a deflection tool and nothing more. The questions it fails are the most valuable thing it produces.
FAQ
Questions this approach raises
How do you stop a support chatbot from confidently giving a wrong answer?
Does the chatbot need a separate knowledge base?
What happens when the documentation doesn't cover the question?
What do unanswered support questions do for the documentation?
Can the chatbot answer general technical questions, not just product questions?
Give your customers an answer worth trusting
Generate documentation from your repository, measure it against your code, and let it answer your customers. Free for 30 days, no card.