Chatbot development.

A chatbot does three things reliably: it answers recurring questions immediately, it is reachable outside office hours, and it structures a request far enough that the handover to a person goes faster. Everything beyond that is either a question of implementation quality or simply not what the tool is for.

What it does not do: advice that rests on experience. Binding commitments on price, date or contract terms. Sales conversations with genuine needs analysis. And above all, visibility — answers in a chat window do not appear in your page source, are not indexed by search engines and are not cited as a source by AI systems. Prepare the same answers as visible pages instead and you get both: the answer for visitors and the discoverability.

The most common error of expectation is about volume. A chatbot does not reduce the number of enquiries; it shifts them. It catches the simple questions, the complex ones still arrive — only now after a round of chat that has already cost the other person patience. Whether that is a net gain depends entirely on how well the handover works.

A second, underrated effect is the data. Chat transcripts show very precisely what your customers do not understand. That insight is often worth more than the enquiries deflected — it tells you which page you need to rewrite. How this translates into measurable improvement is described in our article on conversion optimisation.

A rule-based bot follows a predefined conversation tree and can only output text that somebody wrote and approved; a language-model-based bot formulates its answer afresh every time and can therefore also say things nobody intended. That single distinction determines cost, risk, upkeep and auditability all at once.

The rule-based route is the better start in most SME cases. It is set up in days, costs almost nothing to run, cannot invent anything and can be tested exhaustively: there is a finite number of paths. Its limit is just as clear — the moment somebody asks a question that was not foreseen, the conversation ends in a dead end or at the contact form.

The language-model route understands freely worded questions, can rephrase, answer in several languages and summarise from your documents. In exchange it costs by usage, demands continuous sampling and brings the risk of invented answers. Technically behind it sits a language model whose behaviour is bounded through prompt instructions.

In practice we almost always build a mixture. The ten to twenty most frequent concerns run through fixed buttons with approved text — fast, free and safe. Only the open remainder goes to the model, and strictly tied to your own content. That split lowers cost and risk at the same time, without the person on the other side noticing the difference.

Invented answers cannot be excluded, but five measures narrow them far enough that a bot becomes operationally defensible. Leave one of them out and you have moved the risk onto your customers.

• Binding to your own sources. The model answers not from its general knowledge but exclusively from your documents, which are searched at runtime and passed along with the question. The method is called retrieval augmented generation and it is the single most important measure.
• Permission to refuse. If the search finds no matching passage, the correct output is "I do not know", followed by the route to a person. A bot that always says something is a bot that will eventually say something wrong.
• Blocked subject areas. Price commitments, delivery dates, legal and health information, contract interpretation and anything that creates a binding expectation are excluded at instruction level and caught again by a filter.
• Source references in the answer. Every statement points at the page it came from. That lets customers verify and lets you find errors quickly.
• Logging and sampling. All transcripts are stored and read through regularly. Without that ritual, nobody notices that the bot has been quoting the wrong amounts since the last price update.

On top of that comes expectation management in the interface itself: a short note that an AI assistant is answering and that errors are possible, plus a route to a person visible at all times. That costs nothing and prevents most complaints.

A chat transcript is regularly a processing of personal data — often a more delicate one than a contact form, because people give away more in conversation than a form asks for. Four points therefore have to be settled before going live.

First, information. Since 1 September 2023 the revised Data Protection Act has required, under Article 19 FADP, adequate information about purpose, recipients and any disclosure abroad. In practice that means your privacy policy has to name the chatbot, and the pointer to it belongs visibly in the chat window, not in a footnote.

Second, processing on your behalf. The provider of the model and the chat platform processes data on your instruction; under Article 9 FADP that needs a contractual basis and the same data security you are bound to yourself. Third, disclosure abroad: if data leaves Switzerland, Article 16 FADP applies, requiring an adequate level of protection or suitable safeguards. Fourth, retention — set a deletion period for transcripts before the first one is stored, and settle contractually whether inputs may be used for training.

Then there is disclosure. Since 2 August 2026, Article 50 of the EU AI Act has required people to be informed when they interact with an AI system, unless that is obvious anyway. This affects Swiss businesses as soon as they address customers in the EU. Switzerland itself has no AI act along EU lines; in 2025 the Federal Council decided on sector-by-sector implementation of the Council of Europe AI Convention, with a consultation draft announced for the end of 2026. This orientation does not replace legal advice; it describes what we build in by default.

