9 min read
Support assistants are sold on deflection rate — the share of questions that never reach a person. It is a clean number to put on a slide and a cleaner one to improve, because the fastest way to raise it is to answer everything.
An assistant that answers everything will answer the things it does not know. Not deliberately, and not with any signal that it is doing so. It will have read enough adjacent material to assemble a paragraph that reads exactly like the paragraphs that are correct, and it will hand that to your client's customer with your client's logo above it.
The deflection rate goes up. So does the number of people following a step that does not exist.
Scope is the first decision
Doc AI answers from one hub's published docs and nothing else.
Not your other hubs. Not the general knowledge the model arrived with. Not its own earlier answers in the same conversation, which is the quiet one — an assistant allowed to build on what it already said will cheerfully compound a wrong turn for four exchanges.
That scope is narrow on purpose, and it is what makes the answers checkable. When Doc says something on a client's help center, the material it came from is material that client can open and read. There is no third source to account for.
Drafts are outside the scope too. A guide you have written but not published is invisible to Doc, the same as it is invisible to every reader.
Every answer carries its source
Doc cites the guide and the step each answer came from, underneath the answer.
The citation is there for the reader, who can open the guide and confirm it, and it is there for you. An answer with a source attached is an answer you can audit. If Doc gets something wrong, the citation shows you which guide is wrong — and the fix is to correct the guide, which corrects the answer, and also corrects the guide for the next person who reads it directly.
That is the loop worth having. The alternative is discovering, months later, that the chat has been confidently wrong about something with no record of where it got the idea.
The handoff
When the docs genuinely do not cover a question, Doc opens a ticket instead of guessing.
The reader gets a plain sentence: this is not covered in the documentation yet, and someone will reply. No apology performance, no suggestion that they rephrase it, because rephrasing does not add a guide that was never written. Their question stays in their thread, and your reply appears in that same thread when you write it.
The ticket lands in your Inbox with the question in the words the reader actually used.
The unanswered question is the useful one
Here is why this ends up being the most valuable thing the chat does.
Documentation is written from the inside. You write a guide about the thing you understand, using the words you use for it, in the order that makes sense once you already know how it works. That is unavoidable and it is also why guides have holes in exactly the places their author could not see.
A ticket is the outside view, arriving unprompted. It is a real person, stuck, describing the problem in their own vocabulary — which is frequently not your vocabulary, and that mismatch is itself a finding.
Read a month of your Inbox and you have a writing queue, in priority order, ranked by how many people needed something that was not there. Nobody has to run a content audit to produce that list. It assembles itself out of the questions you had to answer by hand.
What that means for the number
A question that reaches you is not the chat failing. It is the chat doing the one thing that keeps every other answer worth trusting, and handing you the single clearest signal there is about what to write next.
Write that guide, and the question stops arriving. Which moves the deflection rate too — by documentation rather than by confidence.
Ready to write it once?
Capture a process, publish it as a help center under your own name or a client's, and answer the repeat questions from what you published.