Answer routine requests across DE / FR / IT / EN with RAG over the support knowledge base — and escalate cleanly the moment it stops being routine.
In short: Routine support across DE / FR / IT / EN with RAG over the support knowledge base; clean escalation in the detected language. Stack: Claude for multilingual coverage (idiomatic across all three Swiss national languages plus English), Azure OpenAI Switzerland when Swiss data residency is contractually required, RAG index with an eval set per language. Anti-hype: multilingual support pays off when request volume per language is substantial (rule of thumb: over 20 requests per day in the rarest language). For smaller volume or highly specialised single-language flows, a well-rehearsed multilingual team often remains the better model.
Swiss SMBs serving end customers across multiple language regions — tourism, insurance, mail-order, public services — face a structural cost problem in support. A large share of the volume is standard: "Where is my order?", "How do I change my booking details?", "When does the mountain station open?", "What documents do I need to register?". These requests are individual for the customer, but collectively repetitive for the vendor — and they still need to be answered in the customer's language, politely and correctly.
A seasonal tourism company with DE / FR / IT / EN customers has two practical options: build a fully four-language team (expensive, hard to recruit, oversized in low season), or reduce support to one or two languages and serve the rest in English or via translation workarounds (customers frustrated, conversion drops). AI-supported support is not suitable for all requests — but for the standard 60-70 % it is, and the rest lands with a human in the right language. That combination — autonomous for routine, cleanly escalated for the rest — is the lever.
The pipeline is cleanly cut. Inbound message (mail, web form, chat) → language detection via the model itself (Claude reliably detects DE / FR / IT / EN, including Swiss politeness conventions and regional vocabulary) → topic classification against a customer-specific catalogue (order status, booking change, opening hours, complaint, sensitive matters, …). For clearly routine-classified requests, RAG runs over the support knowledge base: the index contains FAQs, terms and conditions, product data sheets and internal reply templates — versioned per language, because content varies regionally (opening hours per location, T&Cs per language version).
Before any outgoing answer comes the confidence gate. Above the threshold the answer goes out autonomously, in the detected language, with a source link to the knowledge base entry. Below the threshold the agent escalates to a human — and specifically to a human who speaks the language. Language detection is robust enough that even on escalated cases the routing into the right queue works. Topic gates above the confidence logic: complaints, grievances, safety- or health-relevant matters are always escalated, no matter how high the RAG score sits. Models: Claude (Anthropic direct) as the default; Azure OpenAI Switzerland when Swiss data residency is a contract condition.
Important: this system doesn't just answer — it also knows when it should not answer. The topic gates are the ethical line. Leaving complaints or safety questions to a confidence score risks damage no eval set ever recovers from. Escalation in those cases isn't "the agent failed" — it's "the agent correctly recognised that a human needs to handle this".
A Swiss travel provider — composite, not a real client — with customers across all four languages and roughly 80 support requests per day. A mix of clearly routine (FAQ matches: booking changes, mountain station opening hours, T&Cs clarification, cancellation conditions) and non-routine (complaints after a cancelled tour, individual wishes for group bookings, multilingual complex cases where an Italian-speaking customer responds to a German-language reservation flow). Before the agent, a three-person support team primarily served DE and FR; Italian requests were answered in English or routed with delay to an external translation helper. After rollout the agent runs across all four languages: routine requests receive answers in under two minutes, with correct tone and a source link. Complaints and complex cases land directly with a human in the right language, accompanied by the original request and a structured briefing from the agent's pre-work (detected language, topic, available context).
Typical pattern: 60-70 % of requests get answered fully automatically in the right language; the support team handles only what's actually interesting — complaints, special wishes, ambiguous cases — and does so in the customer's language. Important: the 60-70 % is directional, not guaranteed. The actual ratio depends on the quality and maintenance of the knowledge base — a poorly maintained FAQ collection leads to poor RAG performance regardless of the model. The second effect: first-response time on the routine layer drops from hours to minutes, and minority-language customers (e.g. Italian-speaking in a primarily DE/FR-driven setup) get consistent native-language support for the first time. Effort isn't eliminated, it's shifted: away from repetitive first replies, toward knowledge base maintenance and handling the escalated cases.
Claude and GPT-4 are both strong in DE / FR / IT — all three languages with good idiomatic range and a usable feel for Swiss politeness conventions (more polite framing, less direct phrasing than in other DACH variants). In our experience, Italian is the most common weak spot for smaller models: open-source models like Llama-3 or Mistral tend to struggle more with IT than with DE or FR, and rarely handle Swiss specifics well — dialect touches, regional terms, politeness-driven phrasing. Recommendation for CH multilingual setups: Claude or GPT-4 as the default; if compliance or licensing requires an open-source model, plan an intensive per-language eval setup before production. Romansh is not production-ready in mainstream LLMs as of May 2026 — for the relevant volume in Graubünden, human handling remains the more professional path.
Three thresholds that fire independently. (a) Topic classification: complaints, grievances, safety- or health-relevant matters escalate directly, regardless of how high the confidence would be — these topics should land with a human. (b) Confidence threshold: when the RAG score is below a configured threshold (e.g. below 0.7 in a standard configuration), the agent escalates — the knowledge base has no sufficiently solid answer for the question. (c) Length and complexity threshold: when a request contains multi-issues (one mail with three different questions) or exceeds a certain token length, the agent either splits the request or escalates directly. Important: escalated requests land with a human in the right language. The agent detects language reliably even when it doesn't answer itself — the language routing component is independent of content confidence.
Eval set per language, typically 50 to 100 questions with defined answer expectations. On top of that, a cross-language eval: the same question asked in all four languages, with answers expected to be content-consistent (even if phrased to fit each language). On every model swap or RAG index update the eval set runs before deployment — if one language suddenly drops (typical pattern: IT loses ground against DE and FR), that's a pre-production blocker, not a nice-to-have. We additionally recommend a quarterly sample review by native speakers, especially for FR and IT, to catch drift in tone and accuracy over time. Knowledge base updates should also trigger a small eval run, because a single changed FAQ entry can land differently per language.
This use case sits in the AI Engineering practice and connects to neighboring customer-operations and knowledge use cases.
Practice: LLM applications in production — multilingualism, RAG, evaluation, guardrails, platform choice with CH data residency.
RAG pipeline over company-owned content — indexing, retrieval, answer generation with source attribution and eval set.
Classify inbound, draft replies, CRM routing with approval queue — the sister pattern for mixed sales/support inboxes.
Multilingual support pays off when request volume per language is substantial (rule of thumb: over 20 requests per day in the rarest language) and a four-language team is uneconomical. For a one- or two-language setup with high specialisation, a well-rehearsed team model often remains better — and we'll tell you that honestly before we tie up your time. In a non-binding 30-minute discovery call we'll look at your language distribution and knowledge base.
Book a discovery call