Multilingual customer support with AI for Indian businesses

Multilingual AI customer support means one agent that reads a message in Hindi, Tamil, Kannada, Telugu, Marathi, Bengali or English, works out what the customer wants, answers in the language they used and, when it hands off, gives the human rep a summary in the rep's language. For an Indian business that is not a feature; it is the difference between an agent that resolves and one that only works for the English-speaking third of your customers. This article covers what a multilingual support agent actually does, what breaks, how to evaluate it per language, and what it costs to build.

Why multilingual AI customer support matters in India

Most Indian support queues are already multilingual whether the business admits it or not. Customers write in Hinglish, in Tamil typed with Roman letters, in Kannada script with an English product name in the middle, or by sending a voice note. English-only bots handle the English messages and fail the rest, and the failed ones become phone calls. A customer service agent that handles the whole queue changes the economics, because the languages you were routing to the most expensive channel become the ones the agent resolves first.

There is also a trust reason. A customer who asks in Marathi and gets an answer in Marathi believes the business is speaking to them. One who gets English back, or a machine-translated sentence with the wrong honorific, assumes nobody is listening.

What a multilingual support agent does, step by step

Hindi customer support AI: the specific problems

Code-mixing and Romanised script

"Mera order abhi tak nahi aaya, tracking bhi update nahi ho raha" is Hindi in Latin script with English nouns. Detection has to work at the phrase level. Current large models handle Hinglish well in our testing; smaller and older models often classify it as English and answer in the wrong language. The fix is to test detection on your own message history rather than on a benchmark, and to let the agent mirror the customer's script: if they wrote Devanagari, reply in Devanagari; if they wrote Roman Hindi, reply in Roman Hindi.

Register and formality

Hindi has three levels of "you". A support agent should use aap, always, and the prompt must say so explicitly, because models drift toward tum when the customer does. The same applies to Tamil, Kannada and Telugu honorifics. Register errors are the complaint we hear most from support managers reviewing transcripts, and they are cheap to fix with a style rule and an evaluation check.

Entities in mixed formats

Amounts written as "2 lakh", dates as "parso", addresses with landmark-based directions. The extraction layer needs examples from your own tickets, and the agent should confirm any entity it will act on: "Should I change the delivery address to the one ending in Koramangala?" in the customer's language.

Regional language chatbot coverage: which languages, in which order

Do not launch with twelve languages. Look at the last three months of tickets, classify by language, and launch with English plus the two or three that cover most of the non-English volume. Add languages one at a time, each with its own evaluation set. A regional language chatbot that is excellent in Hindi and Tamil beats one that is mediocre in ten languages, because a customer who gets a bad answer in their language is more offended than one who was politely told to switch to English.

Model choice differs per language. Model-agnostic routing lets you send Hindi to one model and Kannada to another if the evaluation says so, and swap when a better one appears. Indian-language models such as those from Sarvam are worth including in the benchmark alongside the large general models, particularly for speech.

Vernacular support automation needs a vernacular knowledge base

The most common failure we see is a help centre that exists only in English, with the agent expected to translate on the fly. That works for simple policy answers and fails for anything with product-specific terms, because the model translates "EMI conversion" or "cashback wallet" three different ways in three conversations. The practical route is a two-layer knowledge base: the source content stays in English with a glossary of product terms and their approved translations per language, and retrieval works across languages using multilingual embeddings. The agent answers from the English passage and renders it in the customer's language using the glossary. Over time, the knowledge-gap report will show which articles are asked for most in each language, and those get a human-reviewed translation.

Hand-off with a translated summary

When the agent escalates, the rep should receive the customer's language, a summary in the rep's working language, the intent, the entities already verified and the actions already taken. The customer should not be asked to repeat anything. If your reps are organised by language, routing uses the detected language; if they are not, the translated summary is what makes a Hindi-speaking customer's ticket workable for a Kannada-speaking rep. The multilingual voice agent for a hospital network uses exactly this pattern for call hand-offs, and it transfers directly to chat.

Voice and WhatsApp change the requirements

On WhatsApp, customers send voice notes in their language and expect a text reply. That means speech-to-text per language before anything else, and the accuracy of Indian-language transcription varies far more between vendors than text does. On the phone, latency and accent handling dominate; see the Indian-language voice agent guide and the voice agents service. For text-only channels the problem is easier, and a text-first launch is the sensible order.

Evaluate per language, not overall

An overall resolution number hides a failing language. Build a golden set per language from real conversations: fifty to a hundred each, with expected intent, expected entities and an acceptable answer. Score detection accuracy, intent accuracy, entity accuracy, answer correctness and register. Run the set on every prompt or model change. In shadow mode, have a native speaker on the support team review a sample of drafts per language every week; they will catch the register and idiom errors no automated metric sees.

A worked example

A consumer-lending business ran support on email and WhatsApp in English, with Hindi and Marathi customers phoning because the bot could not help them. The build started by classifying three months of messages by language and script, which showed most non-English traffic was Roman-script Hindi and Marathi about EMI dates, statements and address changes. The agent launched in shadow mode in English and Hindi, with drafts reviewed by a Hindi-speaking rep. Register errors and inconsistent translation of product terms were the main findings, fixed with a glossary and style rules. After shadow mode the read-only intents went live in both languages; Marathi was added a month later with its own evaluation set. Reps received translated summaries, and the phone queue, which had been the overflow for the failed bot, shrank to the calls that genuinely needed a person.

Team and timeline

A multilingual support agent is typically an AI engineer, a conversation designer with the relevant languages, a data engineer for the helpdesk and account integrations, and a native-speaking reviewer from your support team per language. English plus two languages takes six to nine weeks: two for message analysis, golden sets and the glossary, three to four for the build and shadow mode, and the rest for staged rollout. It fits the customer service agent service, from $12,500 / ₹8L, with additional languages priced by evaluation and glossary work rather than a flat per-language fee. A Sprint Zero at $3,250 is the right start if you do not yet know your language mix. Full details are on the pricing page, and ongoing tuning is covered by a Care Plan.

Before you start: a checklist

• Classify three months of messages by language and script
• Pick English plus two or three launch languages by volume
• Build a glossary of product terms with approved translations
• Write register rules per language (aap, honorifics, formality)
• Create a golden set of 50–100 real conversations per language
• Name a native-speaking reviewer per language for shadow mode
• Decide hand-off routing: by language or with translated summaries
• Test speech-to-text per language if WhatsApp voice notes or calls are in scope

Glossary

• Code-mixing: switching languages within a sentence, such as Hinglish
• Romanised script: an Indian language written in Latin letters
• Register: the level of formality, including forms of address
• Multilingual embeddings: vector representations that place the same meaning in different languages close together, enabling cross-language retrieval
• Translated summary: the hand-off note written in the rep's language rather than the customer's
• Golden set: real conversations with expected outcomes, used to evaluate every change

Related reading

AI customer service agents: resolve, don't deflect explains the resolution model the multilingual agent sits inside, WhatsApp AI chatbot for business covers the channel most Indian customers use, and the pricing page has the numbers.

Launch in the languages your customers already write in, evaluate each one separately, and the agent will resolve the tickets the English-only bot was quietly turning into phone calls.