How to write help articles an AI can actually answer from

The single highest-leverage change you can make to a help article in 2026 is to put the answer in the first sentence and state every number and policy explicitly. An AI reading your help center to answer customers does not skim, infer, or "get the gist" — it retrieves a chunk of text and works with exactly what that chunk says. Write for that reader and your articles get better for humans too. Write against it and your AI will confidently make things up.

We built the AI in Iris to answer only from what a team has published, and we have watched the same lesson land over and over: a support AI is only as good as the worst article it is allowed to read. Here is how to write articles it can be trusted with.

Why vague articles make an AI hallucinate

An AI does not fail loudly on a vague article. It fails plausibly. If your refund article says "we're generally pretty flexible about returns," the model has no policy to state — so, being built to be helpful, it fills the gap with what companies "usually" do and tells a customer "you have 30 days," a number that appears nowhere in your business. It sounds right. It is invented. And it is now a promise you have to honor or deny to a customer's face.

An AI cannot quote a number you never wrote down. If the policy isn't in the article, the model will supply one — and it won't be yours. Vagueness is not a small quality issue; it is the direct cause of the confidently-wrong answers that make people distrust support bots. The fix is not a smarter model. The fix is a specific article. A well-grounded AI, given a clear policy, will state it exactly and, given no policy, should stay silent and route to a human — but it can only be as precise as your writing lets it be.

One question per article

The most common structural mistake is the mega-article: "Everything about billing," covering plans, upgrades, invoices, refunds, and failed payments in one long page. A human tolerates it by scrolling. Retrieval hates it, because when a customer asks about a failed payment, the system pulls a chunk that is three-quarters about other billing topics, and the actual answer is diluted or missed.

Split by question. "How do I change my plan," "when am I charged," "why did my payment fail," "how do I get an invoice" — four articles, each answering exactly one thing. One article, one question, one answer. If a title needs an "and," it needs to be two articles. A tight, single-purpose article retrieves cleanly every time, and it is easier for a human to land on from search too.

The answer goes in the first sentence

Lead with the answer, then explain. Not context, not background, not "at Acme, we believe support should be simple" — the answer, in sentence one. Retrieval favors the top of a chunk, humans read the first line and leave, and an AI can quote a lead sentence directly with confidence.

Compare. Weak: "Refunds are an important part of a good customer experience, and we've thought carefully about our policy over the years." Strong: "You can request a full refund within 7 days of purchase, for any reason." The second one is a fact the AI can serve verbatim. The first is throat-clearing that answers nothing. Roughly speaking, if your first sentence does not contain the answer, an AI cannot rely on your first sentence — and neither can a hurried human.

State numbers and policies, never imply them

Every number a customer might ask about must appear as a literal number. Not "a few days" but "3 to 5 business days." Not "a small fee" but "a flat $2 COD fee." Not "shortly after we receive it" but "within 2 business days of the returned item arriving at our warehouse."

Implied policy is invisible to retrieval. If your return window is "communicated at checkout" but written nowhere in the help center, the AI cannot see checkout and will either stay silent (best case) or guess (worst case). Write the number down in the article, even if it lives somewhere else too. The AI can only read what is on the page. This feels redundant when you know the policy by heart. Write it anyway — you are not the reader who needs it.

Never write "see above" or "as mentioned below"

Cross-references assume the reader has the whole page in view. Retrieval does not — it may hand the AI a single paragraph, ripped out of its surroundings, with no "above" and no "below." A chunk that says "follow the steps mentioned above" is useless on its own; the steps are in a different chunk that may not have come along.

Make every paragraph self-sufficient. Repeat the key fact instead of pointing at it. If two articles need the same policy, state it in both. Redundancy is a virtue in a document meant to be read in fragments. The instinct to keep things DRY belongs in code, not in help content that will be sliced into pieces before an AI ever sees it.

Tables beat prose for anything structured

Plans, pricing, tiers, comparisons, regional differences — anything with a grid shape should be a table, not a paragraph. Prose forces the reader (human or AI) to reconstruct a structure you already knew; a table hands it over intact. "Growth includes 3 seats and 1,000 credits, while Scale includes 10 seats and 5,000 credits, and the Free plan..." is a sentence nobody parses cleanly. The same facts as a three-row table are unambiguous, and the AI can read a specific cell instead of untangling a run-on.

Roughly: if you are using the words "whereas" or "while" to compare two things, you wanted a table. Reserve prose for the things prose is good at — the why, the caveat, the exception — and let structure carry the structured facts.

A before/after rewrite

Before: "Cancellations & Your Account — We understand that sometimes things change! At Acme we try to be as accommodating as possible when it comes to cancellations. Generally, if you reach out to us, we'll do our best to help you out, and depending on your situation there may be some options available. Your data is also something we take seriously."

That paragraph answers nothing. An AI reading it can state no window, no method, no data outcome — so it either says nothing useful or invents specifics. Now the rewrite:

"How do I cancel my subscription? — You can cancel anytime from Settings, Billing, Cancel plan. Your plan stays active until the end of the current billing period; you are not charged again after that. Your data is kept for 30 days after cancellation, then permanently deleted. To export your data first, use Settings, Export before you cancel."

Every sentence is a fact the AI can serve verbatim: the method, the timing, the data window, the export path. Same topic, a fraction of the fluff, and now it is genuinely answerable. The rewrite did not add information. It stopped hiding the information you already had.

The 10-point checklist

Run every article past this before you publish:

1. Does the title state one specific question, the way a customer would ask it?
2. Is the complete answer in the first sentence?
3. Is there exactly one question answered here (no hidden "and")?
4. Is every relevant number written as a literal number?
5. Is every policy stated outright, not implied or "handled elsewhere"?
6. Are there zero "see above / as mentioned below" references?
7. Would a single paragraph, read alone, still make sense?
8. Is anything grid-shaped (plans, tiers, regions) in a table?
9. Is it free of throat-clearing, brand mission, and filler?
10. Could someone act on it without needing a second article?

Ten yeses and your article is one an AI can stand behind — and, not by coincidence, one a human finds faster and trusts more.

None of this is extra work so much as earlier work: the clarity you would eventually be forced into by an angry customer, done up front. In Iris, the moment you publish an article it becomes part of what the AI is allowed to say, and when it cannot find a clear answer it stays silent and hands the conversation to a human rather than guessing — so tightening your articles is the most direct way to make your automated support both broader and safer at once. Write for the machine that reads in fragments, and you will have written better for the person who was always reading in a hurry.