A chatbot that has not been given your material will answer anyway. It will invent a returns window, guess a delivery time, and do it in a confident, well-written sentence that a customer has no reason to doubt. That is the failure mode worth designing against, and the way to avoid it is unglamorous: give the assistant good documents, structured well, and check what it says.

This is a step-by-step guide to doing that for a webshop. No Python, no machine learning background, no model training in the academic sense. Just the sources to feed it, how to shape them, why answers go wrong, and how to test before you let it near a customer.

It is written for the most common use case we see: a shop owner who wants to create a chatbot that handles delivery, returns and product questions accurately, and refers everything else to a colleague.

What "training" actually means here

The word covers three different things, and mixing them up wastes weeks.

  • Training a model from scratch — building a language model on a huge dataset. This costs millions and is not what anyone means when they say train your chatbot.
  • Fine-tuning — nudging a base model's style or format with a few hundred examples. It changes tone, not facts, and it will not teach the model your shipping cut-off.
  • Retrieval — indexing your own documents and handing the relevant passages to the model at the moment a question is asked. This is what modern tools do, and it is what you want.

Essentially all customer service chatbots you can buy today use the third approach, and it has a formal name: retrieval augmented generation. Your text is split into chunks, each chunk gets a vector — a numerical fingerprint of its meaning — and those vectors go into an index. When a customer asks something, their question is turned into a vector too, the closest chunks are pulled out, and the model answers using them.

The practical consequences are worth internalising. You never retrain anything: edit the document and the next answer changes. Facts live in your files, not in the model. And because the system can see how well the retrieved chunks match the question, a well-built assistant can tell when it has nothing solid and stop rather than improvise.

Which sources to feed it

Start with the questions your inbox already gets, then find the document that answers each one. Not the other way round. Uploading everything you own produces a large, noisy knowledge base that retrieves the wrong thing.

Shipping and delivery

Carriers, delivery windows per country, cut-off time for same-day dispatch, weekend handling, shipping costs and the free-shipping threshold, what happens when a parcel goes missing. Write the cut-off as an explicit time and time zone. "Ordered before 15:00 CET on a working day ships the same day" is retrievable; "order early for fast delivery" is not.

Returns, exchanges and refunds

The window in days, who pays return postage, condition requirements, sale and clearance exceptions, how long a refund takes to land, and how an exchange differs from a return. This is the single highest-value document you will write, because returns questions are frequent, factual, and expensive to get wrong.

Product catalogue

Titles, descriptions, materials, dimensions, compatibility, care instructions, what is in the box. If your descriptions are three lines of adjectives, the assistant will have nothing to answer with. Export the catalogue as structured text — one product per entry, with the attributes spelled out as sentences rather than left in a table.

Manuals and technical documentation

Installation steps, troubleshooting, warranty terms, spare parts. These are usually PDFs, which is fine as long as the text is selectable. A scanned manual is an image and the indexer will get nothing from it.

Your existing FAQs and past conversations

Your FAQ page is already written in the customer's language, which makes it excellent training data. Better still, read a month of real conversations and write down the twenty questions that actually recur. Half of them will not be on your FAQ page. Those gaps are the most valuable content you will produce.

What to leave out

Marketing copy, blog posts, press releases, anything superseded, and internal notes containing prices or margins you do not want quoted back. Every irrelevant document is a chance for the retrieval step to surface the wrong passage. Fewer, cleaner knowledge sources beat more.

How to structure the documents

Data quality does more for accurate answers than any model choice. A few rules that consistently help:

  • One topic per document. A single file covering shipping, returns and warranty will retrieve badly for all three.
  • Use plain headings. Chunking usually follows structure, so a clear heading keeps a passage self-contained.
  • Make each section stand alone. Avoid "as mentioned above" — the chunk may be retrieved without whatever was above it.
  • Write numbers explicitly. 30 days, 4.95 euros, 15:00 CET. Vague phrasing produces vague chatbot answers.
  • Turn tables into sentences. Shipping matrices lose their column headers when flattened. "Delivery to Belgium takes 2–3 working days and costs 5.95 euros" survives; a stray cell does not.
  • Date the document. A line saying "last updated 4 August 2026" helps you and helps anyone auditing an answer later.
  • Answer the edge case in the same file. If sale items cannot be returned, say so in the returns document, not in a footnote on a different page.

A step-by-step process

Here is the sequence that works for a small team, start to finish.

  • 1. Data collection. Pull the twenty most common customer questions from your inbox. List them.
  • 2. Map each question to a source. Anything with no source is a document you still have to write. Write those first.
  • 3. Clean before you upload. Remove duplicates, delete superseded versions, fix the numbers.
  • 4. Upload or point at a URL. Most no-code tools take files or crawl your site. Crawling is quicker; uploading gives you control over exactly what is in the dataset.
  • 5. Set the refusal behaviour. Tell the assistant to hand over rather than guess. This is a setting worth more than any amount of prompt polish.
  • 6. Test against your list. Ask all twenty questions plus the awkward variants. Compare each answer with the source.
  • 7. Deploy narrow. Go live with handover switched on and read every conversation for the first two weeks.

