Why voice AI built for English struggles on Indian calls

Two problems, both measurable

Voice AI platforms built for English-speaking markets often perform poorly on Indian phone calls, and the reasons are less mysterious than they look. There are two, they compound, and both can be measured rather than argued about.

Problem one: the servers are somewhere else

A voice call is a loop. Audio goes to a server, an answer comes back, and the loop runs again on every turn. If those servers sit on another continent, the network round trip is paid every time, before any useful work has begun.

On our own systems the difference is stark. Reaching speech recognition from our Mumbai deployment takes about 20 ms. Reaching the same models hosted in the United States takes about 300 ms.

That is a network measurement, not a benchmark. There is no clever engineering that recovers it, and it is spent on every turn of a call: three turns into a conversation you have already given away most of a second to geography alone. The old telephony guidance in ITU-T G.114 is a reminder of how little delay a conversation tolerates before people start behaving as though the line has dropped.

The uncomfortable part for a buyer is that this is invisible in a demo run over a good office connection, and painfully visible on a customer’s mobile.

Problem two: your customers use two languages at once

Not one language per caller. Two languages per sentence:

Mera order abhi tak deliver nahi hua, tracking mein “out for delivery” dikha raha hai since Tuesday.

Most platforms model language as a setting: pick one per agent or per call. That model is correct in a market where each caller speaks one language and wrong in a market where they do not. Whichever value you pick, it is wrong for part of every call.

The visible damage is a bad transcript. The expensive damage is in timing.

Where the timing goes wrong

A voice agent decides that a caller has finished speaking by watching for a pause. Set the threshold short and it cuts people off mid-thought. Set it long and every turn carries dead air, which is the thing callers notice. The three ways that decision goes wrong on a real line are in why a voice AI agent interrupts callers.

Measured against a labelled set of real calls, that threshold is not one number. English speakers want a noticeably shorter pause than Hindi speakers do, and speech that moves between the two behaves like neither. A single value tuned on English cuts Hindi speakers off. Stretched to suit Hindi, it makes every English call feel slow.

So the system needs the threshold set per language, tuned against recordings of the calls it will take. That is not a feature to buy; it is measurement work somebody has to have done. The mechanics are set out in callers who mix Hindi and English.

The third thing, which is not technical

Background noise. An Indian mobile call usually has traffic, a television, or another conversation in it. A system tuned for a quiet room stops mid-word every time a bus passes, which is the opposite failure from an agent that cannot be interrupted at all. Both failure modes, and how to test for each in a demo, are in barge-in.

What to ask for

• Where is each part of the call served from? Speech, reasoning and voice separately. “Our cloud has a region in India” answers none of the three.
• Show me one sentence with two languages in it, and give me the transcript.
• Is the pause threshold the same for every language? If the answer is one number, the system was tuned on one language.
• Take the demo somewhere noisy.

If those four answers hold up, the rest of the evaluation is about your business rather than about the technology. The fuller list is in nine questions to ask a voice AI vendor.

There is now a fifth question that has nothing to do with latency or language: whether AI calling is legal in India the way your vendor is running it. As of 18 September 2026 it is a paperwork question with a real consequence, not a technical one.