Preparing documents for AI answers

Why the same documents answer well or badly

An AI assistant does not read your documents the way a person does, cover to cover. It splits them into passages, and for each question it retrieves a handful of passages and answers from those alone. Two things therefore matter: whether the passage that holds the answer can be found by the words people ask with, and whether that passage makes sense on its own, without the three pages before it.

Every habit below serves one or both of those. None of them needs special tools, and none is AI-specific: a document that is easy for an assistant to answer from is easy for a hurried person to read.

1. One topic per section, with a heading that names it

Most systems split documents along their headings. A section headed "Annual leave - how many days and how to carry them over" becomes a passage that is obviously about annual leave. A 12-page policy with no headings becomes arbitrary slices that each mention three things.

Use real heading styles (Heading 1, Heading 2 in Word; # in Markdown), not bold text in a larger font. Name the topic in the heading rather than using "General", "Other" or "Section 4.2".

2. Put the answer first

Write the rule, the number or the yes/no in the first sentence under the heading, then the detail and the exceptions. "Employees get 21 days of annual leave a year, of which up to 10 can be carried into the next year." is a passage that answers on its own. Three paragraphs of background before the number is one that may be cut off before the number arrives.

3. Use the words people ask with

Your documents say "reversal"; customers ask about "refunds". Your policy says "privilege leave"; staff ask about "holidays" or "PL". Meaning-based search bridges some of that gap, but not reliably for internal jargon, abbreviations or product names.

Mention the common names once, near the top: "Privilege leave (PL, sometimes called earned or annual leave)". Look at real ticket subjects and chat questions to learn which words those are.

4. Keep exactly one current version

The single most common cause of a confidently wrong answer is two versions of the same document: the 2024 travel policy and the 2025 one, both in the shared drive, both retrieved, one quoted. Dates in file names do not help; the assistant sees two plausible passages.

Delete or move the old version out of every source the assistant reads. If you must keep history, keep it in a folder or space that is not connected.

5. Say who and what each rule applies to, in the text

"Refunds are available within 30 days" - on every plan? In every country? For annual and monthly billing? A person browsing knows they are in the India pricing section; a retrieved passage does not carry the page around it.

Repeat the scope in the sentence or the heading: "Refunds on monthly plans (India)". It feels redundant on the page and it is exactly what makes a passage safe to quote on its own.

6. Keep tables simple and labelled

Simple tables with a header row and units in the headings ("Limit (GB)", "Price per month (INR)") survive extraction well. Merged cells, tables split across pages, and numbers whose meaning depends on colour do not. When a table is the answer to a common question, add one sentence above it that states the most-asked row in words.

7. Make sure there is text to read

A scanned PDF is a picture of text. If you cannot select the words in your PDF viewer, an assistant that reads text has nothing to work with. The same goes for slides and screenshots where the meaning is in the image: a diagram of an approval flow says nothing to a text index.

Export documents to PDF from the word processor rather than scanning a printout, and describe important diagrams and screenshots in a sentence or two of text.

8. Keep internal and public content apart

An assistant answers from whatever it is given. If agent-only troubleshooting notes, pricing exceptions or an internal escalation list sit in the same collection as your public help centre, a website visitor can be answered from them.

Keep separate collections for separate audiences - in SupaCortex, separate projects - and connect each audience only to its own. Check private or draft articles in particular: if a help-centre feed can read them, the public assistant can quote them.

9. Mark what is official

Not every source is equally authoritative. The published policy should outrank a wiki page someone wrote in 2022, and both should outrank an old support ticket. If your tool supports it, set that explicitly - SupaCortex has a trust tier on every document, used in ranking - and put informal material in the lowest tier rather than leaving it out entirely.

10. Write down what only lives in people's heads

The answers agents type from memory, the workaround everyone knows, the exception the finance team always makes - none of these are in a document, so no assistant can give them.

Two good sources for the gaps: the questions your assistant could not answer, and your resolved support tickets. SupaCortex can mine resolved conversations from Zendesk, osTicket and UnifyDesk into suggested questions and answers, with personal details redacted; a person reviews and approves each one before it becomes searchable.

Then test with real questions

Do not try to perfect everything before you start. Load what you have, then ask it 30 to 50 questions taken from real tickets, emails and chats - in the askers' words, typos included. For each wrong or missing answer, look at which passages it cited or found, and fix the document, not the question.

Repeat weekly for the first month and monthly after that, using the list of questions the assistant could not answer. The fixes are usually one of the ten habits above.

• Wrong answer from an old document: habit 4.
• Right document, wrong section: habits 1 and 2.
• Answer exists but was not found: habit 3.
• Correct rule applied to the wrong people: habit 5.
• No answer anywhere: habit 10.