Ask a documentation team how they handle feedback and you will hear about the collecting: a thumbs-up widget on every page, a support inbox, a chatbot with a rating button. Ask what happened to last month’s feedback and the answer gets quieter. A spreadsheet, maybe. A Jira board with 140 open items. A good intention to “go through it in the next docs sprint”.
That is an open loop, and open loops are expensive. Readers who report a problem and see nothing change stop reporting. The same question keeps arriving in support. And the writer who finally sits down with the backlog has to reconstruct, for each item, what the reader wanted, which page they were on, and whether anyone fixed it already.
A closed loop has four steps: collect, triage, fix, and confirm. This post walks through doing all four for a documentation site with an AI assistant on it, using the ChatbotIQ Docs Insights MCP server inside Claude, ChatGPT or Claude Code. The loop closes in one chat, from the reader’s complaint to the moment the assistant answers from the corrected page.
Why the loop stays open
It is not laziness. The loop breaks at three joints:
- The feedback lives in one place and the writing happens in another. Ratings sit in an analytics dashboard. Pages live in Confluence, Notion or a Git repo. Every item has to be carried across by hand, and most of them are not.
- Feedback says “bad”, not “what”. A thumbs-down on a page does not tell you which paragraph failed, or whether the page was even the right one. Working that out is the slow part, so the backlog grows faster than it drains.
- Nothing confirms the fix. Someone edits a page and the item is closed on trust. If the site was not re-read by the assistant, or the new heading still does not match the question, the same complaint comes back next month and nobody connects the two.
Fix those three joints and the rest is a routine.
What you are collecting
If an AI assistant answers questions on your docs, it is already collecting better feedback than any widget, because it sees the question and the answer together:
- Thumbs-down replies: a reader said the answer was wrong or unhelpful.
- Declined questions: the assistant said “that is not in the documentation”. Nobody complains about an honest decline, which is why these go unnoticed.
- Low-confidence answers: the assistant found something loosely related and answered anyway. These produce the confident, wrong replies that cost you trust.
- Reports from readers’ own AI agents. When developers point a coding assistant at your docs, it can report a page as wrong, outdated or confusing and quote the passage. Three agents reporting the same paragraph in a week is feedback with the sentence already highlighted.
All of this is in your ChatbotIQ workspace. The Docs Insights MCP server hands it to the assistant you write with, so the loop runs where the writing happens instead of in a dashboard you visit when you remember to.
Step 1: Connect the assistant you write with
You need a ChatbotIQ workspace on a paid plan (the trial counts) and membership in it. Any member can read; owners and admins can also grant the write permission used to mark items done.
- In ChatbotIQ, open Analytics > Docs Insights and copy the endpoint for your client. It looks like
https://app.chatbotiq.eu/v1/mcp/workspaces/<workspace-id>/mcp. - Add it to your client:
- Claude.ai or Claude Desktop: Customize > Connectors, +, Add custom connector, paste the endpoint, Connect, sign in to ChatbotIQ and click Allow access.
- ChatGPT: turn on developer mode, open chatgpt.com/plugins, Add > New plugin, paste the endpoint as the server URL, choose OAuth, sign in and allow.
- Claude Code:
claude mcp add --transport http chatbotiq-insights <endpoint>, then/mcpto sign in. - Cursor and other clients: create a personal access token on the Docs Insights page and add the server with the token in the Authorization header.
- In a new chat, turn the connector on and ask: what can this do?
The assistant answers with a snapshot of what is waiting: problem conversations from the last seven days, new reports from readers’ agents, the pages reported most often, and a suggested first step. The full setup, including Claude Team plans and troubleshooting, is in the Docs Insights how-to.
Step 2: Triage, with the cause worked out for you
Run the Weekly documentation review prompt from the connector’s menu, or ask in plain words:
What did readers complain about in the docs assistant last week, and where should I fix it?
The assistant pulls the week’s problem conversations and the most-reported pages, groups them by topic, works out a cause and a target for each, and shows a table like this:
| Topic | Turns | Agent reports | Cause | Page and section | Proposed change |
|---|---|---|---|---|---|
| Webhook retry policy | 7 | 2 | content gap | Webhooks > Delivery | Add the retry schedule and max attempts |
| SSO with Okta | 5 | 0 | not found | Authentication > SAML | Rename the section; “Okta” is not in any heading |
| Export to CSV | 4 | 0 | answer quality | Reports > Export | Split the 400-word paragraph into steps |
| Pricing in CHF | 3 | 0 | out of scope | none | Ignore, or add a one-line FAQ |
(This example is shortened and made up. The real table links every row to its conversations.)
Then it stops and asks which rows you want to work on.
The cause column is what makes triage fast, because only one cause means “write something”:
- Content gap: the docs do not contain it, or it is outdated. Yours to fix.
- Not found: the answer exists and the assistant did not find it. Not a writing job; pass it to whoever runs the assistant.
- Answer quality: the assistant had the right material and still answered badly. Usually a dense or hedged section; tighten it if it really is confusing.
- Out of scope: not about your product.
The page and section are always chosen from pages that are actually indexed, and the heading is copied from the page’s own outline. You will never be sent to a section that does not exist. For reports from readers’ agents, the quoted passage tells you which paragraph, not just which page.
Step 3: Fix the page, with the assistant reading it
Pick a row and ask:
Read the target page and draft the change for the webhook retry topic.
The assistant reads the current page, drafts the new section in the page’s own style, and says when a fact has to come from an engineer rather than be guessed. The retry schedule in the example is exactly that kind of fact.
Apply the change in your own documentation tool. The server never edits your docs. If your tool has its own connector, such as Confluence, Notion or GitHub, the draft goes into it from the same chat; otherwise paste it.
Step 4: Close the loop, and prove it
This is the step that turns a fix into a closed item. After you publish:
Mark the webhook retry items as docs updated, resolve the matching agent reports, and re-sync the source.
Three things happen. The outcome is recorded on each conversation. The reports from readers’ agents are set to resolved, so they leave the list of new reports. And a refresh of the source is queued, so the assistant reads the corrected page.
When the refresh has finished, ask for the proof:
Search the docs for “how many times is a webhook retried” and show me what comes back.
If the new section comes back, the loop is closed in the only sense that matters: the next reader who asks gets the right answer. If it does not come back, you have caught a fix that would have failed silently, before the complaint returned.
Re-sync works for website, Confluence and Notion sources. For uploaded files, upload the new version in the dashboard and run the same search afterwards.
Step 5: Let the team see it
A loop is only closed if someone other than you knows. The outcome you recorded shows up as Docs updated next to the conversation in the ChatbotIQ dashboard, with the suggested fix and who addressed it, so your manager and your support team see it without opening a chat. Items that were not a documentation problem show that too, which is how “the docs are wrong” conversations with engineering get shorter.
Resolved agent reports disappear from the bot’s list of new reports, and the people who get the daily digest of new reports stop seeing that one.
The weekly routine
- Monday, 20 minutes. Run the weekly review. Pick the two or three content-gap rows with the most readers behind them. Forward the “not found” rows to the assistant’s admin.
- During the week. Draft each fix with the assistant reading the page. Get the facts from the feature owner. Publish.
- After publishing. Mark as updated, resolve the reports, re-sync, verify with a search.
- Next Monday. The table is shorter, and every row still on it has a count you can show.
For a quarterly view, ask for the same questions clustered by topic instead of raw conversations; that is the version to bring to a planning meeting. But the weekly loop is what empties the backlog.
Frequently asked questions
Does this work with ChatGPT, or only with Claude? Claude.ai, Claude Desktop, ChatGPT and Claude Code connect with a sign-in. Cursor and other MCP clients connect with a personal access token. Anything that speaks MCP over HTTP works.
Do I need to be a developer? No. Connecting is a copy-paste in your client’s settings. After that it is a conversation. The only command-line step is for Claude Code, which is a developer tool anyway.
Will the assistant edit my documentation? No. It reads conversations and pages, drafts changes, records outcomes and queues the re-read. Writing happens in your own tool.
Who can see our readers’ conversations? Only members of the workspace, each with their own sign-in. Emails, phone numbers and similar personal data are masked before anything leaves ChatbotIQ. Owners and admins see every active connection and can revoke any of them, and every call is logged.
How far back does it look? Thumbs-down and unanswered conversations as far back as you need, up to 400 days per request. Declined and low-confidence questions cover the last 90 days.
What if I don’t have a docs assistant yet? Then there is nothing to close the loop on. Put an assistant on your documentation first; a few weeks of real questions is enough to run the first review.
Docs Insights is included in every paid ChatbotIQ plan and in the free trial. The step names above match the dashboard and the documentation as of October 2026.