When we launched AIVA Voice in early 2024, every onboarding call asked for the same thing first: "Does it work in English?" Of course it does. So does every other AI product. The interesting question — the one nobody asked — was whether it would work in Hindi. Or Marathi. Or Tamil. We started building for those answers anyway, six months before our first customer asked.
That decision turned out to be the most important one we made in our first year. By the time customers did start asking — and they did, around month nine — we had Hindi shipping in production, Marathi in beta, and Tamil two weeks out.
Today we ship voice in twelve Indian languages with native scripts, code-switching, and regional accent recognition. We're the only AI customer-support platform that does.
This post is about why we did it that way. Some of it is engineering. Some of it is sitting in a Rajkot office and listening to people. Most of it is the gap between what customers say they want and what they actually need.
The feedback trap
If you ask any B2B customer in India what language they want their support tool to speak, they'll say English. Every single time. The buyer is in English. The company website is in English. The internal Slack is in English. Their procurement form is in English. Their existing CRM is in English. Of course they'll say English.
But the buyer isn't the user. The buyer is a clinic manager or a salon owner who communicates in English internally. The user is the patient calling to book an appointment, or the customer asking about availability.
That person — the one whose problem AIVA actually solves — speaks Hindi 70% of the time. Or Marathi. Or Tamil. Or Bengali.
We learned this the hard way. Our first three pilot customers — a clinic, a coaching centre, and a service business — ran AIVA in English-only for two weeks. The results were embarrassing. Customers were hanging up within ten seconds.
Our voice agent was perfectly fluent, but it sounded like reading a press release at people who wanted to be talked to in their own language.
The buyer is in English. The user almost never is. Build for the user.
The twelve languages
So we picked twelve. Not because twelve is a magic number — because that's the set that covers roughly 85% of Indian inbound calls across our customer base.
We picked from call distribution rather than from the Census of India's list of scheduled languages, and the two don't rank the same way. Hindi is obvious. Marathi for Mumbai/Pune clinics and businesses. Tamil for Chennai. Gujarati for our home turf.
Bengali for the eastern belt. Telugu and Kannada for the south. Malayalam for Kerala healthcare. Punjabi for the north. Odia and Assamese for the east. And Urdu, which surprised us — it turned out to matter a lot for businesses serving customers in Hyderabad.
Why we didn't just translate
The cheap way to do "multilingual AI" is to take your English model and stick a translation layer in front and behind it. The customer speaks Hindi → translate to English → run the model → translate back to Hindi → text-to-speech. This is what most "AI for India" tools do. It's a bad experience for everyone.
Translation layers introduce 200–400ms of additional latency. They lose context — Hindi has politeness markers and pronouns that don't survive a round-trip translation. They miss code-switching entirely. And they make every interaction sound like reading a manual.
Instead, we trained on native conversational data in each language. The model thinks in Hindi when speaking Hindi. It picks up on regional cues — "ji" suffix in formal contexts, code-switching with English brand names, the rhythm of Marathi phone conversations vs. written Marathi.
It works because we treated each language as a first-class citizen, not as English with a costume. The side-by-side comparison is in regional language AI vs translation.
This only became affordable because of the 2.0 rebuild. In the original architecture, adding a language meant negotiating coverage across three vendors who each supported a different subset. Owning the pipeline turned it into a config file and a model checkpoint — six weeks of work became under two.
If you remember one thing from this post: "multilingual" via translation layer and "multilingual" via native models are completely different products. Customers can hear the difference within the first three seconds of a call.
What changed when we shipped
The week we launched Hindi voice in production, our pilot customer's CSAT jumped from 3.4 to 4.6. That's the largest single-week movement we've ever seen on any metric.
Not because the underlying model got better — it was the same model — but because customers stopped having to translate themselves into a foreign language to get help.
The other thing that changed: call volumes went up. This was counterintuitive at first. We'd assumed that better support meant fewer escalations meant fewer calls. The opposite happened.
Customers who had been silently fuming or churning suddenly had a path to resolution they were willing to take. Our customer's overall support volume increased ~20% in the first month — and their per-call resolution rate went from 41% to 96%.
The code-switching surprise
Here's something we didn't expect: most Indian customers don't speak in pure Hindi or pure Marathi or pure Tamil. They speak in code-switched mixes — "Hinglish" being the most famous, but every regional language has its own version. A customer might say:
"Hi yaar, kal ke liye appointment available hai kya? Morning mein chahiye bhai, around 11 baje. Can you check?"
The pure-Hindi-or-pure-English approach fails on this. Translation layers fail catastrophically. Models trained natively on conversational Indian data — including code-switching — handle it fine. AIVA's response: reply in code-switched Hinglish that matches the customer's register.
Not because we instruct it to, but because that's what the training data looks like. We've gone deeper on the mechanics in Hinglish code-switching in voice AI.
Accent is a separate problem from language
The mistake we nearly made was assuming that shipping Tamil solved Tamil. It doesn't. A caller from Coimbatore and a caller from Chennai speak the same language and don't sound the same, and a model tuned on one will quietly underperform on the other.
Worse, accent variation shows up most in English — a Malayali speaker's English, a Punjabi speaker's English, and a Bengali speaker's English diverge more than the textbooks suggest.
An "English-only" agent isn't solving one recognition problem; it's solving a dozen it hasn't been told about. That's the real reason English-first deployments failed for our pilot customers even with callers who were comfortable in English.
We've written up the recognition side separately in can AI understand Indian accents.
The practical consequence is that language coverage and accent coverage need separate test sets. We evaluate every language against regional speaker samples before it ships, not just against the language as a whole.
What this replaces
For most of the businesses we work with, the thing being replaced isn't a human — it's a menu tree that asked callers to press 1 for English.
That design puts the burden of translation on the customer at the exact moment they're already frustrated, and it's why so many multilingual IVR deployments show high abandon rates.
Both why "press 1 for English" loses customers and our multilingual IVR guide cover that failure in more detail.
The alternative is simple to describe and was hard to build: the caller speaks, and the agent answers in whatever language they used. No menu, no selection step, no press-1.
What we'd tell another founder
A few things we'd say to anyone building for an Indian (or any non-Anglo) market:
- Talk to users, not buyers, when designing the product. The buyer is in English. The user almost never is.
- Don't bolt languages on later. Multilingual is an architectural decision, not a feature. Building English-first and adding Hindi later means you'll always have second-class Hindi.
- Resist the translation-layer trap. It's the cheap way and it always shows. Customers can hear translated AI within three seconds.
- Trust the data, not the feedback. If we'd built only what customers asked for, we'd still be English-only and stuck at 3.4 CSAT.
We're shipping six more languages in Q3. The same logic applies. We're not waiting for customers to ask.
The current list lives on the languages page, and how it fits into the rest of the stack is on the voice platform page.
If you want to hear it for yourself, call us: +91 96623 20707. AIVA picks up. Pick a language and ask anything — or start free with ₹500 of credit and point it at your own number.