All articles
Guide

How to write a knowledge base your AI can actually use

A long document splitting into clean single-topic sections

The short answer

A knowledge base an AI can use is not a bigger FAQ. It is a set of short, single-topic documents with clear headings, exact numbers and no contradictions - written so retrieval can find one passage that fully answers one question. Structure beats volume every time.

A knowledge base an AI can use is not a bigger FAQ. It is a set of short, single-topic documents with clear headings, exact numbers and no contradictions - written so retrieval can find one passage that fully answers one question. Structure beats volume every time.

A grounded AI is only as good as the documents it reads. The good news: you don't need to write a wiki. You need a handful of well-structured documents that answer the questions your customers actually ask. Here's how to write them so retrieval finds the right passage every time.

Start with the five documents

Day one, upload these: your shipping and delivery policy (with cities and timelines), your return and refund policy (with the exact window and conditions), your price list or catalogue, a plain-language FAQ of your fifteen most-asked questions, and an "about us" page with hours, location, and contact details. In our data, these five cover more than 80% of all customer queries.

Write for retrieval: one topic, one place

When a customer asks a question, the system retrieves the few passages most similar to it - so structure matters. Keep one topic per section, under a clear heading that matches how customers ask ("Do you deliver to my city?" beats "Logistics overview"). State facts explicitly and completely in each section rather than referring to "the above" - a retrieved chunk should make sense on its own.

Avoid contradictions across documents. If your return window appears in three files, it will eventually disagree in one of them, and the bot can only be as consistent as you are. Keep a single source of truth per fact.

Write each section as if it's the only thing the AI will read - because at answer time, it is.

Numbers, tables, and edge cases

Prices, timelines, and sizes should be written as text, not buried in screenshots - AI reads text, not pixels. Simple tables work well; complex merged-cell spreadsheets don't. And write down the edge cases you handle by instinct: COD limits, festival delays, damaged-item photos. If it's only in your head, the bot escalates what it could have answered.

The FAQ page you already have

Most businesses start from zero when the best first document already exists: the FAQ page on your own site - which, left on its own, is not reducing your ticket count anyway. Paste it in as text and you have covered your most-asked questions in two minutes. But read it once before you do, because FAQ pages accumulate marketing sediment - answers that say we pride ourselves on service instead of stating the return window.

Strip every answer down to its facts and split multi-part answers into one question, one answer. The version of your FAQ that persuades a browsing human and the version that answers a retrieval query are different documents, and the second one is shorter. Keep both - one on your site, one in the knowledge base - and let each do its own job.

How many documents is too many?

Fewer than you think. The Free plan takes ten documents, Starter thirty, Growth fifty - and those ceilings are a feature, not a squeeze. Every document you add is another place a fact can live, which means another place it can go stale and another chance for two files to disagree. A knowledge base with 12 tight documents beats one with 60 overlapping ones, every time.

The discipline that works: one document per policy area, named for what it answers. shipping-policy.pdf, returns.pdf, size-chart.pdf, fees-2026.pdf. When a fact changes, there is exactly one file to edit, and the citation on every answer tells you which one.

Keep it alive: the monthly pass

A grounded bot has one failure mode you own completely: it quotes stale documents accurately. If your Diwali price sheet is still uploaded in January, the bot will cite it - confidently, correctly, and wrong. Grounding guarantees provenance, never freshness.

So put twenty minutes a month in the calendar - it is the habit a single knowledge base makes sustainable, because there is only one folder to review. Reread the two documents with numbers in them - prices and timelines drift fastest. Delete anything about an offer that ended. And scan the knowledge-gap list, because the questions that came back empty are the exact list of what to write next.

A worked example: one paragraph, rewritten

Here is a passage from a real returns page, lightly disguised: "We want you to love your purchase! If for any reason you aren't satisfied, reach out to our team and we'll sort something out, subject to our policies." Warm, and useless. There is no window, no condition, no process - nothing a retrieval system can quote, because nothing is actually stated.

The rewrite: "Returns: items may be returned within 7 days of delivery, unused, with the original invoice. Refunds reach your original payment method in 5-7 working days. Sale items are exchange-only." Three sentences, three facts, one topic under one heading. A customer asking "can I return this?" at midnight now gets your policy, not a paraphrase of your vibes.

The test for every paragraph you upload: could a stranger answer a customer question by quoting it verbatim? If not, the bot can't either - it only answers from what you give it, which is the point.

Traits that help retrieval, and traits that break it

Documents get split into passages before they are searched - chunking, in the jargon. That mechanical step is why some writing habits quietly sabotage answers.

Document traitWhat the customer gets
One topic per headingThe right passage surfaces on its own
Exact figures - 7 days, Rs 999, 5pmThe number, quoted verbatim with the source
Everything in one 40-page PDFAnswers buried mid-chunk, retrieval hit-and-miss
Two documents that disagreeEither version, unpredictably - fix the documents
Vague wording - usually, promptly, soonA vague answer, faithfully reproduced

The pre-upload checklist

Five checks before you hit upload. They take ten minutes and save a month of confused answers.

  1. Does every document cover one subject, named in its title and headings?
  2. Is every number current - prices, windows, timings, charges?
  3. Do any two documents state the same policy differently? Pick one and delete the other.
  4. Can the text be selected with a cursor? A photograph of text is not text.
  5. Have you included the five basics - shipping, returns, pricing, product details, and your most-asked FAQ?

One more habit worth stealing from teams whose bots answer well: date your documents in the filename. fees-aug-2026.pdf tells future-you at a glance whether the numbers inside are current, and makes the monthly review a filename scan instead of a reading exercise.

The documentation covers upload formats, and the e-commerce walkthrough lists the exact five documents for an online store. If you want to see how your own text performs before signing up, the homepage demo retrieves from whatever you paste into it - the free plan takes ten documents when you're ready.

Let the gaps teach you

You won't get it perfect on day one - and you don't need to; expecting day-one perfection is itself a common rollout mistake. Every time the bot can't answer, that's logged as a knowledge gap. Check the list weekly, add the missing paragraph, and the bot learns instantly. Within a month, your knowledge base converges on what your customers actually ask, not what you guessed they would.

Frequently asked questions

Which documents should I upload first?

Five: your shipping and delivery policy with cities and timelines, your return and refund policy with the exact window and conditions, your price list or catalogue, a plain-language FAQ covering your fifteen most-asked questions, and an about page with hours, location and contact details.

Is more content always better?

No. Every extra document is another place a fact can live and go stale. A knowledge base with twelve tight documents beats one with sixty overlapping ones - one document per policy area, named for what it answers.

Why does the same fact in two files cause problems?

Retrieval can surface either one, so the customer gets whichever version it reached first - cited, which makes a wrong answer look authoritative. Keep a single source of truth per fact and delete the duplicate.

Can I upload screenshots or scanned PDFs?

Prices, timelines and sizes should be selectable text, not pixels. If the text cannot be highlighted with a cursor, retrieval cannot read it.

Get started for free

What are you waiting for?

Stop answering the same 15 questions. Your customers get accurate answers 24/7, and you get your evenings back. Live in 5 minutes - no developer, no sales call.

Let's go! →

Free plan to start · No credit card · Cancel anytime