Multilingual chatbot in an online shop: languages, glossary, limits

A customer writes in the chat of a small online shop on a Tuesday evening: “Mijn pakket is nog niet aangekomen, kan ik het retourneren?” The shop sells household goods, ships from Germany to several EU countries and is run by three people. Nobody on the team speaks Dutch. The customer will not wait until Monday; she orders from the next provider.

In this scenario, support has so far run via a contact form and a mailbox. Replies arrive the next working day, mostly in German or in an English that the other side reads out of necessity. The questions repeat: where is my parcel, how long does shipping to Austria take, how do I send it back, who pays the postage, which size fits. A large part of the day goes on answers that differ only in language.

A multilingual chatbot seems the obvious answer. The real question is what it must be able to do so that it helps instead of creating new problems. A bot that chats fluently while quoting a wrong return deadline is worse than none, because the customer will later rely on that statement. This study walks through the path we would choose and names where it ends.

Modern language models understand dozens of languages and answer in the language of the inquiry. That tempts people to assume that multilingual is a switch. In practice the problems lie not in grammar but in content that can mean something different in each language: deadlines, costs, countries, product terms.

A typical failure: the bot freely translates “Rückgaberecht” and names a deadline in its answer that is not in the shop's terms, because the model adds it from general knowledge. A second: a product name that is an everyday word in one language gets translated too, and the customer searches in vain for the item. A third: the language is misdetected from a single word, and the answer comes in Spanish although the message was written in Portuguese.

Then there are questions where an answer is binding not only linguistically but also in substance. Anyone who wants to know whether an order has already shipped needs real data, not a guess. Anyone arguing about a refund needs not a friendly phrasing but a person with authority to decide. A bot that answers everything seems competent until it matters.

Finally an organisational problem arises: who actually checks the answers in Dutch, Polish or Italian? Nobody on the team can. Without a process for it, every statement about quality remains hope.

Add to that customers' expectations. Someone addressed in their own language perceives the answer as binding, even if it was produced by a machine. A notice that a bot is answering is therefore not only a matter of transparency but also lowers the risk that an offhand phrase is read as a commitment. A shop selling in several countries carries this responsibility equally in every language.

Before choosing a technology, we sort the questions that land in the chat by the harm a wrong answer would cause. A question about opening hours or care instructions tolerates a small inaccuracy. A stated return deadline, a promised delivery date or a statement about customs duties does not, because customers base decisions on them.

This sorting determines how strictly an area is treated. For uncritical information the bot may phrase freely from the knowledge base. For shipping and return rules it may only repeat what is written there and must cite the source. For legal texts it outputs only the approved wording and points to it. For order data it answers only after verifying identity and from the shop system, never from the model's memory.

A look at the languages themselves also helps. Instead of maximising the number of “supported languages”, we ask which countries orders and inquiries actually come from. For a small shop that might be German, English, Dutch and French. Every additional language is a separate quality task, not a tick box. The shop's order and support data show which languages are worth the effort.

There are two basic patterns. In the first, there is a single knowledge base in German. The question is translated, answered, and the answer translated back. This is quick to set up and easy to maintain, since one text suffices. The price is translation errors at both points, and with follow-up questions the system easily loses the thread because nuances are shifted twice.

In the second pattern, the knowledge base exists in every supported language as an editorially reviewed version. The bot searches in the customer's language and answers from her text. The effort is greater because every change must be carried through in all languages. In return, what exactly applies can be fixed per language, and a native speaker can review it once instead of every answer individually.

We would combine both, tiered by risk. For core languages with notable inquiry volume, reviewed versions of the shipping, returns and payment information are created. For minor languages, runtime translation of the uncritical information is enough, supplemented by a clear notice that the answer is machine-translated and by the option to switch quickly to English or German.

An example shows the difference. If a customer asks in French about returning an item, the bot finds the steps, the return route and the note on the conditions in the French version. With pure runtime translation the answer would be built from the German text, and a word like “Rückerstattung” could appear as a credit note or as a money refund depending on the sentence. For the customer that is a considerable difference.

What matters is the procedure under uncertainty. If the bot finds no suitable passage in the knowledge base, it does not guess but says so openly and offers the handover. That sounds self-evident, but it is the trait that separates usable bots from unusable ones.

