A clinic in Antwerp trained a chatbot in twenty minutes. It quoted the wrong price. The fix was not the platform — it was the data. A founder-written guide to RAG, sources, and the five mistakes that wreck launch month.
A clinic in Antwerp tried to train a chatbot on their website in February. They pasted the homepage URL into Chatbase, hit train, and tested it twenty minutes later. The bot confidently told a prospective patient that their lip filler cost €450. The current price on the website is €350. Their old website, which they redirected six months ago, had the €450 price. The crawler found both. The bot picked whichever it ranked first.
This is the part of "train an AI chatbot on your own data" that the platform marketing pages do not show. The technology works. The data work is where teams fail.
This article is the practical version. What the training actually does, what data to give it, how to spot when it is going to hallucinate, and the specific mistakes that ruin the first month after launch.
What "training" means in 2026
Training a chatbot on your data does not mean what fine-tuning a model means. Nobody is updating model weights on your help center. That would be wasteful and slow.
What happens instead is this:
The platform reads your content — website pages, PDFs, FAQs, product catalog. It chops the content into chunks of a few hundred tokens each. It turns each chunk into a vector — a long list of numbers that captures meaning. It stores the vectors in a database. When a user asks a question, the platform turns the question into a vector, finds the chunks with the closest vectors, and sends those chunks plus the question to an LLM. The LLM writes the answer using the retrieved chunks.
This is called RAG — retrieval-augmented generation. Every major platform that claims to "train on your data" runs some version of it. Chatbase, Intercom Fin, SiteGPT, Botpress, ours. The differences are at the edges: how aggressively they re-crawl, how they rank retrieval, what guardrails they apply when retrieval fails, whether they let the LLM answer outside the retrieved context.
The implication: your bot is only as accurate as the chunks in its database. The work is not in the training. The work is in the data.
What data to give it
In practice, the best results come from a narrow, current corpus rather than a broad, stale one.
Most teams over-supply. They upload the marketing site, the help center, every blog post, three product datasheets, the privacy policy, the cookie policy. The retrieval ranking then has to discriminate between a customer asking about pricing and a 2022 blog post celebrating their Series A. It often picks wrong.
The data sources that consistently improve accuracy:
- The help center. Articles written for the question. Tagged. Up to date.
- The FAQ page. Q&A pairs are dense; the bot retrieves cleanly from them.
- Current pricing pages and product specs. Specifically the current ones. Delete or noindex old pricing pages first.
- Past human support transcripts. Real questions in real customer language are gold. Most teams forget this corpus exists.
The data sources that often hurt:
- The marketing site. Written for SEO and brand, not for direct answers. Often contradicts the help center.
- Old blog posts. Stale information that ranks confidently in retrieval and lies.
- Internal docs. Often phrased in ways customers do not phrase questions. Worse, may leak internal-only language.
A useful rule: if you would not show a particular page to a confused customer who emailed support, do not let the bot retrieve from it either.
The five-step process that actually works
Step one — audit before training. Make a list of every URL and document you intend the bot to know. Mark each with: source, last updated date, content owner, and freshness. This step alone resolves 80% of the accuracy problems teams blame on the platform later. The Antwerp clinic was losing to old data they had forgotten was indexed.
Step two — pick a platform and connect sources. For most businesses, the right platform is one that ingests a website URL, accepts file uploads, and offers a no-code interface. Chatbase is the popular benchmark. SimplyBoost, ours, is functionally equivalent on the training step — you paste your URL, we crawl. The platform you pick matters less than the data you feed it.
Step three — configure the persona and guardrails. This is the step teams skip and regret. Set the tone — professional, friendly, the way your team actually talks. Set the out-of-scope behaviour — what should happen when someone asks something you do not want the bot to answer. The default in most platforms is "the bot tries to answer anyway", which is how hallucinations leak out. Change it to "decline politely and escalate".
The single most important setting is "answer only from retrieved context". Every major platform has this. Most teams leave it off because the bot then declines more questions. The trade-off is hallucination versus refusal. Refusal is the safer default for customer-facing deployments.
Step four — test against real queries before launch. Run 30 to 50 questions that real customers actually ask. Pull them from your support inbox, not from your imagination. Log the ones the bot gets wrong. Most of the wrong answers will trace back to two causes: a missing data source, or a contradiction between two sources. Fix the data, retrain, test again. The first iteration is usually disappointing. The fourth is usually good.
Step five — launch on a low-stakes surface first. Put the bot on a help article, not the homepage. Watch the first 100 real conversations. Look at where users escalated, where they did not get the answer they wanted, where they rephrased the same question three times. That is the next batch of data work. Plan for at least four weeks of weekly iteration before the bot stops surprising you.
The mistakes that wreck the first month
In rough order of how often they happen, what we have watched teams trip on:
The first is stale data. The bot was trained in January, the prices changed in March, nobody re-indexed. The bot quotes January's prices in April. The fix is automatic re-crawls; most platforms support them; most teams forget to enable them.
The second is contradictory sources. The marketing site says one thing, the help center says another, the bot picks one at random. The fix is editorial: pick which source is canonical for each topic, and either delete or de-index the others.
The third is no escalation rule. The bot tries to answer everything, including questions it should hand to a human — refunds, account-level changes, anything with money involved. Real customers find this frustrating and end up confused. The fix is to define a small list of escalation triggers (the word "refund", the word "lawyer", a confidence score below a threshold) and route to a human when they hit.
The fourth is the "looks fine in testing" problem. The bot performs well on the questions the team asks because the team unconsciously asks them in well-formed sentences. Real customers ask in fragments, in their second language, with typos. The fix is testing against actual past support transcripts, not against polite internal phrasing.
The fifth is over-prompting. Teams try to fix accuracy by stuffing the persona prompt with rules — "always say X, never say Y, if the customer mentions Z then do W". After about ten rules the LLM starts losing track. The fix is to handle policy in data and guardrails, not in prompt. If "do not quote prices over chat" is the rule, take pricing out of the indexed corpus rather than telling the bot in the prompt not to mention prices.
What this looks like as a real product
The chatbot itself is the visible piece. The data layer behind it is the work. The teams that produce accurate, useful bots treat the data layer the way an editor treats a content library: deliberate, curated, current, with someone responsible for it.
This is also why "train on your data" platforms diverge so much in accuracy despite using the same underlying technology. The ones that ship with sensible defaults — answer-from-context on, escalation rules pre-configured, contradiction warnings during indexing — produce better results out of the box. The ones that leave it up to the user produce wildly variable results depending on how careful the user is.
A practical recommendation for any team starting now: do the audit before you pick the platform. If you cannot list the URLs you are about to train on and confirm they are all current, the platform choice does not matter.
Frequently asked questions
Can I train a chatbot on my website for free?
Yes. SimplyBoost's free tier crawls a website and trains the AI agent with no credit card required. Chatbase has a free tier with capped messages per month. SiteGPT has a free trial. The "free" tier is fine for proof of concept; you will outgrow it once volume is real.
How much data do you actually need?
Less than people think. A 20-page website plus a 30-question FAQ is enough for a useful bot. Adding more documents helps with edge cases but the marginal accuracy gain drops quickly after the first 50 sources. Past human support transcripts are the highest-density training data; if you have them, use them.
How do I stop the bot from hallucinating?
Turn on "answer only from retrieved context" — every major platform has this setting under different names. Configure a confidence threshold for escalation. Remove stale and contradictory sources. The remaining hallucination rate after these three changes is usually low enough for production.
How often should I retrain?
Set up automatic re-crawls — weekly is reasonable for most businesses, daily if your pricing or product changes often. Manually retrain when you ship a meaningful change to the help center or pricing. The Antwerp clinic case was caused by a single stale page that automatic re-crawl would have caught.
Can I train a chatbot on PDFs?
Yes. Every major platform accepts PDF, DOCX, and text uploads. The platform extracts text, chunks it, and indexes it the same way it indexes a website page. Long PDFs sometimes retrieve poorly because the chunks lose context; splitting long PDFs into focused documents helps.
What is the difference between training a chatbot and training an AI agent?
The data layer is the same — RAG on your content. The difference is what the system can do with the retrieved information. A chatbot writes a reply. An agent writes a reply and calls tools — books meetings, writes CRM records, processes refunds — based on the conversation. If you are training a system that should take actions, you also need to configure the tools and the policies for using them.
---
A disclosure. I run SimplyBoost, a flat-priced AI agent that trains on your website in roughly five minutes and handles inquiries across web, WhatsApp, and Instagram. We see the same data-layer failures every week — teams ship a bot, ship a bug, blame the platform. Most of the time it is the data. If you want to see what training on your site looks like end-to-end, there is a no-credit-card trial at get.simplyboost.io.
SimplyBoost is registered in the Netherlands (KVK 87456346). Data hosted in Frankfurt, EU.