AI Chatbot: Can It Really Serve Your Customers?

Yes, a chatbot can serve your customers — provided you know which chatbot we're talking about. The word covers three systems that have almost nothing in common: the scripted decision trees of the 2015s, RAG systems that answer based on your own documents, and agents that carry out actions within your systems. The first frustrates as soon as a question strays from the script, the second informs reliably, the third acts. Success hinges less on the choice of model than on the scoping: scope, document base, human escalation.

Three Systems Under One Word

Scripted chatbots represent the earlier generation, still widely deployed. The user clicks through a list, the system follows its decision tree, and delivers pre-written answers. For stable questions — opening hours, order tracking, public pricing — this works. As soon as a request strays from the intended path, you get the inevitable "I didn't understand that, could you rephrase?" Their strength is predictability; their limitation, a total inability to handle the unexpected. If your last experience was with this generation, your skepticism is well-founded — but it's dated too.

RAG-grounded chatbots make up the dominant generation for serious enterprise projects in 2026. They understand freely phrased questions, retain conversation context, and answer based on the company's own documents, citing sources. They don't follow a script: they search, then formulate.

Agents bring up the rear, the most recent generation. An agent doesn't just answer: it uses tools — querying a management system, scheduling an appointment, creating a ticket — to accomplish a task that goes beyond conversation. Knowing where your project sits among these three categories is the most structuring decision in the scoping phase: each carries a different level of effort, operating cost, and risk profile.

How Does a RAG Chatbot Avoid Making Things Up?

RAG — Retrieval-Augmented Generation — combines a language model with semantic search over a company-specific knowledge base: every answer is grounded in verified internal documents, which the system can cite. The mechanics unfold in four steps: your documents — manuals, product sheets, procedures — are split into segments and converted into vector representations that capture their meaning; the user's question undergoes the same conversion; the closest segments are injected into the query sent to the model; the resulting answer is grounded in these sources, which it can reference.

This is the structural answer to the central flaw of models used alone: hallucinations. Grounded in verified documents, the system stays factual on what the knowledge base covers — and can explicitly say "I don't know" when it doesn't. The protection isn't absolute, though: the model can still extrapolate when the retrieved segments are only partially relevant. Monitoring responses and giving users a way to flag issues remain necessary.

I use this mechanism every day: the conversational assistant in FiscalDoc, my local tax document management application, queries an SQLite database and re-reads my documents to answer questions like "total pillar 3a deductions over the past three years." Everything runs on my own machine, with no network calls. What this small case taught me holds everywhere: answer quality tracks the quality of what's indexed. Outdated documents, outdated answers; contradictory documents, inconsistent answers. Preparing and maintaining the document base generally weighs more heavily in the total effort than the technical integration itself — better to plan for that at the scoping stage than discover it mid-project.

When the Chatbot Becomes an Agent That Acts

The agent adds execution capability. Checking an order's status in your management system and answering the customer with that information. Scheduling an appointment in a salesperson's calendar after qualifying the need. Creating a complete support ticket. Generating a quote from parameters extracted during the conversation. Triggering an internal approval workflow, with supporting documentation.

This capability demands a stricter framework than a simple answer: explicitly defined accessible tools, bounded permissions, security rules set at the design stage. The agent chooses which tool to use, but within a scope you've defined. Operating cost follows complexity: an agent can chain together several dozen model calls for a single task, where a RAG answer needs one or two. I therefore reserve agents for cases where the automated value clearly justifies that cost — and I'd advise against starting there.

What Is This Actually Useful For in Switzerland?

Four use cases come up consistently in serious projects in Switzerland:

1. Continuous multilingual customer support — current models natively handle French, German, Italian, and English: a direct advantage in a structurally multilingual market.
2. Documented technical support — fed by your manuals and troubleshooting guides, the system guides the customer on the exact product they own, instead of generic answers.
3. Lead qualification — on your website, the system asks the questions that qualify a visitor's intent and directs them to the right contact — something a form cannot do.
4. The internal assistant — fed with your procedures and policies, it answers employees' questions without drawing on support functions; often the simplest deployment and the one with the best return.

