Which questions should become help articles?

The high-volume ones with a clear self-serve answer. Rank candidates by how well an article could deflect the ticket — "reset password" ranks high, "my package is lost" ranks low because it needs a human. Not every frequent question should be an article.

How do I stop Claude inventing steps it doesn't actually know?

Tell it to leave a [confirm the steps] marker wherever it doesn't know your product's real flow, instead of guessing. One wrong instruction in a help article generates the exact ticket it was meant to prevent, so you fill those markers in from the real product.

Why build articles from tickets instead of what I think confuses people?

Because the trap is writing for confusions you assume exist. Sourcing from real tickets — or the top clusters from Find what the queue is really about — means the help center maps to actual demand and deflects the questions you genuinely get.

Do I need to do anything before publishing?

Click through every numbered step in the real product before it goes live, and keep the "still stuck?" exit honest so a confused reader always has a human to reach. Claude drafts the articles; a human owns publishing them.

Build a help center from the questions you actually get

when to reach for this

Some questions never stop coming — how to reset a password, where to find an invoice, how to change a plan — and a canned reply only answers the next one customer. A help center answers the cause: a searchable article means the question gets solved before it ever becomes a ticket. The trap is writing help articles from what you assume people are confused about; the fix is building them from the tickets you actually get, in plain language, with numbered steps and a "still stuck?" line — so the article deflects the question instead of generating an angrier follow-up.

gather this first

The real questions, sourced from tickets — a tickets.csv export you drop into the chat in Claude Desktop, or the top clusters from the Find what the queue is really about playbook. Scrub names and emails first.
The actual steps for each task, however rough — the real button names and screen labels a customer sees, so the article matches reality, not a guess.
Your voice and reading level: friendly, plain, written for someone frustrated and in a hurry — not a spec.

the workflow

Pick the articles that will deflect the most tickets

Write articles in volume order, not in the order they come to mind. The point of a help center is deflection, so you start with the questions that flood the queue.

you ask

Here are our top question clusters with counts. Rank them by how well a good help article could DEFLECT the ticket — high volume plus a clear self-serve answer ranks highest; 'my package is lost' ranks low because it needs a human. Give me the top 8 to write first and one sentence on why each.

what you get back A ranked shortlist — "reset password (deflectable, 47/wk), find your invoice (deflectable, 31/wk)" — with the human-only ones flagged as poor article candidates, so you spend effort where it pays back.

Not every frequent question should be an article — the ones that genuinely need a human shouldn't be self-serve, and saying so up front is the difference between a help center and a wall.
Draft one article in the right shape

Lock the format on a single article — short intro, numbered steps, a 'still stuck?' line — before generating eight, so the whole set is consistent and skimmable.

you ask

Write the 'reset your password' article in our voice: a one-line intro telling the reader they're in the right place, numbered steps using our real button names (I'll give them to you — Sign in, Forgot password, Check your email), and a 'Still stuck?' line at the end pointing to how to reach us. Plain language, written for someone in a hurry. Under 150 words.

what you get back A short, friendly article — one-line intro, clean numbered steps in real button names, and a warm "Still stuck? Reply here and we'll sort it" closer — skimmable in fifteen seconds.
Batch the rest against that template

Generate the remaining articles to the same structure in one pass, so they read as one help center instead of eight different authors.

you ask

Using that exact structure — short intro, numbered steps in real button names, a 'Still stuck?' closer — draft the other 7 articles from the shortlist. Where you don't know the real steps, leave a [confirm the steps] marker instead of inventing the flow. Keep each under 150 words and the reading level simple.

what you get back Seven more articles in the same skimmable shape, with [confirm the steps] markers wherever Claude doesn't actually know your product's flow — so you fill those in rather than ship a made-up sequence.
Add titles, search terms, and a 'still stuck' fallback

Make each article findable and give the customer a graceful exit when the article doesn't cover their case. Findability and a real fallback are what turn articles into deflection.

you ask

For all 8 articles, give me a plain search-friendly title and 4 alternate phrasings a customer might type ('can't log in,' 'forgot password,' 'reset link not working'). Then write one short 'still stuck?' fallback block we can reuse at the bottom of every article, pointing to how to reach a human.

what you get back Search-friendly titles plus the real phrases customers actually type, and one reusable "still stuck?" block — so people find the article and have a clear way out when it's not enough.

make it your own

Source it from the data, not memory: run the Find what the queue is really about playbook first and write articles for the top clusters by volume, so the help center maps to real demand.
Bridge to canned replies: for questions a human still has to handle, point the "still stuck?" line at a macro from the Build a canned-response library you'll actually reuse playbook, so the handoff is warm and fast.
Keep it fresh on a schedule (Power Track): set a /help-audit custom command or a scheduled agent (see the Playbook's Capabilities tab) to re-check your top articles against last month's tickets and flag the stale ones. Custom commands and scheduled agents are the opt-in Power Track — on Desktop you run the same audit prompt by hand whenever you refresh the help center.

watch out for

Never let Claude invent a click-path — wherever it doesn't know your product's real steps it should leave a [confirm the steps] marker, because one wrong instruction in a help article generates the exact ticket it was meant to prevent.
Scrub names, emails, and account numbers from any ticket export before using it as source material — you want the question patterns, not the customers' personal details.
Claude drafts the articles; a human owns publishing them. Click through every numbered step in the real product before it goes live, and keep the 'still stuck?' exit honest so a confused reader always has a human to reach.

you'll end up with A starter set of short, friendly, search-findable help articles built from your real tickets — each answering the cause once, with a 'still stuck?' line so no one hits a dead end.

Questions people ask

Which questions should become help articles?: The high-volume ones with a clear self-serve answer. Rank candidates by how well an article could deflect the ticket — "reset password" ranks high, "my package is lost" ranks low because it needs a human. Not every frequent question should be an article.
How do I stop Claude inventing steps it doesn't actually know?: Tell it to leave a `[confirm the steps]` marker wherever it doesn't know your product's real flow, instead of guessing. One wrong instruction in a help article generates the exact ticket it was meant to prevent, so you fill those markers in from the real product.
Why build articles from tickets instead of what I think confuses people?: Because the trap is writing for confusions you assume exist. Sourcing from real tickets — or the top clusters from `Find what the queue is really about` — means the help center maps to actual demand and deflects the questions you genuinely get.
Do I need to do anything before publishing?: Click through every numbered step in the real product before it goes live, and keep the "still stuck?" exit honest so a confused reader always has a human to reach. Claude drafts the articles; a human owns publishing them.