The conversation flow follows a fixed order. First the bot detects the language of the first message but confirms it in one sentence (“I'll reply in Dutch, would you like to switch?”) rather than silently assuming it. Short messages such as “ok” or a product name are too thin for language detection, so the last confirmed language applies until the customer chooses otherwise.

Next, the bot classifies the intent: information, order question, return, complaint or something it does not understand. It answers information requests from the knowledge base of the respective language and shows the source. Order questions it routes into a secured flow in which it asks for the order number and a second detail. It guides returns step by step without deciding on goodwill or exceptions.

Complaints, refund disputes, suspected damage and anything that turns emotional go straight to a person. The ticket contains the language, the conversation so far, a summary in German and the customer's original. Whoever on the team replies can then work with a translator without reopening the conversation. The customer is told openly what happens next and within what period a reply is realistic.

Technically, the bot consists of several layers that stay testable independently of one another. At the top is the chat interface on the shop page. Below it lies the controller, which detects language and intent and decides which source is responsible. The language model phrases, but it does not decide what applies. This separation is the most important safety feature, because it prevents free phrasing from becoming free statements.

The glossary is unassuming but effective. It contains product names that are never translated, technical terms with the approved equivalent per language, and words the shop deliberately avoids. If it is supplied before every answer and checked after every answer, many own goals disappear, for example when an item designation turns into an everyday word. It can be maintained by the person who knows the range, not by a developer.

Legal texts such as the right-of-withdrawal notice, shipping terms or privacy notices we treat as quotations, not as conversation material. The bot outputs the approved version in the respective language verbatim and links to it. If there is no reviewed translation, it points to the German version and says so. It does not explain the text freely, because a “more understandable” paraphrase can promise something different from the original. Whether a translation is legally sufficient is, in case of doubt, something the shop operator clarifies with a qualified body.

For order status the bot needs a connection to the shop system that works read-only and only for the individual order. The lookup runs through a server-side interface with narrowly scoped permissions. The bot receives only the fields needed for the answer, namely status, carrier and tracking number, not the complete customer file. Access is logged.

The special cases show whether a concept holds up. The first is mixed language: someone who writes in German but inserts an English product name and a French place name confuses any automatic detection. It helps to determine the language over several messages and, when in doubt, to ask politely instead of guessing. Dialect, colloquial speech and typos also require intents to be recognised robustly and the bot to ask an understandable follow-up question.

The second case concerns order status. Someone types in an order number they have seen somewhere and wants details of someone else's order. That is why the bot asks for a second detail that only the person who ordered knows, such as the email address of the order, and gives no hint on failed attempts as to which of the two details was wrong. The chat generally does not output sensitive details such as complete addresses or payment data.

Third, questions about countries and prices: shipping costs, customs, delivery times and taxes differ by destination country. The bot answers them only for countries that are in the knowledge base and honestly says it does not know for all others. This also applies to currencies. A conversion from the model's memory is not a price quote.

Another case lies in characters and forms of address. Special characters, accents or other scripts must arrive unchanged in the chat, the ticket and the notifications, otherwise the team reads illegible text in the mailbox. Forms of politeness also differ: a form of address that seems natural in German can sound too familiar or too stiff in another language. The glossary should therefore also fix forms of address and greetings per language.

The fourth case is the complaint in a sharp tone. Translation does not help here, speed and responsibility do. The bot recognises trigger words and repetitions, stays neutral and hands over immediately. It does not try to turn the mood with polite phrases, because that comes across as condescending in every language.

A multilingual chatbot takes the always-identical standard questions off the team and makes the shop reachable outside office hours, in the customer's language. That is a realistic benefit. How large it turns out depends on the range, the quality of the knowledge base and the share of standard questions. We do not promise a rate of conversations a bot “solves”, because it is one of the numbers that can only be measured in your own business.

Measurement falls into three groups. First, coverage: how many conversations ended without handover, and how many of those had no follow-up message by email? Second, quality: how many answers in the sample were factually correct, linguistically understandable and backed by the right source, split by language? Third, relief: how many tickets per week still arrive in the mailbox, and how long does the first reply by humans take?

Plan for a ramp-up period. In the first weeks, gaps in the knowledge base stand out above all, and they only show up through real conversations. Only then can you judge whether the bot really provides relief. If after an observation period of a few weeks it turns out that most questions are special cases anyway, that is a legitimate result: then a better help centre is worth more than a bot.

An honest balance sheet also includes what does not get better. The bot replaces no negotiation, no goodwill decision and no expert advice. It does not prevent customers from being dissatisfied when the product or delivery disappoints. It can only ensure that they reach a correct answer or a person faster.

The most important lesson is not to manage quality as an overall impression. “The bot works well” says little if nobody knows in which language. That is why we set up a small, fixed test catalogue per language: about twenty typical questions, including trick questions about deadlines, unknown countries and other people's orders. With every change to the knowledge base, glossary or model, the catalogue runs again and deviations are compared.

The catalogue alone is not enough. In addition, a person with language skills regularly reads a sample of real conversations, ideally the same person over a longer period. If nobody in the shop's circle can do it, an external language service can take on this task by the hour. What matters is that it is firmly scheduled and not done only when someone complains.

Upkeep is part of it too. If shipping partners, deadlines or prices change, the change must reach every language, otherwise website and bot contradict each other. A simple process makes sense: one source in German, from it the versions per language, each with date and person responsible. And if a language cannot be maintained, it is switched off instead of running on in last year's state.

On data protection, only orientation is given here, without legal advice: customers should recognise that they are talking to a bot, conversations should not be stored longer than necessary, and which data reaches the language model must be deliberately defined. The shop clarifies the details with its data protection adviser.

A multilingual chatbot is worthwhile for a shop that regularly ships to several countries and receives many similar questions. It works when it answers only what is in verified sources, reproduces legal texts unchanged, retrieves order data through a secured integration and hands over to people early. It does not work as a translation machine that covers every gap with fluent wording.

The next step is small. Go through your inbox for the last few months and count which languages inquiries came in and which ten questions come back most often. With that list you can tell which languages are worthwhile and which content belongs in the knowledge base first. We are happy to review it together and will tell you honestly if a better help center would bring more at first than a bot.

Three insights go the furthest. First: the language model phrases, the source decides. Second: fewer languages that are verified beat many languages of unknown quality. Third: handover to people is part of the concept, not an admission of failure. A shop that sticks to these three points can add languages later without risking customers' trust.

To put the effort into perspective: the larger part lies not in the bot but in the texts, the glossary and the ongoing review. This can be estimated after analyzing the inquiries, not before.