Urdu, Roman Urdu, and what a system can honestly handle

The short answer, split by what you are asking it to do

Current language models understand conversational Urdu and Roman Urdu well enough to work out what a customer wants and to draft a reply that reads naturally. They are markedly less reliable when asked to pull exact values out of that message: names, addresses, quantities, dates and prices. So the rule that holds in production is to use the model for understanding and drafting, never for keyword matching, and to have the customer confirm any field that will be written into a record.

That split is the whole design. Understanding is forgiving, because being roughly right about intent still routes the conversation correctly. Extraction is unforgiving, because being roughly right about a quantity means the wrong thing gets dispatched. Systems that treat both as one capability are the ones that demonstrate beautifully and cause arguments in month two.

Roman Urdu has no fixed spelling, so keyword matching fails

Roman Urdu is Urdu written in the Latin alphabet, and there is no standard for it. Each person spells by ear, so the same word arrives in a handful of forms from a handful of customers, and sometimes in two forms from one customer in a single thread. Vowels get dropped or doubled. Sounds that need two letters in English get written several ways.

That kills a common design. A system built on a list of trigger words will match some of your customers and quietly ignore the rest, and the ones it ignores do not complain, they simply go elsewhere. The failure leaves no evidence either: nothing in the logs says a message was missed, because from the system's point of view nothing arrived that matched.

Matching on meaning works better, either with a model asked to classify the intent or with an embedding comparison against real examples. Both carry the same caveat. They are trained overwhelmingly on English, and their handling of Roman Urdu is weaker than their handling of English, so better than keyword lists is not the same as reliable.

• The same word spelled several ways by different customers, and sometimes by one
• Vowels dropped or doubled, and sounds written by ear rather than by rule
• Words joined together, split apart, or corrected into unrelated English words
• Urdu script and Roman Urdu arriving in one conversation from the same person
• Trigger word lists that fail silently, leaving nothing in the log to notice

Code switching in text, and in ninety seconds of audio

Mixing English and Urdu inside one sentence is the normal way people write and speak here, not an edge case to be handled later. A single message carries an English product name, Urdu grammar around it, an English numeral, and a closing line in Roman Urdu. Any design that begins by detecting the language of a message and routing on the result starts from a question that has no single correct answer.

Two things follow. Do not route by detected language: handle the mixture directly, and decide separately what language your replies go out in, which is a business choice rather than a technical one. And do not force customers into one script. Some type in Urdu script from the phone keyboard, some in Roman, and plenty switch depending on which phone they are holding.

Then there is audio, which is how a great deal of it arrives. Transcribing a voice note that moves between languages inside single sentences is genuinely hard, and quality varies with the speaker, the background noise and how fast they talk. The weakest points are consistent: proper nouns, place names, brand names and numbers, which are the parts you needed. So the transcript is a draft, and it becomes a record only when the customer has been shown a short summary and confirmed it.

Numbers, dates and the fields that have to be exact

Quantities and times in everyday Urdu use forms that have no single English equivalent. There are dedicated words for one and a half and two and a half, and constructions for quarter past and quarter to that attach to the hour rather than being spoken as minutes. A system trained mostly on English handles those unevenly, and when it guesses it produces a plausible number rather than an error.

Dates are worse, because several conventions run at once. A numeric date can be written day first or month first with nothing to say which. Relative expressions do a lot of the work in conversation, and at least one common word covers both the day before yesterday and the day after tomorrow, with only the surrounding sentence to settle it.

Religious and seasonal references anchor delivery dates without a number being said at all. And business here talks in lakh and crore, so a conversion can land one decimal place out while still looking entirely normal.

One rule follows, and it should be non negotiable in the design. No model output writes a number, a date, an address or a name into a system of record without being shown back and confirmed. Put it in the customer's own thread, in the same layout every time, and ask for a one word reply. It costs one message and removes the whole category of expensive error.

The dangerous failure is never a crash. It is a plausible number, written confidently into a record nobody re-reads.

How to test it before you let it talk to customers

Build the test set from real traffic, not from a supplier's demonstration. Take a few hundred genuine recent messages from your own threads, chosen at random rather than picked, and include the voice notes. Do not write test messages yourself, because invented examples are always cleaner and better spelled than the real thing. For each one, write down what the correct outcome would have been: which intent, which fields, which reply.

Then measure by outcome rather than by impression, keeping two categories apart. Cases where the system asked a clarifying question are a good outcome. Cases where it produced a confident wrong answer are the ones that cost money, and a system that asks more and guesses less is usually the better purchase.

