Turn unanswered support questions into help articles

A miss is only wasted if nobody writes

Support tickets and chatbot logs already contain the titles your help center is missing. Customers ask in their words: “SSO from Okta,” “webhook fired twice,” “seat limit on Pro.” Writers title the same ideas “Enterprise authentication” and “Retries.” The gap is vocabulary as much as coverage.

If the bot invents an answer, you never see the gap — you see a five-star chat that taught the wrong setup. That is why usedocs files low-confidence questions instead of completing them from model memory. The Monitor inbox and weekly digest exist so a human can decide what to publish.

A cited refusal plus a draft is cheaper than a ticket. The visitor did not get fiction. You got a writing queue. The widget stays the place people ask. The help-center link is where they read the page you just published. Chat without that publish step is only a demo.

Capture every weak answer, not only tickets

Ticket tags are a lagging signal. By the time something is a ticket, several visitors already bounced. Capture:

• Questions the bot refused.
• Questions with thumbs-down or “not in the docs.”
• Searches on the help center that returned nothing (if you have that log).
• Sales and Discord repeats that never became tickets.
• The same how-to asked with three different product names.

usedocs clusters chat misses automatically. If you are not on usedocs yet, dump a month of tickets into a sheet and group by theme. Five clusters is enough to start. A free first look at public docs coverage is /tools/gap-audit

Cluster before you write

Do not write one article per raw question. Group by the page a support agent would send:

• Auth / SSO / SCIM
• Webhooks and retries
• Billing, seats, plan limits
• Install / API keys / environments
• Version or migration notes

Pick the cluster that hit production chat most often last week. One published article that the bot can cite beats six drafts in a doc no one shipped. Ignore one-off questions until they repeat.

If a miss is actually a product bug, file it in the issue tracker. Do not write a workaround into the help center as if it were a feature.

Draft with the customer’s words in the H2s

Open the cluster. Use the most common phrasing as an H2, then answer in steps a stranger can follow. Retrieval later needs the same facts a support agent would paste into a ticket reply.

A publishable draft should include:

• The customer phrasing in at least one H2.
• The exact error string or numeric limit, not a paraphrase.
• The setting URL or dashboard path a stranger can follow.
• A last-updated note if the product just changed.

usedocs can draft from a gap. Treat the draft as a first pass. A human still approves before anything is public. Auto-publishing model text is how you ship the same hallucination you tried to avoid — only now it is a canonical page.

If a GitHub merge already changed the product, connect the repo so PR and release notes can spawn a draft article or changelog entry. Still review. Still publish by hand.

Publish, recrawl, rerun the original question

Ship the article to the help center (or your existing GitBook / portal). Recrawl or wait for the daily resync. Ask the original customer question in the test chat. You should see the new URL in citations. If you do not, the article is live for readers and still invisible to retrieval — fix that before you call the gap closed.

If the citation is still the old overview page, the new article’s title and H2s do not match the question language. Fix the headings; do not add more model instructions.

This closed loop is the difference between a chatbot demo and a docs operation. Ferndesk-style products start from “the CMS updates itself.” usedocs starts from “the chat told you what to write.” Both can be valid; pick the center of gravity you actually staff. Comparison: /compare/ferndesk

Cadence that survives a small team

A realistic weekly rhythm for one founder or a two-person DX team:

• Monday: skim the gap digest. Pick one cluster.
• Tuesday: draft and approve one article (or reject the draft).
• Wednesday: publish + recrawl. Rerun last week’s failed question.
• Thursday: check whether the widget now cites the new page.
• Friday: if a miss is actually a product bug, file it in the issue tracker instead of writing fiction into the help center.

You do not need a full docs department to run this. You need a bot that will admit ignorance and a place to publish the fix. The widget stays the front door; the help-center link is where people read the source.

Free is 100 messages per month — enough to collect a real queue. Pro is $29 for 5,000. Growth is $79. Business is $299. Start free at /dashboard