AI chatbot on the website: when RAG really pays off

A chatbot on your own website was long an annoyance: rigid decision trees that failed at the second follow-up question. With language models that has changed – but only if the assistant gets the right information. That is exactly what RAG is about.

What RAG means

RAG stands for Retrieval Augmented Generation. The process is simpler than the term: your documents – service pages, data sheets, instructions, question collections – are broken into small sections and stored in a database that searches by meaning rather than keyword. When someone asks a question, the system fetches the matching sections and presents them to the language model together with the question. The model answers exclusively from that material.

The decisive advantage: the model is not trained but supplied. If a data sheet changes, you swap the source – the answer is correct from the next question on.

Which data the bot should know

The selection decides the quality. Start with what is already written and correct:

What does not belong in are terms lists, internal calculations, personnel data and anything you would not tell a stranger on the phone. The assistant is public, even in a small window.

Data protection: hosting and the FADP

As soon as users enter a name, address or request in the chat, you are processing personal data. We fix four points in every project. Transparency: a note that an assistant is answering and where the inputs go. Processing location: for personal data we choose models with processing in Switzerland or the EU and contractually exclude use of the inputs for training. Data minimisation: no unnecessary mandatory fields, histories with a deletion period. And inclusion in the privacy policy and in the list of processors.

Handover to people

The most important button in any assistant is the one that leads to a person. We define fixed triggers: twice no verifiable answer, a complaint, a question about binding terms, an annoyed tone or the wish for a person. Then it hands over – with the history so far, so nobody has to tell everything twice. Outside office hours that becomes a callback request with a time window.

Typical use cases

In support the assistant answers recurring questions on operation, warranty and procedure and relieves the calls that challenge nobody technically. For appointment requests it records the request, place and preferred time and creates a proposal that a person confirms. In product advice it leads through a few questions to the right variant – for instance to the wall mount based on device weight, hole pattern and wall construction – and hands over for the decision.

What a bot should not be able to do

It should not make binding commitments, not quote situation-dependent terms, not confirm appointments and not give legal or safety-relevant information. It should not pretend to be a person. And it should be able to say that it does not know something – one that invents something for every question does more damage than none at all.

Conclusion

An assistant is only as good as the documents behind it and the rule for when it hands over. We start with the twenty most common questions from phone and e-mail and measure how many of them the assistant answers cleanly. Only when that convinces does it go on the website – first on one page, not everywhere.