If you want to train a chatbot on your own data, the first useful thing to know is that you probably should not train anything. For customer support, the reliable route is to connect your documents and let the bot read them at the moment a question arrives. The model stays as it is; your content sits outside it and is retrieved on demand. That is why an edit to your delivery page this morning can be in the bot’s answers this afternoon.

The phrase “train on your own data” covers two quite different techniques, and the industry uses it loosely enough to be misleading. Knowing which one a vendor means is the difference between a bot you can correct in a minute and one you cannot correct at all.

Training and connecting are not the same thing

Fine-tuning adjusts the model’s own weights using examples you supply. It is genuinely useful for teaching a style, a format, or a domain vocabulary. It is a poor way to teach facts. A fine-tuned model still answers from memory, so it cannot show you where an answer came from, it has no way to know that your policy changed last week, and correcting a single wrong fact means preparing data and training again.

Retrieval keeps your content outside the model. Documents are split into passages and indexed; each question is matched against that index; the best passages are handed to the model with an instruction to answer from them and name the one it used. Facts live in files you control, which means you correct an answer by editing a document — the same place your team already looks.

For support, that difference decides everything. You need answers that change when your content changes, and a footnote you can check. Fine-tuning gives you neither.

Step one — find the questions worth answering

Before connecting anything, read last month’s inbox and write down the ten questions that arrived most often. Not the questions you wish customers asked; the ones they actually send, in their words. This list is your specification. It tells you which documents matter, and it is the test set you will use in step three.

Most small teams find that a handful of topics account for the majority of what arrives: delivery times, returns, sizing, opening hours, account access. A bot that handles those well is worth more than one that has read everything and answers none of them precisely.

Step two — connect the documents that hold those answers

Serochat reads from the sources you connect, and each has limits worth knowing before you plan around it.

  • Website pages: up to 25 pages you select per source. Discovery can surface up to 500 candidate URLs from your site for you to choose from, but only the pages you pick are indexed — this is not a whole-site crawl.
  • Google Drive: files you individually pick in Google’s own picker, because the permission we request cannot see anything else in your Drive. Google-native Docs, Sheets and Slides only; a PDF sitting in Drive is skipped, so upload it directly instead.
  • Microsoft 365: Word, Excel, PowerPoint, PDF and text files from OneDrive and SharePoint.
  • Notion: up to 50 pages per sync. Zendesk: Help Center articles, drafts skipped. Confluence: Cloud pages.
  • A custom JSON API: up to 500 items with the fields you map, for content that lives in your own system.
  • Direct uploads: PDF, DOCX, TXT and MD files up to 25 MB each, with PDFs read to 200 pages.

Start with the one source that covers most of your ten questions. You can add the rest once you have seen real answers.

Step three — ask it your real questions

Open the widget and work through the list from step one, phrased the way customers phrase them, typos and all. You are checking three things: whether the answer is right, whether the document named underneath is the one you expected, and whether it says it does not know when it should.

The last of those is the test people skip. Ask something your documents genuinely do not cover. A bot that improvises here will improvise in front of a customer.

Step four — write the answers your documents never had

Some questions have no home in your content. Serochat clusters unanswered questions into a training queue overnight, so the gaps come to you sorted by how often they were asked. Write the answer once as a question-and-answer pair, and every future asker gets it directly. These pairs are retrieved and cited exactly like documents, and they do not count against your plan’s source limit, so they are the cheapest fix available for a wrong or missing answer.

Step five — keep it in sync

Connected sources are re-synced automatically when they are more than a day old, and there is a manual sync button for the moments that cannot wait — a price change, a policy correction. If a website page fails to fetch, the last good copy is kept rather than dropped, so a temporary outage on your site does not blank the bot’s knowledge.

Make the re-sync part of the content change, not a separate chore. Whoever edits the policy presses sync.

What this approach cannot do

It cannot rescue documents that contradict each other. Two pages with different refund windows will produce inconsistent answers, correctly cited, and the fix is editorial rather than technical.

It cannot always bridge vocabulary. Serochat ranks passages with full-text keyword search, so a question asked in words your documents never use may retrieve poorly. When it does, the bot hands off instead of guessing, and the question lands in the training queue for you to answer properly.

And it cannot make your content true. A grounded bot is a faithful reader — which is the point, and also the catch.

Common questions

Do I have to retrain the bot when my content changes?

No. There is no training step to repeat. Re-sync the source, and the next answer uses the new text.

Can I train a chatbot on my website?

You can connect it. Choose the 25 pages that answer real questions rather than pointing at the domain and hoping; your best help pages are worth more than your homepage.

Is my content used to train anyone’s model?

Not by us. Conversation content and connected documents are not used to train third-party models, and our privacy page names every sub-processor involved in producing an answer.

Connecting documents is unglamorous work, and it is most of the job. The afternoon you spend choosing ten pages and testing ten questions is what separates a bot that answers from one that performs.