Hinglish, Tamil, or pure Hindi: why your bot must speak like your customers

Most Indian customers type support questions in Hinglish or a regional language, not the English your FAQ was written in. Understanding that variety is a retrieval problem, and answering it well means replying in the register the customer used. This post is about why that is harder than translation, and how it works.

Open your support inbox and read how customers actually write. "Bhaiya delivery kab tak?" "Return karna hai size chota hai." "Pongal offer irukka?" Almost none of it is the polished English your FAQ page was written in - and that mismatch is where most chatbots quietly fail. The businesses it costs most are the ones who never notice, because a customer who was not understood does not file a complaint. They just stop typing.

The English-only trap

Traditional keyword bots match exact phrases. If your FAQ says "What is your return policy?" and the customer types "return kaise hoga," the keyword bot shrugs. So businesses either force customers into rigid button menus, or watch queries fall through to a human - defeating the point of automation entirely.

The uncomfortable truth: a bot that only understands formal English only serves the customers who least need help. The customer who writes in Hinglish or a regional language is exactly the one who won't email you a neatly formatted question later.

How semantic understanding changes this

Modern retrieval doesn't match words - it matches meaning. "Return kaise hoga," "how to send back," and "exchange karna hai" all land on the same passage of your return policy, even though they share almost no words with it. Your knowledge base stays in whichever language you wrote it; the understanding layer handles the variety on the customer's side.

Your documents can be in English. Your customers shouldn't have to be.

Answering in the customer's register

Understanding the question is half the job; the reply matters too. The agent mirrors the customer's register while the facts underneath stay grounded in your documents and cited - tone adapts, truth doesn't. A question typed in Devanagari comes back in Devanagari; one typed in Hinglish comes back in Hinglish, not in textbook English that reads like a form letter.

The knowledge base itself stays in whichever language you wrote it. You are not maintaining one copy of your return policy per language - the same passage answers all of them, which is the only version of this that a small team can actually keep current.

Why keyword bots fail hardest here

Keyword matching was always brittle, but a mixed-language inbox breaks it completely. A flow built on the trigger word refund never fires on paisa wapas. A menu tree in English is a wall to a customer thinking in Tamil. The tools built around keyword flows handle this by making you write every variant by hand - one trigger per phrasing, per language, forever. That is the same limitation WhatsApp campaign tools hit on inbound support.

Meaning-based retrieval inverts the work. You write your policy once, in one language, and the matching happens in meaning-space, where return kaise hoga and how do I send this back land on the same passage. The maintenance difference is the whole game for a small team: one document to update instead of one per phrasing, per language, forever.

How each form of the question is handled

The status, in one table. Every row answers from the same uploaded documents - what changes is the register the question arrives in.

Every one of those answers comes from the same documents you uploaded once - there is no per-language knowledge base to maintain, and no second copy per channel either. The WhatsApp agent and voice agent pages cover how each channel handles this, and the FAQ states it plainly too.

Three exchanges, side by side

What the understood-today half looks like in practice. A customer types "What is your return policy?" and gets the 7-day window, cited to returns.pdf. Another types "return karna hai, size chota hai" - different words, no overlap with the document - and lands on the same passage, because the matching happens on meaning. A third types "Pongal offer irukka?" and, if your documents say nothing about a Pongal offer, gets an honest refusal and the option of a person rather than an invented discount.

That third exchange is the one to appreciate, because it is the one most tools get wrong. A bot that fails safely in a language edge case is worth more than one that succeeds impressively until it improvises - and language edge cases are where improvisation hides best, since you are least likely to audit an answer in a register you did not write. The refusal is the feature - the same grounding rule that stops English hallucination stops the Hinglish kind too.

What to do this quarter

You do not need to wait for native-script replies to act on any of this. The understanding half works now, and most of the value is in it - the customer who types in Hinglish gets their answer; it simply arrives in English, which nearly all of them read comfortably even when they would not write it. Reading and writing are different skills in a second language, and support only needs the customer to do the easier one.

So: launch with what ships, on the chat widget. Then watch the knowledge-gap list with a language eye - a question that failed because it used a term your documents never mention is a one-line fix. Add the phrasings your real customers use, and the match rate climbs without any new technology at all.

The measure of success is simple and worth writing down before you start: what share of Hinglish questions get a grounded answer this month versus next? You have the data - every conversation is in the inbox with its transcript. If that share is not climbing as you add customer phrasings to your documents, the misses will tell you which words are still missing.

Writing documents for a mixed-language audience

You can improve the understood-today half with how you write. Retrieval matches meaning, but it matches better when your documents use the words your customers use.

• Include the terms customers actually type alongside the formal ones - exchange and replace, refund and money back.
• Keep numbers as digits. 7 days survives every register; a week in prose is fuzzier to match - and digits read identically to a customer thinking in any language.
• Name cities and regions explicitly - do you deliver to Wakad fails if your policy only says Pune metro area.
• Keep one fact in one place, per the knowledge-base guide - mixed-language matching is exactly where a buried answer goes missing.

The mechanics of meaning-matching are in the RAG explainer, which defines the jargon as it goes. For coaching institutes - where parents ask in whichever language they think in - the EdTech walkthrough covers the admission-season version of this problem.