Every article about AI and customer support assumes you deployed the bot. Meanwhile your existing customers are asking public models how to configure your product, why a feature is not working, and whether you support something you shipped last quarter. Nobody in your company sees those conversations.
The support automation industry has spent two years solving the problem of grounding your own assistant in your own documentation. That work is real and useful.
It also addresses the channel you control. The uncontrolled one is larger, invisible, and answering from sources you have not looked at in years.
Key Takeaways
- This is not about your chatbot: customers use public models regardless of what you deployed.
- The answers come from old material: superseded tutorials, archived docs versions, and years-old forum threads.
- The damage is post-sale: failed onboarding, wrong-premise tickets, and churn from capabilities customers think you lack.
- It needs a different prompt set: how-to and troubleshooting questions, not category or comparison queries.
- Ownership is unclear by default: it sits between support, product, docs, and marketing.
What Customers Are Actually Asking
Post-purchase questions look nothing like pre-purchase ones, and they are the ones nobody tests.
- How do I set up a specific integration in your product.
- Why is a particular feature not doing what they expect.
- Whether your product can do something at all.
- How to export their data, change their plan, or cancel.
- How your product compares to the one they are considering switching to.
A customer asking a public model these questions is doing what used to be a search of your help centre. The difference is that the model answers from whatever it has, and your help centre is only one input among several. Which inputs dominate varies by engine, since platforms draw on largely different sources.
Where the Wrong Answers Come From
Four sources produce most of the damage, and only one is under your direct control.
Superseded documentation versions
Documentation sites that maintain multiple versions frequently leave older ones indexable. A model retrieving your v2 setup guide will describe a flow that no longer exists, confidently, with a citation that looks authoritative because it is genuinely your domain.
Third-party tutorials
Blog posts, YouTube walkthroughs, and integration guides written by users and partners. These were accurate when published and are frequently never revisited. They tend to be highly specific, which makes them unusually citable, and they age badly after any interface change.
Community threads
Forum answers, subreddit posts, and community discussions where a user described a workaround for a limitation you have since removed. The thread persists, the limitation does not, and the model has no signal that anything changed.
Your own stale pages
Changelog entries, deprecated feature pages, and old comparison content that you left up because nothing pointed to them. Something now does.
What It Costs
A wrong pre-sale answer costs you a deal you might not have won. A wrong post-sale answer costs you a customer who already paid, plus the support hours spent unwinding what they were told.
Four consequences, roughly in order of how easily they go unnoticed.
Tickets that start from a wrong premise. A customer arrives having already tried steps that do not apply, and support spends the first exchange establishing what actually happened rather than solving anything.
Onboarding that fails quietly. A new user follows an outdated setup guide, hits a wall, and does not open a ticket. They just do not activate, and nothing in your funnel data explains why.
Churn from the capabilities you have. A customer asks whether your product supports something, gets told no on the basis of a two-year-old thread, and evaluates alternatives. You never hear about it.
Compliance exposure in regulated contexts. If a model describes your security posture, data handling, or regulatory position from outdated material, that description enters conversations where accuracy carries weight.
Why This Is Not Your Chatbot Problem
| Your deployed assistant | Public models | |
|---|---|---|
| Sources | What you indexed | Everything public about you |
| Visibility | Full conversation logs | None |
| Fix for a wrong answer | Update the indexed doc | Correct or displace the source |
| Who notices | Support analytics | Usually nobody |
| Speed of fix | Same day | Weeks to months |
Grounding your own assistant does nothing for the second column. The customer who asked a public model never touched your product surface at all, which makes this a source-accuracy problem of the same kind that our work on citation freshness examines on the marketing side.
How to Audit It
The method resembles category visibility testing but uses a completely different prompt set, which is why it rarely gets run.
Build the prompt set from support data
Export your top ticket subjects from the last two quarters and convert each into the question a customer would type into a public model. These are questions you can prove people ask, which is better than any list you would write from scratch.
Add the ones customers never file tickets about: how to cancel, how to export data, and whether you support the thing your roadmap shipped most recently.
Record the source, not just the answer
For each wrong answer, identify which specific page or thread produced it. This is the actionable output. An audit that ends with "the answers are outdated" gives you nothing to do on Monday.
The distribution usually surprises people. A single community thread frequently turns out to be producing several unrelated wrong answers, which makes it the highest-value correction available.
Sort by fixability
Your own stale pages are immediate: deindex, redirect, or update. Old documentation versions usually need a canonical or noindex decision that somebody has been deferring. Third-party tutorials need outreach. Community threads need a reply, not a takedown request.
What Actually Fixes Each Type
Old doc versions: make the current version unambiguously the canonical one, and consider whether archived versions need to be publicly indexable at all. This is often a fifteen-minute configuration change that nobody owns.
Third-party tutorials: contact the author. Most will update a post that is now wrong, particularly if you supply the correction. This works better than it sounds because the author's incentive aligns with yours.
Community threads: reply in the thread with a dated correction rather than attempting removal. A visible, specific update becomes part of what models retrieve, and removal attempts frequently fail or draw attention.
Missing coverage: if a question generates tickets and has no good public answer anywhere, that is a documentation gap producing both support load and wrong AI answers simultaneously. Fixing it addresses both.
Who Should Own This
By default nobody does, which is the main reason it persists.
Support sees the ticket volume but not the cause. Documentation owns the current version but not the archive or the third-party material. Marketing runs AI visibility work but tests category questions rather than troubleshooting ones. Product ships the changes that make old content wrong without anyone tracking what became stale.
The workable arrangement is for whoever already runs AI visibility testing to add the support prompt set, and for support to supply the questions quarterly. Neither team needs new tooling, and the combined view is more useful than either alone.
The Underlying Point
Companies have spent considerable effort making sure a model gives the right answer about whether to buy their product, and almost none making sure it gives the right answer about how to use it.
The second question is asked more often, by people who have already paid, and gets answered from material nobody has audited. Our AI Recommendation Gap report covers how much of what models say about a company originates outside its own control, and that dependency does not stop at the point of sale.
FAQs
1. Why do AI assistants give wrong instructions about my product?
Because they answer from everything public about you, not only your current documentation. Superseded doc versions, third-party tutorials written before an interface change, and old community threads describing removed limitations all remain retrievable and are frequently more specific than your current pages.
2. Does deploying my own support chatbot solve this?
No. Grounding your own assistant controls answers from customers who use it. Customers asking ChatGPT, Perplexity, or Gemini directly never touch that surface, and those models draw on public sources instead.
3. How do I find out what models tell my customers?
Build a prompt set from your top support ticket subjects, converted into questions a customer would type, and add the ones people rarely file tickets about such as cancellation and data export. Record both the answer and the specific source that produced it.
4. Should I remove old documentation versions?
Usually you should make the current version unambiguously canonical and decide deliberately whether archived versions need to be publicly indexable. Many teams leave old versions indexed by default rather than by decision, and models retrieve them as authoritative because they sit on your domain.
5. What do I do about wrong information in community threads?
Reply in the thread with a dated, specific correction rather than seeking removal. The correction becomes part of what models retrieve, while removal attempts often fail and occasionally amplify the original. This applies equally to outdated third-party tutorials, where contacting the author usually works.
This describes an auditing method rather than a measured study. Which sources dominate varies considerably by product category, documentation structure, and how active the relevant user communities are.
