The only test that matters
A help article succeeds when a frustrated person, nine words into skimming it, finds their answer and leaves. It fails when it is complete, accurate, well-organized — and unread. Write for the skimmer, not the archivist.
Title with the customer's words
Customers search "refund" — not "billing adjustment policy." Pull titles from real transcripts and tickets: the exact phrasing people used when they asked. If your product renames a concept ("Workspaces") but customers say "accounts," the article title needs their word, with yours in the body.
Answer in the first sentence
Context, caveats, and background go AFTER the answer, not before it. Compare: "To reset your password, click Forgot Password on the sign-in page" versus three paragraphs on account security philosophy. The skimmer needs the verb and the button name immediately; the one reader in ten who needs the caveats will keep reading.
One task per article
"Managing your account" is a junk drawer; "Change your billing email" is an article. Small articles rank better in search, match one question each in your widget's suggestions, and — critically — make better AI training material: an assistant trained on single-task articles gives single-task answers instead of summaries of junk drawers.
Structure for skimming
- Numbered steps for anything procedural — never prose paragraphs describing clicks.
- Bold the UI names ("click Deployment") so eyes can jump from step to step.
- State the precondition first when there is one: "You need admin access for this."
- End with the next question. If readers of this article usually ask a follow-up, link it at the bottom.
Screenshots that age well
Screenshots go stale the day the UI changes, and stale screenshots are worse than none — they tell the reader the whole article might be wrong. Use them only where words genuinely fail, crop tightly to the control being discussed, and skip decorating every step with a full-window capture you will never maintain.
The monthly transcript audit
Once a month, read the chats and tickets about topics you have already documented. Each one is a verdict: the article was unfindable (fix the title), unclear (fix the first sentence), or incomplete (fix the body). This loop — real questions correcting written answers — is what separates a help center that deflects from a help center that exists. It is also exactly what improves an AI assistant trained on those articles: the bot is a mirror held up to your documentation.
Where this lives in MyLiveChat
The built-in knowledge base serves these articles three ways at once: as your public help center, as suggestions inside the chat widget, and as the AI assistant's approved training source. Write the answer once; it deflects in all three places.
Deciding what not to write
A help centre that tries to document everything ends up with hundreds of thin pages, none maintained,
and search results that compete with each other. Coverage is not the goal; answering the questions people
actually ask is.
Let the transcripts choose. Write the article when a question has been asked enough times that you can
quote several real phrasings of it, and not before. Questions asked once are usually better answered in
the conversation, and writing an article for each one produces a corpus nobody can keep true.
Be equally willing to delete. A page that gets no traffic and answers no question in your transcripts is
not neutral — it dilutes search, competes with the page you want found, and gives an AI assistant
another source to be confused by. Retiring pages is part of maintaining a help centre.
Keeping articles true as the product moves
Help content does not fail loudly. It drifts, slightly wrong at first, until a customer follows
instructions that no longer match what they see and trusts nothing you wrote afterwards.
The cheapest defence is a named owner and a review date on every article, and a rule that any change to a
screen or a flow includes checking which articles mention it. That rule is easier to keep if the article
describes what the customer is trying to achieve rather than narrating a specific interface, because goals
change far more slowly than layouts.
Where you must describe an interface, describe it in words rather than only in screenshots. Words can be
corrected in seconds by anyone; screenshots need a person with the right access and the right account state,
which is why they are almost always the most out-of-date thing on the page.
What to measure
The number that matters is whether the question stopped arriving. Track contacts about the topic before
and after publication rather than page views — a page can be read a thousand times and still fail if
readers keep opening a chat afterwards.
Watch searches inside your help centre that return nothing useful. That list is the most direct
specification for what to write next that you will ever get, and it comes from people already trying to
help themselves.
Keep an eye on the articles agents send most often. Those are your highest-value pages, they deserve the
most maintenance attention, and if an agent is routinely pasting an explanation instead of a link, the
article they need does not exist yet.
When you are moving existing documentation in rather than writing fresh, splitting one markdown file into help articles explains how a single paste becomes many articles and which of them get quietly skipped.