Nothing here needs code. If you want the specifics of uploading sources and setting the escalation threshold in Veyra, the documentation covers each screen.

Why chatbot answers go wrong

Almost every bad answer traces back to one of five causes, and none of them is the AI being stupid.

Contradictory pages

This is the most common by far. Your returns page says 30 days, a landing page from last Christmas says 60, and the terms and conditions say 14. The retrieval step finds all three, the model picks one, and you have no idea which until a customer quotes it. Search your own site for the numbers that matter and make them agree before you index anything.

Out-of-date policies

A carrier changed in March, the shipping page was updated, but the old PDF is still in the knowledge base. The index does not know which is newer. Anything you upload must be the version you would stand behind today, and ongoing maintenance means removing the old one, not just adding the new.

Missing edge cases

The policy covers the normal path, so the assistant answers the normal path — and confidently applies it to a customer whose situation is not normal. Sale items, personalised goods, hygiene products, gifts bought in November for Christmas, orders shipped in two parcels. Write these down explicitly or accept that the answer will be wrong for them.

Marketing language in factual documents

"Lightning-fast delivery" retrieves for a delivery question and answers nothing. Keep persuasion on the product page and facts in the knowledge base.

The wrong thing retrieved

Sometimes retrieval simply picks a plausible neighbour — the returns section of a different product line, or last year's holiday schedule. You spot this by reading transcripts, and you fix it by splitting or renaming the documents involved so the intent of each one is unambiguous.

How to test before you go live

Build a test set. Thirty questions in a spreadsheet, with the correct answer and the source next to each. It takes an hour and it is the only way to know whether a change made things better or worse.

Cover four categories:

  • The common ones — delivery time, returns window, order status, stock.
  • The awkward phrasings — typos, one-word messages, two questions in a single sentence, another language if you sell across borders.
  • The edge cases — sale items, damaged goods, a return past the deadline.
  • The unanswerable — something you have deliberately not documented. The right answer here is "I do not know, let me get a colleague." If you get a fluent invention instead, fix that before anything else.

Re-run the set whenever you change a source. Then evaluate the live traffic weekly: transcripts show you areas for improvement that no test set predicts, because customers ask things you would never think of. That loop is what makes an assistant that improves over time, rather than one that was good on launch day.

Keep the refusal behaviour honest as you tune. It is tempting to widen what the bot will attempt once accuracy looks good, but the value of a stop is that customers can trust the answers that do come. Our guide to the handover from chatbot to human explains what the visitor and your colleague should each see when that happens.

Common questions

Can you train a chatbot with your own data?

Yes, and for a webshop it is the only approach that makes sense. You are not altering the model — you are giving it your documents to read at answer time. Any tool built on retrieval supports this, including Veyra, where you upload sources or point at pages and the assistant answers from those.

How do I train my own chatbot?

Gather your shipping policy, returns policy, FAQs and product information; clean them so each fact appears once and correctly; upload them; set the assistant to hand over when unsure; then test with thirty real questions before going live. The work is in the documents, not the software. Expect an afternoon for the first pass and an hour a month afterwards.

How can I train ChatGPT on my own data?

Three options, in increasing order of usefulness for a shop. You can paste context into a ChatGPT conversation, which works once and then forgets. You can build one of OpenAI's custom GPTs and attach files to it, which is fine internally but is not a support channel on your website — nobody visiting your shop is going to log into ChatGPT. Or you use a product that connects to the OpenAI API with your own key and puts the result in a widget on your site, with conversation history and human handover attached. Only the third is a customer support tool.

Do I need Python or machine learning skills?

No. A decade ago you would have written code to build a dataset, embed it and query a vector store. Today the no-code tools do that for you. Some technical literacy helps when you are deciding what to include, but the skill that actually matters is writing clear documentation.

How much data do you need?

Less than people expect. Four good documents — shipping, returns, FAQ, product information — cover the majority of a webshop's questions. Twenty pages of accurate, current text will beat two hundred pages of mixed vintage every time.

Is my data used to train someone else's model?

Check the privacy policy of whichever provider you use, and check it specifically for whether API inputs are used for model training. With Veyra you supply your own OpenAI key, so the traffic runs on your own account under OpenAI's API terms and you can see exactly what is being sent. Data privacy is easier to reason about when the AI account is yours.

How often should I update it?

Whenever a fact changes — a price, a carrier, a policy — and otherwise once a month with the transcripts in front of you. Put a recurring reminder in the calendar. A knowledge base nobody owns drifts out of date within a quarter, and the assistant will keep quoting the old version confidently.

Where this fits

Good source documents are what separate an assistant that deflects real work from one that produces plausible nonsense. Everything else — the widget, the model, the settings — is comparatively easy. If you are still deciding what to automate at all, our pillar guide to the customer service chatbot is the place to start, and the questions worth automating first in a webshop narrows it to the ones with the fastest payback.

If you are weighing a bot against simply answering chats yourself, chatbot vs live chat lays out the trade-off honestly, and what to automate and what to leave alone covers the wider process around it.