How to write help-center articles an AI can actually answer from

Teams that are disappointed by AI support usually blame the model. Far more often the model is fine and the content is thin. An AI that answers from your own material can only be as good as that material — it cannot infer your returns window, your delivery cut-off, or what you do when a parcel is marked delivered and never arrived. If it is not written down somewhere, the honest response is a handoff, and a handoff is what you get.

Why your content sets the ceiling

Grounded AI support works in two steps: find the passages in your knowledge base most likely to contain the answer, then write a reply based on those passages and cite them. Both steps are entirely at the mercy of what you wrote. If no article contains the answer, retrieval returns the next-best thing, and the writing step is left choosing between guessing and handing off. A well-behaved system hands off — which is the correct outcome, and still shows up in your numbers as a conversation the AI did not resolve.

This is why two companies running the same product report resolution shares that are nowhere near each other. The difference is rarely configuration. It is that one of them documented its top twenty ticket topics and the other has a six-line FAQ written three years ago.

1. One question per article

The most common structural mistake is the omnibus article: "Shipping, returns and refunds", three thousand words, eleven headings. It is convenient to maintain and close to useless for retrieval. When a customer asks how long a refund takes, the system has to pull the right fragment out of an article that is mostly about something else, and all the surrounding text about shipping actively competes with the part you wanted.

• Split by the question a customer would type, not by the department that owns the answer. "How long does a refund take?" is an article. "Returns policy" is a category.
• If an article needs more than one heading to answer its own title, it is probably two articles.
• Title each article with the question itself, in the customer's phrasing. Titles carry a lot of weight in retrieval, and they are also what a person scanning search results reads.
• Cross-link the split articles so a customer who lands on the wrong one gets to the right one in a click.

2. Put the answer in the first two sentences

Support articles have a habit of opening with context: why the policy exists, what changed last year, who to contact if this does not apply to you. Move all of it down. The opening sentences are what gets retrieved, what gets quoted back to the customer, and what a person in a hurry actually reads.

A useful test: if you deleted everything after the second sentence, would the article still answer its own title? If not, rewrite the opening rather than adding more to the end.

3. Write the values out — do not point at a screenshot

Screenshots are helpful to a human and invisible to retrieval. An article that says "set the threshold as shown below" with an image underneath contains no threshold. The same goes for a table saved as an image, an embedded PDF, or a video walkthrough where the number is spoken aloud at 1:42.

• State numbers, deadlines and limits as text: 30 days, 22:00, €50, five working days, three delivery attempts.
• Write out the click path in words — Settings, then Billing, then Invoices — even when a screenshot shows the same route.
• Keep the screenshot. It is still the fastest way for a person to confirm they are in the right place. Just do not let it be the only place a fact exists.
• Transcribe the important part of any video. A caption file is content; a video player is not.

4. Cover the cases you would rather not put in writing

Most knowledge bases document the happy path thoroughly and stop where it gets uncomfortable. Those are exactly the conversations that reach a human, and they are the expensive ones. Every unwritten exception is a permanent tax on your queue.

1. The parcel is marked delivered and the customer did not receive it. What should they check first, how long do you wait before opening an investigation with the carrier, and what do you offer afterwards?
2. The item comes back used or damaged. What do you accept, what do you deduct, and how do you word it?
3. The customer is a few days outside the return window. Write down what your team actually does — if agents routinely make an exception up to a week, say so, or the AI will be stricter than your own staff.
4. The refund has not appeared. How long does the card issuer take on top of your own processing time, and what do you ask the customer to send you?
5. The discount code was not applied. Do you refund the difference afterwards, and under what conditions?

Writing these down has a second benefit that has nothing to do with AI: your agents stop answering them five different ways.

5. Use the words your customers use

Retrieval matches meaning rather than exact keywords, so the occasional synonym is not fatal. Writing consistently in internal vocabulary is. If your customers say "invoice" and your articles say "billing document", or they say "cancel my subscription" and you say "terminate the agreement", you are asking the retrieval step to bridge a gap on every single query.

6. Make retrieval's job easy

Long articles are normally split into chunks before they are indexed, and each chunk is retrieved on its own. A paragraph that only makes sense after the three paragraphs above it will therefore be retrieved without them.

• Make each section self-contained. Repeat the subject rather than starting a section with "it" or "this plan".
• Use headings that state the question the section answers, not one-word labels.
• Prefer short paragraphs and lists to dense blocks. A list survives chunking; a wall of text can be cut mid-argument.
• Put conditions before conclusions. "If your order has not shipped yet, you can cancel it in…" is safer than a cancellation instruction whose exception appears two paragraphs later.

7. Freshness is a support metric, not a content metric

A wrong article is worse than a missing one. Missing content produces a handoff. Wrong content produces a confident, cited answer that is wrong — and the citation makes it more convincing, not less. Every price change, policy change and integration change needs a pass over the articles that mention it.

• Give every article a named owner and a review date. Unowned articles rot quietly.
• When something changes, search the knowledge base for the old value before you announce the new one.
• Retire aggressively. Two articles that disagree are worse than one that is slightly out of date, because you cannot predict which one gets retrieved.
• Control what is indexed. In CustomerEagle each help-center article carries a "Searchable by AI" setting, so an internal or seasonal article can exist for people without being used as an answer source.

A template you can copy

Almost every article in a knowledge base that performs well looks roughly like this.

1. Title: the customer's question, in their words where possible.
2. First paragraph: the answer, with the actual values in it.
3. Conditions: when this does not apply, written as "if… then…".
4. Steps: numbered, in words, with screenshots as support rather than as substance.
5. Exceptions: the awkward cases, and what you actually do about them.
6. Next step: where to go if this did not solve it, including how to reach a person.
7. Footer: owner and last-reviewed date — for your team, not for the customer.

Test it with real tickets before you trust it

Content quality is measurable, and the measurement takes an afternoon.

1. Take fifty real tickets from last month, spread across topics — not the fifty easiest.
2. Ask each question the way the customer phrased it. The interactive demo is a quick way to try phrasings without touching your live widget.
3. Score every answer as correct, incomplete or wrong. Ignore tone entirely at this stage; tone is a settings problem, coverage is not.
4. For each incomplete or wrong answer, write down which article should have answered it. That list is your content backlog, already in priority order.
5. Re-run the same fifty once you have written them. The delta is what the content work bought you.

Then let the gaps find you

Manual testing gets you the first draft of the backlog. After that, the system knows more about what is missing than you do: every conversation where it had no confident answer is a documented gap. CustomerEagle logs those, groups them, and can draft an article from the conversation for a person to edit and publish. The drafting is automated; the publishing deliberately is not, because an unreviewed article immediately becomes a cited answer.

That loop is the whole job. Write the twenty articles that cover most of your volume, ship, read what fails, write the next five. Teams whose resolution share climbs month after month are not the ones with cleverer prompts — they are the ones who treat the knowledge base as a product. What that share is worth in money depends on your volume and plan; the per-agent allowances are on the pricing page.