One Multilingual Chatbot for English, Bahasa and Chinese

You do not need one chatbot per language. A single assistant with one shared knowledge base can reply in English, Bahasa or Chinese, following whichever language the customer used last, even when they switch mid-sentence. Product names, prices and policies stay in one place, and anything sensitive or uncertain goes to a person with the full transcript.

A common first attempt is one bot per language. It looks tidy on a diagram. It breaks the moment a customer writes half a sentence in English and finishes it in Bahasa, which in Singapore, Malaysia and Indonesia happens all the time.

Why one bot per language fails

Separate bots force a choice at the start of the conversation: pick your language. Real customers do not stay in one lane. A message like “Hi, nak tanya, the delivery for order 4471 sampai bila?” is perfectly normal. A language menu cannot route that.

Separate bots also create a maintenance problem. When a price changes, someone has to update three knowledge bases. Sooner or later one is missed, and customers get different answers depending on the language they wrote in. That is worse than no bot at all, because it damages trust in every answer.

Problems we see with duplicate bots

• Mixed-language messages get routed to the wrong bot or fail to match
• Prices, opening hours and policies drift out of sync between languages
• Reports are split three ways, so it is hard to see what customers actually ask
• Every improvement has to be made three times

One knowledge base, many languages

We keep a single source of answers and let the model reply in the language the customer used last. Product names, prices and policies stay in one place.

Modern language models handle English, Malay, Indonesian and Chinese well enough to answer from a knowledge base written in just one of them. The knowledge base is written in whichever language your team maintains most easily. The model translates at answer time.

What goes in the knowledge base

• Products and services, with official names and any common local nicknames
• Prices, fees and what they include
• Policies: delivery, returns, warranties, cancellations
• Opening hours, locations and contact routes
• Answers to the questions staff get asked most often, in their own words

Keep fixed terms fixed

Some words should never be translated. Product names, brand names, plan names and order codes need to appear exactly as they do on your invoices and website. We mark these terms in the knowledge base so the model keeps them as they are in every language. That way a customer who reads the answer in Chinese still recognises the product name on their receipt.

On an omnichannel retail project in Jakarta, AI generates product tags and descriptions in both Bahasa Indonesia and English from one product record. The same principle applies: one source of truth, many outputs.

How the assistant follows the customer

The rule is simple: reply in the language of the customer’s most recent message. If the message mixes languages, reply in the main one, and match the customer’s tone where it fits.

A few details make this feel natural:

1. Do not ask customers to pick a language. Detect it from what they write.
2. Switch when they switch. If the conversation moves from English to Bahasa, the next reply moves too.
3. Keep local terms. If customers say “lah” or use a local word for a product, the assistant should understand it, even if it replies more formally.
4. Match the script. Reply in Simplified or Traditional Chinese depending on what the customer used.

This is how our WhatsApp service assistant for a car dealer group in Johor Bahru works. Customers ask whether their car is ready, what the next service costs or whether a part is in stock, in English, Malay or Chinese and often all three in one message. One knowledge base of service packages, prices and branch hours answers every language, and the assistant books slots straight into each branch’s workshop calendar.

Where people still step in

An assistant is useful when it handles the repeated questions well and knows when to stop. These are the handover rules we set by default:

• Complaints and refunds go to staff with the full transcript
• Low-confidence answers are flagged, not guessed
• Staff replies are added back to the knowledge base

On the dealer project, that means a complaint about a repair goes to the service advisor for that branch, with everything the customer has written so far. Advisors handle the conversations that need a person, rather than the same “is my car ready?” question all day.

The goal is fewer repeated questions for staff, not zero staff.

Why the full transcript matters

Nothing frustrates a customer more than explaining their problem twice. When a conversation is handed over, staff see everything the customer has already said, in the original language, along with what the assistant replied. They can pick up from there.

Closing the loop

Every staff reply to a question the assistant could not answer is a candidate for the knowledge base. We make it easy for staff to mark a reply as “add this”, and a supervisor approves it. Over time the assistant answers more, and staff see fewer of the same questions.

Running on WhatsApp

In this region many customers prefer to message a business on WhatsApp. The assistant can run there through the official WhatsApp Business Platform. The platform has its own rules. For example, outside an open customer service window, messages a business starts need pre-approved templates. Those rules shape how reminders, follow-ups and order updates are designed, so we plan for them early rather than discovering them at launch.

If your sales team also works out of WhatsApp, the same conversations can sit next to the customer record and the deal. Our CRM keeps WhatsApp and email in one shared inbox, so a handed-over chat lands with the person who owns that account.

Personal data in conversations

Customers share names, phone numbers, addresses and order details in chat. Treat transcripts as personal data. Limit who can see them, decide how long to keep them, and mask personal details before transcripts are used to improve the assistant. Singapore’s Personal Data Protection Commission publishes guidance on what the PDPA requires, and Malaysia and Indonesia have their own data protection laws. Our data checklist for AI projects covers the questions to answer before you start.

A short checklist before building

1. List the 30 to 50 questions staff answer most often, with current answers
2. Decide which language the knowledge base will be maintained in
3. List the terms that must never be translated
4. Agree what always goes to staff: complaints, refunds, anything legal or medical
5. Name the person who approves new answers
6. Decide where the assistant will live: website, WhatsApp, or both

With this in hand, a first version can be built and tested with real conversations within a 4-week sprint. If you want to discuss your own case, get in touch.