Hold part of the set back from whoever is tuning the system, and rerun everything after any change to the model, the prompt or the workflow, since those get edited casually by people who do not think of them as code.

• A few hundred real messages taken at random from your own threads, voice notes included
• A written correct answer for each, decided by someone who knows the business
• Separate counts for clarifying questions and for confident wrong answers
• A held back portion nobody tunes against, rerun after every change
• New failures added to the set each month rather than fixed and forgotten

What language handling still cannot do

It cannot be trusted with a payment. An amount read from a screenshot or heard in a voice note is a reading, and readings are sometimes wrong. Confirmation belongs against the bank, and a system that quietly removes that check has automated a control away rather than a task.

It cannot handle the other languages of this country at the same quality. Punjabi, Sindhi, Pashto and Balochi appear in real conversations, in speech more often than in text, and support for them is weaker again. If a meaningful share of your customers speak to you in one of those, test it specifically rather than assuming it arrives alongside Urdu.

It cannot read register the way a person does. Whether a customer is being polite or annoyed, whether a phrase is a joke, and the moment a complaint stops being about the product. Those judgements are what customers remember, which is why prices, complaints and promises belong in front of a person rather than behind one.

And no accuracy number quoted in any proposal counts until it has been produced on your data. Ask to see the failures rather than the score.

Building the test set, and where the system has to stop

The test set is the part to do in-house and the part that decides everything else. A few hundred genuine recent messages from your own threads, chosen at random rather than picked, with the right answer written beside each one by somebody who knows the business. Your own team can assemble that in an afternoon and no supplier can produce it, because they do not have your traffic. It is also the only asset in this article that keeps its value when the models underneath change.

The audit takes the first week and most of it goes on that test set and on the vocabulary: product names, area names, the local word for the thing, and the spellings your customers actually use rather than the correct ones. One assistant is live inside a fortnight, and it is deliberately narrow, because a system handling four intents well is worth more than one handling twelve unreliably across two scripts.

The stop is the same as the limitation. An amount read from a screenshot or heard in a voice note is a reading, so it is read back and confirmed, and anything that changes a record, a booking or a sum waits for human approval. Two failed attempts to understand somebody hands it to a person rather than asking a third time, because a customer switching script mid-sentence is ordinary and being asked to repeat is not. Where the system cannot tell what was meant, saying so is better than a fluent guess.

The test set, the vocabulary list and the conversation history sit in accounts under your own logins, so you own the system and the measurement, and a change of supplier does not restart the evaluation. The published work is the operating kind rather than the demonstrating kind: Culligan Pakistan through East River, and Emraan Rajput, a Pakistani fashion business running creative, Shopify operations and callers inside one system. Moiz Khan owns automation architecture at Wobble, which works from Karachi, bills month to month, across 25 engagements in six countries.

Common questions

Can AI understand Roman Urdu?

It can usually work out what a customer means and draft a sensible reply, because understanding tolerates approximation. It is much weaker at pulling exact values out of the message. Roman Urdu has no standard spelling, so any system built on trigger word lists will silently miss part of your customers.

Why does keyword matching fail for Roman Urdu?

Because people spell by ear. Vowels get dropped or doubled, sounds get written several ways, and English autocorrect rewrites some words entirely. A trigger word list matches some spellings and ignores the rest, and it fails invisibly, since nothing is logged when no match occurs.

How does a system handle messages that mix English and Urdu?

By treating the mixture as normal rather than detecting one language and routing on it. Whole message language detection returns a single label for something that has two, so the result is wrong by design. Handle the mixture directly and treat the reply language as a business decision.

Can AI transcribe Urdu voice notes accurately enough to use?

It produces a usable draft. Quality varies with the speaker, background noise and speed, and the weakest points are proper nouns, place names and numbers. Send a short structured summary back and ask for a one word confirmation before treating it as an order.

What about numbers and dates in Urdu?

They are the most common source of expensive errors. Everyday speech uses dedicated words for fractions and quarter hours, numeric dates carry no marker for day or month order, and one common relative word covers two days in opposite directions. Never let a model write one into a record unconfirmed.

How do we test whether a system handles our customers' language?

Take a few hundred real recent messages from your own threads at random, including voice notes, write down the correct outcome for each, and measure. Count clarifying questions and confident wrong answers separately, and keep part of the set back so it can be rerun honestly later.