In most of South Asia, the Gulf and large parts of Africa, customers do not write in one language. A single WhatsApp message might open in English, switch to Urdu for the part they feel more precisely, and finish with a Roman Urdu phrase. Then the next message is a voice note.
Any automation that assumes one language per customer will fail these conversations. Here is how to set one up that does not.
How language handling works
Modern language models are multilingual by default. They are not translating into English and back; they work with the message as written. That is why they handle mixed-language input better than older rule-based systems, which had to match keywords in a specific language.
You have two controls:
- Preferred customer language: the default the agent leans towards when a message is ambiguous or very short
- Follow-the-customer behaviour: the agent replies in whatever language the customer used
For most businesses, follow-the-customer with a sensible default is right. Forcing every reply into one language is the most common configuration mistake, and it makes customers who wrote in Urdu feel they have been handed to a different company.
Roman Urdu is its own case
Roman Urdu, meaning Urdu written in the Latin alphabet, is extremely common in WhatsApp and much messier than either English or Urdu script. There is no standard spelling. "Kitne ka hai", "kitny ka hai" and "kitnay ka h" are the same question, and your customers will produce all three plus variants you have not thought of.
Models handle this reasonably well, but you can help them considerably:
- Include common Roman Urdu phrasings in your knowledge base FAQ entries, alongside the English
- Add the Roman Urdu equivalents of your handover trigger phrases, or escalations will be missed
- Test with real messages copied from your own chat history, not phrases you invented
Where numbers, dates and prices get risky
Language mixing is mostly harmless in casual conversation and distinctly risky around specifics. Watch three areas:
Numbers and currency
Prices should be written one consistent way in your knowledge base, with the currency explicit. "Rs. 1,500" is unambiguous; "1500" is not, and "pandrah sau" in a customer message needs to resolve to the same figure. State currency in the knowledge base and test the agent quoting a price in each language.
Dates and times
"Kal" means tomorrow, and in some usage yesterday. "Parson" can mean the day after tomorrow or the day before yesterday. For bookings this ambiguity is expensive. The safe pattern is to have the agent restate the actual date when confirming: not "booked for kal" but "booked for Thursday 16 October at 2:30pm".
Politeness and register
Urdu carries formality distinctions that English does not. Set a tone that matches how your business actually speaks to customers, and read a few replies in each language before going live to check the register is right.
Voice notes across languages
Voice notes are where multilingual markets differ most from Western assumptions. Many customers prefer speaking, particularly older customers and anyone typing on a phone in a second script.
Incoming voice notes can be transcribed and answered like text, on plans where transcription is enabled. Accuracy varies with accent, background noise and how much the speaker code-switches mid-sentence. A busy shop with traffic noise behind the speaker is harder than a quiet room.
Two practical rules: keep a handover path for transcriptions that come out garbled, and have the agent confirm what it understood before acting on anything consequential, such as a booking or an order.
Testing a multilingual setup
Build a test list from your actual chat history, with at least five real messages per language, and run all of them:
- Your top question in English, Urdu script and Roman Urdu
- A message that switches language halfway through
- A price question in each language, checking the figure is identical each time
- A booking request using a relative date like "kal"
- A complaint phrase in each language, checking it triggers handover
- A voice note in each language
The price test is the one that catches the most problems. If the agent quotes Rs. 1,500 in English and something else in Urdu, your knowledge base needs clearer figures before you go anywhere near live.
Being honest about the limits
Multilingual replies are good, not perfect. Quality depends on the model you select, and it is generally stronger in English than in Urdu script, and stronger in both than in heavily abbreviated Roman Urdu. Regional vocabulary and local slang can trip it up.
That is an argument for clear handover rules rather than against multilingual support. A customer who gets a good answer in their own language most of the time, and a quick human when the agent struggles, is far better served than one who gets a polite English-only wall.
Language settings, tone and model selection all sit in Bot settings. See the full feature list, or book a demo and we will test your own customers' phrasings with you.
