If Your Voice Agent Asks the Caller to Pick a Language, You Have Built an IVR

A voice agent that opens with “for Hindi, press 1” has reinvented the thing the caller was hoping to escape. It is an IVR with a nicer voice, and the caller can tell within two seconds.

The menu is not a design choice. It is what a system does when it cannot handle the language question any other way — and on an Indian phone line, it cannot handle it that way at all, because the premise is wrong.

A language menu assumes each call is conducted in exactly one language, chosen at the start and held to the end. That is a reasonable model of a phone call in Frankfurt. It is not a description of one in Bangalore.

Real Indian phone speech mixes languages inside a single sentence. Not between sentences, and not because the speaker lacks vocabulary — because that is the register. The verb is Tamil and the noun is English. The sentence is Hindi and the order number is English. The greeting is Kannada and the complaint that follows is in whichever language the caller thinks in when annoyed.

Hinglish and Tanglish are not degraded Hindi and Tamil. They are what fluent speakers speak, and a system that treats them as an error state is wrong about its own users.

Three costs, in the order a caller meets them:

• It spends the first ten seconds on admin. Those seconds are where a caller decides whether this is a person, a competent machine, or a wall.
• It asks a question with no right answer. A caller who will use both Kannada and English has to pick one, and is then wrong for half the call.
• It locks the answer in. The worst part. Having chosen Hindi, the caller switches to English to read out an order number — as everyone does, because numbers and product names live in English — and a system pinned to Hindi mistranscribes exactly the field the call was about.

That last one is the expensive failure, because it is invisible. The transcript reads fluently. The order number is wrong. Nothing alerts anybody.

The language cannot be a setting captured at the start. It has to be something the system tracks continuously, because the caller changes it without announcement and without noticing.

That means, concretely:

• Speech models trained on code-mixed audio, not a monolingual model per language with a router in front. A router has to decide, and deciding is the part that fails.
• The embedded English handled as carefully as the Indian language. Indian English is its own variety — lakh and crore, digits read in pairs, place names a US-trained model has never heard — and it carries the payload of most business calls.
• No language state to get stuck in. If there is a mode, there is a wrong mode.

Not laziness — architecture. If your speech stack is a general multilingual model with a language parameter, you need to know the language before you can transcribe. The menu is the cheapest way to obtain it. Everything downstream then inherits the assumption, and by the time anyone notices, the menu is load-bearing.

Which is why “do you support Tamil?” is a weak question — nearly everyone says yes. The question that separates vendors is “what happens when the caller switches language mid-sentence?” The answers divide cleanly into a description of what the model does, and a description of what the menu does.

Call the agent. Open in Tamil or Hindi. Halfway through a sentence, switch to English to read out a number, then switch back. That is not an adversarial test — it is a Tuesday.

Watch for two things: whether it keeps up, and whether the number in the transcript is right. A system can survive the first and fail the second, and the second is the one that costs money.

Ours is on a page per language, each naming what is genuinely hard about that language rather than listing it as supported — and there is a live number on the home page if you would rather test it than read about it.