2026: Customers Switching English & Local Language On Calls

TL;DR

When customers switch between English and a local language on calls, the behavior is called code-switching. In India, it commonly appears as Hinglish, Tanglish, or Kanglish. This is normal multilingual communication, not a language deficiency. It becomes a business problem when voice bots, speech recognition, analytics, and call workflows assume every caller sticks to a single language throughout the conversation.

If a customer says, “Mera EMI due hai, but payment link open nahi ho raha,” they are not speaking broken Hindi or broken English. They are code-switching.

Code-switching means alternating between two or more languages in the same conversation, sometimes inside the same sentence. Microsoft Research defines it as “the alternation of languages within a conversation or utterance” and calls it a common communicative phenomenon across multilingual communities worldwide.

In Indian call centers, customers switching between English and a local language on calls is the default, not the edge case. It shows up as Hinglish (Hindi-English), Tanglish (Tamil-English), Kanglish (Kannada-English), and dozens of other regional-English mixes. Human agents handle this instinctively. IVR systems, speech recognition engines, voice bots, QA dashboards, and compliance records often cannot.

If your team is evaluating voice automation for these mixed-language calls, book a demo to test with real code-switched audio before committing.

What Is Code-Switching on Customer Calls?

When people talk about customers switching between English and their local language on calls, the technical term is code-switching. A closely related term, code-mixing, is often used when the blending happens at the word or phrase level inside a single sentence. In most call center and speech AI contexts, “code-switching” serves as the umbrella term for both.

There are two main types:

Intra-sentential code-switching happens inside the same sentence. This is the harder case for technology because there is no clean boundary where the system can change language mode. Example: “Aapka loan amount disburse ho gaya hai, please account check karo.”

Inter-sentential code-switching happens between sentences. The language boundary is clearer, which makes it somewhat easier for speech recognition. Example: “Your EMI is due today. Kripya payment kal tak kar dijiye.”

In India, the most common code-switching patterns in customer calls involve Hinglish and related mixes: Hindi-English, Tamil-English, Kannada-English, Bengali-English, Telugu-English, and Marathi-English. The specific mix depends on the caller’s region, comfort level, and the subject matter being discussed.

For a deeper look at how this affects voice automation specifically, see this code-switching Voice AI guide.

Why Do Customers Switch Languages During a Call?

Code-switching is not random and it is not a sign that the customer lacks fluency. It is efficient, natural, and contextually meaningful.

Financial and technical terms are often easier in English. Words like EMI, KYC, OTP, PAN, loan amount, due date, and payment link are known to most Indian customers in English. Translating them into pure Hindi or Tamil can actually create confusion.

Local language carries trust and emotion. On sensitive calls (collections, complaints, health, insurance), the local language often feels warmer. Customers express frustration, negotiate, and build rapport more naturally in their mother tongue.

Customers may not know a clean translation for everything. They know the banking term in English but explain the situation in Hindi, Tamil, or Kannada. This produces sentences like “Mera KYC pending hai, OTP nahi aaya,” where the key entities are English and the sentence structure is Hindi.

Agents mirror the customer’s language. Human agents naturally shift languages to keep the conversation moving. AI agents need explicit design to do the same thing.

The patterns are cultural, not accidental. A practitioner on LinkedIn argued that code-switching patterns differ by market and cannot be assumed from generic “multilingual support.” Delhi Hinglish, Mumbai Hinglish, and Lucknow Hinglish sound different. Tamil-English mixing follows different grammatical patterns than Hindi-English. These are not interchangeable.

India’s language reality supports this at scale. According to the IAMAI/Kantar ICUBE 2024 report, 870 million internet users accessed the internet in Indic languages, 57% of urban internet users prefer Indic-language content, and roughly 140 million users interact through voice commands. These are not people who will neatly pick “English” or “Hindi” in an IVR menu and stick with it.

Why Code-Switching Matters for Call Centers and Voice AI

A bilingual human agent understands code-switched speech without thinking about it. The technology stack behind that agent usually does not.

When customers switch between English and a local language on calls, the impact ripples across the entire call pipeline:

Transcription: If the speech-to-text engine misidentifies the language, it produces garbled transcripts. Words get deleted, substituted, or hallucinated.

Intent detection: A customer saying “Main Monday ko payment kar dunga, abhi account mein balance nahi hai” is making a promise to pay. If the natural language understanding system only catches fragments, it may classify this as a general inquiry or miss the promise-to-pay date entirely. Understanding domain-specific NLU for financial conversations becomes critical here.

QA and compliance: Regulators and auditors rely on call recordings and transcripts. If the transcript drops the Hindi portions of a collections call, the compliance record is incomplete.

Analytics and CRM: Structured outputs like “promise to pay,” “dispute raised,” “KYC incomplete,” or “callback requested” depend on accurate comprehension of what the customer actually said. In debt collection language, the difference between “nahi karunga” (won’t pay) and “kal karunga” (will pay tomorrow) changes the entire disposition.

