Every disappointing AI chatbot has the same root cause, and it is never the model. It is that somebody pointed the bot at a website, pressed go, and expected it to know things the website never said. The model is fine. The data underneath it is thin.
"Training" an AI chatbot in 2026 does not mean fine-tuning anything. It means assembling a small, clean body of source material and letting the bot retrieve from it. That is a writing and curation job, not a machine learning job, and it takes about ninety minutes to do properly. Here is how.
What "training" actually means
When a visitor asks a question, the system does three things: it searches your source material for the passages most relevant to the question, it hands those passages to the language model along with the question, and the model writes an answer grounded in what it was handed. This is retrieval-augmented generation, and the practical consequence is simple:
If the answer is not in your sources, the bot cannot give it. A well-configured bot will say it does not know and offer a human. A badly configured one will improvise. Your job is to make the first outcome rare by writing the answers down.
The second consequence matters just as much: retrieval is only as good as the phrasing overlap between the visitor's question and your text. Your internal wording ("bespoke fabrication service") and your customer's wording ("do you make custom parts") need to meet somewhere. Writing in customer language is not a style preference here, it is a retrieval mechanism.
The source types, and what each is for
| Source type | Best for | Watch out for |
|---|---|---|
| Q&A pairs | The 20 to 40 questions you answer every week. The highest-precision source there is. | Nothing. Start here. Most people start with a website crawl and wonder why answers are vague. |
| Custom text | Prices, policies, service area, opening hours, the things your website says badly or not at all. | Free plan caps a text dataset at 50,000 characters; paid plans are unlimited. |
| Website crawl | Breadth. Catching the pages you forgot you wrote. | Navigation, cookie banners and footers add noise. Crawl your content pages, not your whole domain, when you can. |
| PDF and document upload | Price lists, brochures, manuals, spec sheets, menus that already exist as documents. | A PDF that is a scan or a designed poster has no extractable text. Paste the text instead. Essential and above. |
| Structured data (spreadsheet upload) | Anything tabular: rates by region, room types, course dates, service lists. Upload the file and map the columns. | This is a file upload, not a live connection. Re-upload when the data changes. Keep one fact per row and use plain column headers. |
| Online store catalogue | WooCommerce products, with real names, prices and descriptions rather than a scrape of your shop pages. | Essential and above. |
| Notion | Teams whose internal handbook or knowledge base already lives in Notion. | Only expose the pages you'd be happy for a customer to read. Essential and above. |
Do it in this order
The order matters more than the volume. Almost everyone does this backwards.
- Write 20 Q&A pairs first, from memory. Not from your website. Sit down and write out the questions you personally answer most often, with the answers you actually give. This single step does more for answer quality than any amount of crawling, because it is the only source written in customer language.
- Add a custom-text dataset for the facts that live in your head. Prices and what changes them. Service area. Hours including exceptions. What you don't do. Turnaround times. Payment terms. Nine businesses in ten have never written these down anywhere public, which is exactly why their chatbot is vague.
- Then crawl your website. Now it is filling gaps rather than carrying the whole load. The free plan crawls up to 100 pages per website dataset, Essential 500, Pro 2,000.
- Then add documents. Price lists, brochures, manuals, spreadsheets, whatever exists as a file already.
- Then connect your live sources if you have them: a WooCommerce product catalogue, or a Notion workspace.
How to write source content the retrieval step can actually use
Six rules that make a measurable difference:
- One fact per chunk. A 4,000-word "About us" page that mentions your delivery policy in paragraph nine will lose to a 40-word note that is only about the delivery policy. Split by topic, not by document.
- Repeat the subject in the answer. Write "Standard delivery takes three working days" rather than "It takes three working days". Retrieval matches on words; pronouns match on nothing.
- Use your customers' vocabulary, including the wrong words. If people call it a "quote" and you call it an "estimate", put both in. If they misspell your product, put the misspelling in a Q&A pair.
- Write the negative facts explicitly. "We do not offer same-day delivery", "we do not take card payments under £5", "we are closed on Mondays". A bot that cannot find a "no" will hedge, and hedging reads as incompetence.
- Date anything seasonal. "2026 summer opening hours (June to September)" ages honestly. "Our new opening hours" does not.
- Keep answers to three sentences. Long source paragraphs produce long, waffly replies. Short source text produces crisp replies. This is the fastest tone fix available.
What not to put in
Everything you upload is content a stranger can extract by asking politely. Treat every source as public:
- No internal pricing floors, margins, or "what we'll accept if they push back"
- No staff personal details, rotas, or internal escalation contacts
- No customer names, case histories, or anything from a CRM export
- No unpublished plans, contracts, or supplier terms
- No credentials, API keys or internal URLs, even in a footnote of a document you upload
The test is simple: would you be comfortable seeing this sentence quoted in a screenshot? If not, it does not belong in a dataset.
Testing, the step everyone skips
Do not judge your bot by asking it questions you know it can answer. Do the opposite:
- Ask your ten hardest real questions, in the sloppy way customers actually type them, typos included.
- Ask three things you deliberately did not document. The bot should decline cleanly and offer a human. If it invents an answer, your instructions need tightening, not your data.
- Ask a price question three different ways. "How much", "what's the cost", "do you have a price list". All three should land on the same answer. If one misses, add that phrasing.
- Ask in another language. Replies come back in the visitor's language across roughly 100 languages, from your English source text, so this should just work; confirm it does for the languages your customers use.
- Test on a phone. Answers that look concise on a laptop can be four screens on mobile.
Keeping it accurate
A chatbot trained once and never touched degrades in a specific way: it keeps answering confidently while the facts move underneath it. The maintenance loop is small but it must exist.
- Read the transcripts weekly for the first month, then monthly. The conversations view is where the gaps show up. Every "I don't have that information" is a Q&A pair waiting to be written.
- Re-crawl after any real site change. On Pro, automatic dataset refresh does this on a schedule so a new pricing page flows through without you remembering.
- Keep volatile facts in one small dataset. Prices, hours, current offers. When they change you edit one short document instead of hunting through five.
- Delete stale sources rather than adding corrections. Two documents that contradict each other produce a bot that contradicts itself. Removing the old one is the fix.
How much data do you actually need?
Less than you think. A local service business is usually excellent at 30 Q&A pairs plus two pages of custom text. An e-commerce store needs its catalogue plus shipping, returns and sizing. A B2B company needs its product pages, pricing logic and a good "who is this for" document.
Dataset allowances: Starter includes 2 datasets, Essential 5, Pro 15, Enterprise effectively unlimited. Almost nobody hits those ceilings, because the right answer is a few well-curated sources rather than forty half-relevant ones. If you find yourself needing fifteen datasets, the usual cause is one dataset per web page; group by topic instead.