The quality of a chatbot is not decided by its best answers but by how cleanly it gives up. A bot that goes round in circles on the third follow-up question costs you more goodwill than its first two correct answers earned.

Four rules have proven themselves. First, a visible exit on every screen — not hidden behind a menu but as a permanently available button. Second, an automatic stop after two unsuccessful attempts: what follows is not a third attempt but the handover. Third, passing the context along: what has been written so far goes to the person or into the ticket, so nobody has to repeat themselves. Fourth, honesty about availability — if nobody takes over outside office hours, the bot has to say so and name a realistic response time instead of pretending to be reachable.

This sounds banal and is the most common implementation mistake. Many bots are designed to hold the conversation as long as possible. For an SME the opposite is right: the bot should recognise as early as possible that a person is now the better answer — and make that transition pleasant.

A chatbot is not a project with an end but an operational task — and over three years the upkeep usually costs more than the build. Fail to plan for that and after a year you are running an information desk with out-of-date information.

Recurring work: reading real transcripts to find errors and unanswered questions. Updating the knowledge base with every change to prices, range, opening hours or processes. Sharpening the instructions whenever a type of error repeats. A regression test after every model update from the provider, because answering behaviour can shift measurably. And checking the deletion periods.

On top come the direct costs: usage-based model fees that rise with the number of conversations, plus any platform licences. Both are easy to plan once the conversation volume is known — and not before. That is why we start with a bounded prototype and measure instead of guessing.

The simplest check before deciding: count for one week how many enquiries arrive through your website and what share of them consists of genuinely recurring questions. If that share is below half, a chatbot will not earn back the effort.

For a substantial share of SME websites a chatbot is the wrong expense — even though we offer the service, and we say so in the first conversation. Six situations argue against it.

• Too little volume. With a handful of enquiries a week, a person answers them faster and better than the bot can ever be maintained.
• Too little repetition. If every enquiry is a one-off, there is nothing to automate. That applies to many advice-heavy and project-based businesses.
• No maintained knowledge base. Without current, consistent documents a model has nothing to stand on. The bot then becomes exactly as good as your worst source.
• Nobody is responsible. Without a named person for sampling and updates, the bot goes stale within months and then does more harm than good.
• High bindingness in the core business. Where every piece of information has legal or financial consequences, the review effort exceeds the benefit.
• The real problem is elsewhere. If the website does not answer the most common questions at all, a bot is a plaster on a structural weakness. Then the answers belong on visible pages — where they can also be found and cited in AI answers.

The alternative is usually cheaper and more effective: an honestly answered questions page, a calculator or configurator for the price question, and a short form with a visible phone number. On our own website we take exactly that route — with the project calculator, the configurator and the SEO check instead of a chat window. We build such tools for clients too: calculators and configurators. And because visible answers are the real lever, this point connects directly to GEO.

If the case fits, we build in four steps — and the first is always an analysis of real enquiries, never a tool selection. Without that foundation neither the scope can be defined nor the benefit demonstrated later.

Step one: we read the enquiries of the past months and group them. That produces a list of concerns with frequencies — the basis for everything that follows. Step two: we decide which concerns run through fixed rules and which the model handles, and we define the blocked topics. Step three: we build the prototype against your real documents, test it with historical enquiries and measure how often it answers correctly, how often it says nothing and how often it answers wrongly. Step four: go live with logging, disclosure, deletion periods and a fixed review rhythm.

What we do not claim along the way: we keep no list of chatbot references with savings figures. Our documented work sits in web development, e-commerce, SEO and marketing — you can read it under work. In the design and build of web applications with input logic, data connections and reporting we do have demonstrable practice; visible in the three tools on this website and in projects such as the web application for tax returns.

The entry point is the same as for every undertaking of ours in this field: a validated prototype from CHF 10'000, which shows before the large investment whether the answer quality holds. If it does not, we say so — and instead build the pages on which the answers stand visibly. What that looks like for smaller businesses is set out under web design from CHF 3'000. If the task is not answering but acting, the boundary is drawn under AI agent development.