Practitioners on Reddit confirm this is not theoretical. One BPO operator running roughly 15,000 calls per day across Manila and Bogota reported that about 40% of their calls involved customers and agents switching between English and the local language mid-sentence. Their English-only transcription worked fine, but bilingual calls produced hallucinations or dropped non-English segments entirely.

The BFSI Code-Switching Map

Here is what code-switching looks like in real Indian BFSI call moments, and what breaks when AI fails to handle it:

A benchmark by ServiceNow AI introduced Answer Error Rate (AER) specifically because transcript errors cascade into downstream failures: case numbers, names, dates, and request reasons all get corrupted when the speech-to-text layer stumbles.

Why Standard Speech Recognition Fails on Mixed-Language Calls

The failures are not because customers are unclear. They happen because most systems are built to handle one language at a time.

One-language-per-segment assumption

Many ASR engines identify the language at the start of an audio segment and process the entire segment through that language’s acoustic and vocabulary models. When a customer switches mid-sentence, the system tries to force English phonemes through a Hindi model (or vice versa), producing substitutions and deletions. Gnani’s analysis of Hinglish ASR explains that utterance-level language identification commits to a single language for an entire audio segment, which fails on intra-sentential switching.

Wrong script output

This is an especially painful failure mode for Indian languages. A practitioner on Reddit testing Google Cloud STT reported that adding Hindi as an alternative language caused clear English speech to be output as Devanagari. The system heard the sounds correctly but rendered them in the wrong script, making the transcript unusable.

Hallucinations and dropped segments

Practitioners on Reddit report that phrase-level switching, strong accents, background noise, and overlapping turns can trigger hallucinations in both open-source models like Whisper and commercial APIs. One user working with English, Marathi, and Mandarin noted that sentence-level switching sometimes works, but phrase-by-phrase switching with accents causes the model to generate words that were never spoken.

Diarization collapse

When speaker identity and language shift at the same time (common when an agent mirrors a customer’s language switch), diarization can break. The system may attribute turns to the wrong speaker or merge segments incorrectly, destroying the call structure that QA and analytics depend on.

For teams measuring these failures, understanding voice agent accuracy metrics for Indian languages is a practical starting point.

Multilingual Support Is Not the Same as Code-Switching Support

This distinction trips up many buyers. A system can support Hindi and English separately and still fail on Hinglish. A vendor can list 50 languages and still produce garbage when a borrower mixes two of them in one sentence.

A language list is not mixed-language performance. Supporting Hindi and English as separate options does not mean the system handles the space between them.

Automatic language detection is not mid-sentence switching. Google Cloud’s language recognition documentation lets you specify up to three alternative languages, but it also says fewer requested languages help the system choose correctly and that a single language gives the best results. That is language selection, not code-switching.

Translation is not code-switching. Translation converts output from one language to another after the fact. Code-switching requires understanding mixed input as spoken, in real time. ServiceNow’s benchmark found that Whisper, without explicit language parameters, defaulted to translating code-switched audio into English rather than preserving the spoken languages.

A clean demo is not production readiness. Vendor demos typically use studio-quality audio with slow, deliberate language switches at sentence boundaries. Real phone calls have background noise, interruptions, crosstalk, regional accents, and fast speech. Practitioners on Reddit repeatedly flag this gap, noting that simulated call audio does not reflect real telephony conditions.

If you are evaluating vendors for your institution, the procurement guide for small finance banks covers the due diligence steps that apply here.

How Call Centers Should Handle Customers Who Switch Languages

Do not force a single language if the workflow can handle mixed speech

Pressing 1 for English and 2 for Hindi is fine for initial routing. But it does not solve the actual interaction when the customer naturally mixes both languages throughout the call.

Build scripts that allow mixed-language terms

In BFSI, keep domain terms in the language customers actually use. EMI, KYC, OTP, PAN, UPI, loan amount, due date, and payment link are terms most Indian customers know in English. Amazon Connect’s documentation recommends preserving English brand names and product codes inside non-English responses rather than translating them, which aligns with how real customers already speak.

Test with real local audio

ServiceNow’s benchmark, useful as it is, used synthetic text-to-speech audio and the authors acknowledge it may not capture real bilingual prosody. Indian deployments should use actual telephony recordings from target regions. Delhi Hinglish sounds different from Hyderabad Telugu-English, and both differ from Kolkata Bengali-English.

IIT Guwahati’s HingCoS corpus, which includes 25 hours of Hindi-English code-switched speech recorded on landline and mobile phones in realistic environments, exists precisely because researchers recognized the need for real-world mixed-language data.

Segment by language pair and switch type

Do not lump all “multilingual” calls together. Hinglish calls behave differently from Tamil-English calls. Intra-sentential switching (mixing inside one sentence) is far harder than inter-sentential switching (changing language between sentences). A vendor that shows you clean inter-sentential demos has not proven it can handle the harder case.

Measure task completion, not just transcription accuracy

Hamming’s testing framework for multilingual voice agents recommends measuring WER, intent accuracy, and task completion for code-switched utterances, with a suggested 80%+ task-completion threshold despite code-switching. Raw transcription accuracy is necessary but insufficient. The real question is: did the system capture the customer’s intent and trigger the right action?

