When customers type Roman Urdu, Hinglish or mixed Arabic

Code-switching is a customer writing one message in two languages — or in one language using another's alphabet — and it is the normal case in Pakistan, India, the Gulf and much of South-East Asia rather than an edge case. "bhai kitna price hai" is a price question containing one English word and no Urdu script.

Most advice on multilingual bots is about translation: publish your flow in two languages, let the customer choose. That solves a problem your customers do not have. They are not asking for Urdu; they are typing Urdu in Roman letters, and your keyword list does not contain it.

The three separate problems

Problem	Example	What actually fixes it
Transliteration	"kitna" instead of کتنا	More keyword variants
Code-switching	"delivery kab ayegi"	Match on either half
Genuine second language	A message entirely in Arabic script	Separate flow or a knowledge base

The first two are the common ones and both are fixable with the tools you already have, because keyword matching is plain text and does not care which alphabet you typed.

There is no correct spelling, so add several

Transliteration has no standard. The same word appears as "kitna", "kitne", "kitnay" and "kitna hai" from four different customers, and each is a different string to a keyword match. One spelling catches a quarter of the people who meant it.

Intent	English	Roman Urdu / Hindi to add
Price	price, how much, cost, rate	kitna, kitne, kitnay, qeemat, keemat, rate kya
Order status	where is my order, tracking	kab ayega, kab tak, kidhar hai, order kahan
Availability	in stock, available	available hai, stock hai, mil jayega, hai kya
Yes / confirm	yes, confirm, ok	haan, han, ji, ji haan, theek hai, sahi
No / cancel	no, cancel	nahi, nahin, cancel karo, rehne do

That fourth row matters more than it looks. If a confirmation flow only accepts "yes", every customer who types "ji" is invisible to it — and in cash-on-delivery markets that is a shipped parcel nobody confirmed.

Buttons sidestep the problem entirely

The most reliable multilingual technique is not matching text at all. A question with buttons produces a tap, and a tap is the same regardless of what language the customer thinks in.

So in mixed-language markets, lean harder on Ask Customer a Question with buttons or lists, and use free text only where you genuinely need it — an order number, an address. Label the buttons in whichever language your customers read most comfortably, or in both: "Confirm karein / Confirm" fits.

There is a second benefit. A tap opens the 24-hour window, making everything afterwards free — so the accessible design is also the cheap one.

Where the knowledge base helps

Keyword lists have a ceiling. Once you are maintaining eighty phrases for one intent across two scripts, you have outgrown them.

The Answer from Knowledge Base step matches on meaning rather than characters, so it handles phrasings you never anticipated — including transliterated ones — as long as the answer exists in your material. Put specific keyword flows above it for the intents that need a specific outcome, and let it catch the long tail underneath.

Which language should the bot reply in?

Three workable answers, in order of how well they hold up:

1. Reply in the language you sell in, warmly. Most customers writing Roman Urdu read English fine — they are typing in the way that is fastest on their keyboard, not asking to be answered in Urdu.
2. Ask once, then remember. A first-message question offering "English / اردو", saved to a contact field, and branch on it thereafter. Costs one extra step per flow.
3. Write bilingually in the same message. Effective for short transactional messages, clumsy for anything longer.

What does not work is guessing per message. A bot that switches language based on what it thinks it detected feels erratic, and it will be wrong on exactly the mixed-script messages that are most common.

Templates and language

Templates are approved per language, so a genuinely bilingual store needs each one submitted twice. That has a cost you should plan for: Meta caps templates at 250 per account for an unverified business portfolio, and 6,000 once verified, per its template documentation. Doubling every template halves your headroom.

Right-to-left languages add a practical wrinkle: check how the approved template renders on a real phone before you rely on it, particularly where a variable sits next to punctuation.

What to do first

1. Search your inbox for the ten phrasings customers actually use for your top intent.
2. Add every spelling variant to that keyword list.
3. Make sure your confirmation flows accept "haan", "ji" and "theek hai" as well as "yes".
4. Convert your busiest free-text question into buttons.
5. Put a knowledge base underneath as the catch-all.

Step three alone is often worth more than everything else on this page, because it turns silently-lost confirmations into confirmed orders.

Why the usual advice does not fit

Most guidance on multilingual bots assumes the customer picks a language and stays in it. That describes a European market reasonably well and describes Pakistan, India or the Gulf hardly at all, where a single message routinely mixes scripts and languages within one sentence.

Assumption	Reality in these markets
Customers write in one language	They mix, mid-sentence
Translating your flow solves it	The input is transliterated, not translated
A language picker fixes routing	Most people ignore it and type anyway
Spelling is consistent	There is no standard for Roman-script Urdu or Hindi

So the work is not translation. It is making your matching tolerant of input your flow was never designed to see.

Where each tool fits

1. Buttons and lists — best. A tap carries no language at all, so it works for every customer regardless of script. Use them wherever the answer is a choice.
2. Keyword conditions — good for a handful of high-value intents, provided you load several spellings per phrase.
3. Knowledge base — best for the long tail, because it matches meaning rather than characters and does not care which alphabet was used.
4. Free-text questions — use only where you genuinely need typed input, like an order number or an address.

The ordering matters: specific keyword flows above, knowledge base underneath as the catch-all with no keyword condition of its own. That way a message you never anticipated still gets a sensible answer instead of silence. AI answers from your own website covers building it.

Cost and the window, in these markets specifically

Everything above is free to run. These flows start because a customer messaged you, which opens the 24-hour service window, and Meta's pricing documentation confirms service conversations have been free and unlimited since 1 November 2024.

That matters more here than elsewhere. Merchants in cash-on-delivery markets are price-sensitive and often arrive expecting per-message costs to make automation uneconomic. The transactional and support half genuinely is free; it is only outbound marketing templates that are charged.

A first pass you can do this afternoon

1. Open your inbox and read the last fifty customer messages.
2. Write down every phrasing used for your top three intents, exactly as typed.
3. Add all of them to the relevant keyword lists, including every spelling variant.
4. Check your confirmation flow accepts "haan", "han", "ji", "ok" and "theek hai" as well as "yes".
5. Convert your busiest free-text question into buttons.

Step four is the one with money attached. In a cash-on-delivery flow, a confirmation the system does not recognise is a parcel that either ships unconfirmed or gets chased by a human — and both cost more than the twenty minutes this takes.

What not to bother with

• Auto-detecting language per message. A bot that switches based on what it thinks it detected feels erratic, and it will be wrong on exactly the mixed-script messages that are most common.
• Machine-translating your whole flow. Your customers are not asking for translation; they are typing their own language in Roman letters and reading your English fine.
• A language picker as the first message. Most people ignore it and type anyway, and you have spent your opening message on a question nobody wanted.

Spend the effort on keyword coverage and buttons instead. Both are cheap, both work today, and between them they handle the overwhelming majority of real messages.

Ask your team, not a translation tool

Whoever answers your inbox already knows how customers phrase things, because they read it every day. Twenty minutes with them produces a better keyword list than any published one, including ours — and they will spot the phrasings that mean something different locally.

None of this is a translation project. It is twenty minutes of reading real messages and adding what you find, repeated whenever your customers' wording drifts.

Do it once this month, then again next quarter, and the lists stay useful.