This last case deserves a mention: starting internally allows for learning — document base quality, phrasing, measurement — without exposing a customer to the break-in period. It's frequently the first building block I propose in my automation solutions.

And When It Doesn't Know? Human Escalation

A well-designed chatbot knows how to recognize its limits. Emotional requests, complex complaints, cases outside the documented scope must be handed off to a human — and the design of that handoff matters as much as the technology. Three traits distinguish a successful escalation. Detection: identifying, through rules or conversation signals, what exceeds the system's capabilities, and transferring instead of forcing an answer. Continuity: the employee who takes over receives the history and qualified context, without making the customer repeat themselves. Honesty about expectations: if the transfer isn't immediate, say so, give a realistic timeframe, offer a callback.

This point connects to the law: the FADP requires transparency around automated processing that affects individuals^[1]. When the system prepares or produces a significant automated decision, the possibility of human review needs to be addressed at the design stage, not as an afterthought.

What the FADP Requires From the Design Stage

Three dimensions come up when scoping any enterprise chatbot in Switzerland. Transparency about the nature of the system: the user must know they're talking to a machine — a clear notice at the start of the conversation is enough, but it isn't optional. The handling of shared data: contact details, identifiers, financial or health data disclosed over the course of the conversation fall within the scope of the FADP, with its requirements for lawfulness, proportionality, and transparency. And finally, the location of processing: hosting under a foreign jurisdiction can raise questions of extraterritorial data access — a point that sensitive sectors need to settle explicitly, with real alternatives: Swiss or European infrastructure, or open models deployed on controlled infrastructure, as I detail in the architecture of a well-built AI project.

What remains is the overall discipline, the one I apply in my custom conversational solutions: start with a limited, measurable scope, invest first in the knowledge base, design the escalation from day one, then measure — resolution rate, satisfaction, unanswered questions. A well-scoped chatbot absorbs a large share of repetitive requests and frees up time for high-value exchanges; a poorly scoped one manufactures frustration and technical debt. The difference isn't about the model chosen: it's about the rigor of the scoping. To place this project among an SME's other priorities, see What Should a Swiss SME Do About AI in 2026?.

Key takeaways

— "Chatbot" covers three distinct systems: rigid scripts, RAG grounded in your documents, agents that act — scoping starts with choosing your category. — Answer quality tracks the quality of the document base: preparing it generally weighs more than the technical integration. — Human escalation and FADP transparency need to be designed in from day one: detecting limits, transmitting context, clearly flagging the automated nature.

FAQ

Can a RAG chatbot still say something wrong? The risk is significantly reduced, not eliminated. Grounded in your documents, the system stays factual on what the knowledge base covers and can admit when it doesn't know. It can still extrapolate when the retrieved segments are incomplete — hence the value of monitoring responses and giving users a flagging button.

How much does an enterprise chatbot cost? It all depends on the category and scope. An internal RAG assistant built on your own documentation is a contained project; an agent connected to several business systems costs noticeably more, both to build and to run, since each task can require dozens of model calls. The most underestimated variable remains preparing the document base.

Will my customers agree to talk to a machine? They accept it when three conditions are met: the automated nature is announced upfront, the answers are genuinely useful because they're grounded in your documents, and a human remains reachable without an obstacle course. It's a botched escalation, far more than automation itself, that drives people away.

Does the system need to be hosted in Switzerland? Not systematically, but the question is settled at the scoping stage depending on the data processed. For conversations without sensitive data, an international provider with contractual commitments may be enough. As soon as sensitive data is involved — health, finance — Swiss or European hosting, or even an open model on controlled infrastructure, becomes the prudent path.

Are your teams still answering the same questions ten times a day? The AI Usage Diagnostic: sixty minutes to map your actual workflows, identify what deserves a custom build, what stays in SaaS, and what doesn't need AI at all. Book a diagnostic

Sources

[1] Federal Act on Data Protection (FADP), revision of 25 September 2020, entered into force on 1 September 2023. www.fedlex.admin.ch/eli/cc/2022/491/fr [↩]

Jérôme Deshaie is CEO and founder of MCVA Consulting SA, an augmented agency based in Valais. Fifteen years serving major international brands, now working directly with Swiss SMEs. Background.