Keep human escalation available

For regulated workflows like collections, KYC, fraud, and disputes, unresolved language ambiguity should trigger a clarifying question or human handoff. This is not a workaround. It is good system design.

For regulated BFSI teams, reviewing the enterprise security and compliance checklist before deployment helps ensure these escalation paths meet audit requirements.

How to Test Whether Your Voice System Handles Code-Switching

Use a four-layer testing framework: Listen, Understand, Act, Recover.

Testing checklist

1. Create 10 to 20 code-switched utterances per language pair. Hamming recommends this as a baseline test protocol for multilingual voice agents.

2. Test both directions. Hindi sentence with English financial terms, and English sentence with Hindi phrases. Both happen on real calls.

3. Use real telephony conditions. Mobile audio quality, background noise, interruptions, silence, crosstalk, fast speech, and regional accents. Studio-clean test audio hides exactly the failures that matter.

4. Measure beyond WER. ServiceNow uses WER, Semantic WER, and Answer Error Rate because a small transcription error can flip a customer’s intent. A missed “nahi” (no) changes everything.

5. Check latency by language. Hamming recommends investigating any language that shows more than roughly 20% latency increase versus the English baseline. Slow responses on Hindi segments create awkward pauses that erode caller trust.

6. Rerun after model updates. ASR models change. Retest code-switching performance after every update and monitor for drift.

Questions to Ask a Voice AI Vendor About Code-Switching

If your customers regularly switch between English and a local language on calls, these questions separate vendors who genuinely handle code-switching from those who merely check a multilingual box:

1. Do you support code-switching, or only separate languages? Ask for language-pair-specific evidence, not a generic language count.

2. Which Indian language pairs have you tested? Hinglish is not the same problem as Tamil-English or Bengali-English. Each pair has different phonology, grammar, and switching patterns.

3. Do you have WER on code-switched telephony audio? Not Hindi-only WER. Not English-only WER. WER on the actual mixed-language audio your customers produce.

4. Can your system preserve script correctly? In Indian languages, outputting English words as Devanagari transliteration (or vice versa) makes the transcript unusable for downstream systems.

5. How do you handle mid-sentence switching? Ask whether the system uses utterance-level language identification, continuous language detection, or a unified multilingual model. The architecture matters.

6. What happens when confidence is low? The answer should include clarification prompts, retry logic, and human handoff, not just a generic error message.

7. Can your analytics produce structured dispositions from code-switched calls? The output should still be “promise to pay on Monday” or “KYC document missing,” not a garbled transcript with no actionable tag.

For teams comparing platforms, this comparison of voicebot platforms for Indian businesses covers several of these evaluation criteria.

Quick Glossary

FAQ

What is it called when customers switch between English and Hindi on calls?

It is called code-switching. When the specific mix is Hindi and English, it is commonly called Hinglish. Similar terms exist for other Indian language pairs: Tanglish (Tamil-English), Kanglish (Kannada-English), and so on.

Is code-switching the same as code-mixing?

They are closely related. “Code-mixing” typically refers to blending languages at the word or phrase level inside a single sentence. “Code-switching” is the broader term covering both sentence-level and word-level switching. In most call center and ASR discussions, code-switching is used as the umbrella term.

Why do customers use English words in local-language calls?

Often because product, finance, and app terms are known in English: EMI, OTP, KYC, PAN, payment link, loan amount, account number. Customers explain the surrounding situation in their preferred local language because it is more comfortable and expressive.

If our system supports Hindi and English, does it support Hinglish?

Not necessarily. Separate support for Hindi and English does not guarantee accurate transcription or intent detection when a speaker switches mid-sentence. The system may process English words through Hindi acoustic models or output the wrong script entirely.

How common is code-switching in Indian call centers?

Common enough that Indian ASR researchers and voice AI vendors treat it as a core design challenge. Academic datasets like IIT Guwahati’s HingCoS corpus and the MUCS 2021 challenge include thousands of code-switched utterances specifically to train and evaluate models on this behavior.

Does code-switching only affect transcripts?

No. Transcript errors cascade into intent detection, call summaries, QA scores, compliance records, CRM dispositions, and sentiment analysis. A transcript that drops the Hindi portion of a collections call can make it look like a promise-to-pay was never made.

How should AI voice agents handle customers who switch languages?

The system should listen in both languages simultaneously, detect intent across language boundaries, trigger the correct workflow, and escalate to a human when confidence is low. Testing with real code-switched telephony audio (not clean studio recordings) is essential before deployment.

Customers do not speak in neat language boxes. Code-switching is not a language preference selected once in an IVR. It is a turn-by-turn behavior inside the conversation.

If your BFSI call flows involve customers switching between English and local language on calls for EMI reminders, KYC, collections, or support, evaluate your voice automation on those mixed calls before you deploy it. Explore how Awaaz AI helps teams run multilingual voice workflows with structured analytics and human handoff for exactly these scenarios.