The opening piece in this series drew the line between language coverage — the list of languages on a vendor slide — and local fluency, what the customer actually experiences on the line. It named code-switching as one of the three places coverage quietly fails. This piece stays on that one, because in this region it is not a corner case. It is how the call comes in.

How common is code-switching in Southeast Asian customer calls, really?

Common enough to have names. Taglish in the Philippines, Singlish in Singapore, Bahasa rojak in Malaysia, and the everyday Indonesian–English mix in urban Jakarta are not slang or shortcuts — they are the unmarked, default way a large share of customers speak to a service line. For many of those speakers, committing to one "pure" language for a whole call sounds stiff and unnatural, the way reading from a script would.

That inverts the usual assumption. A voice agent that performs well only when the customer stays in a single language is not handling the standard case with a few hard exceptions; it is optimised for the minority of calls and degraded on the majority. Taglish customer journeys and Mandarin–English switching in Singapore service calls walk through what those conversations actually sound like turn by turn.

What exactly breaks when a customer switches languages mid-call?

A pipeline built to process one language at a time fails in four specific places.

Language identification locks too early. If the system decides at the top of the call that this is an "English call," every stretch the customer speaks in the other language gets forced through an English model and comes out as garbled English. The transcript looks confident and is wrong.

The switch lands on the information-dense word. Customers rarely switch on filler. They switch on the product name, the action verb, or the amount — "Pwede ba i-waive yung late fee?" puts the whole request on one borrowed verb. A wrong guess there loses the intent, not a word, and the agent routes the call or answers as if it heard something else.

The response comes back in the wrong language. An agent that correctly detects a mixed-language question but can only reply in formal English has still broken the exchange: it has made the customer code-switch back to accommodate the machine.

Recovery adds latency. When a mislabelled segment triggers a re-ask — "sorry, could you repeat that?" — the customer repeats, often slower and more irritated, and the extra turn pushes handle time up on exactly the calls that were already harder.

Why doesn't "detect the language, then translate" solve it?

Because both halves of that approach assume language is a property of the whole call, and code-switching makes it a property of individual words. Detecting once and translating the rest treats every switch as an error to be normalised away.

Translation also strips register — the level of formality and deference a moment calls for — and often the intent with it. The mixed phrasing a customer reaches for is frequently the most precise version of what they mean; flattening "i-waive yung late fee" into textbook English can lose the specific, locally understood request. The switch points carry meaning. We go deeper on the runtime mechanics in language identification inside a live voice agent, and on why a generic multilingual base isn't enough in the industry corpus flywheel for local voice AI.

What does code-switching cost on an outbound Talkbot campaign?

It costs the first ten seconds. On an outbound call, the opening line has to sound local immediately; an agent that leads in stiff, formal language while the market speaks a mixed register signals "recording" before it has made its point, and answer, consent, and continuation rates fall right there. If the customer replies in their normal mix and the agent stalls or switches to a re-ask, the call ends early.

Those are the numbers an outbound programme is judged on — contact rate, consent rate, completion rate, and cost per successful contact. Fluency on the switch is not a soft attribute here; it moves the campaign's core metrics. See the Talkbot page for how outbound scenarios are built.

What does it cost on inbound Wizlynn service?

Inbound, the customer arrives mid-problem and uses whatever language mix is natural to them from the first sentence. Mistranscribe the action verb, the product name, or the amount at the switch point and the call routes to the wrong place or drops into "sorry, can you repeat that." Containment and self-service completion fall, average handle time rises because customers repeat themselves, and unnecessary escalations climb — with CSAT dropping on precisely the calls where the customer felt they had to slow down for the machine.

Wizlynn handles this as a multi-agent service flow rather than a single script; from multilingual voice AI to multi-agent orchestration covers how that structure keeps a mixed-language conversation on track across intents.

How does WIZ.AI design for code-switching?

The mechanism is Language Engine, which treats mid-call switching as a first-class behaviour rather than a fallback. It recognises customers as they move between local languages, dialects, and short replies without resetting the live conversation, and it is tuned for the call itself: streaming recognition in roughly 100ms, first audio near 300ms, with noise filtering and barge-in handling on 8kHz telephony.

On top of that sits scenario customisation. The load-bearing words — product names, amounts, addresses, compliance phrases, local place names — are adapted per account, so recognition is strongest exactly where the switch tends to land. Both products draw on WIZ.AI's regional speech data and industry corpus rather than a generic multilingual base — the flywheel in the industry corpus flywheel — so code-switch handling keeps improving on real mixed-language traffic instead of freezing at launch quality. And the reply comes back in the customer's own mix at the right register, which is part of why our multilingual agents don't sound robotic.

How do you test an agent for code-switching before you buy?

Four checks the standard demo won't cover. First, use your own call recordings — real customers, real phone lines — not the vendor's curated set. Second, play sentences that switch language on the key noun, verb, or amount and confirm the intent survives, not just the sentence. Third, check the reply: does the agent answer in the same mix, or does it force the customer back to one language? Fourth, check recovery: when it does mishear, does it recover gracefully or loop "please repeat"?

Then ask the ownership question from the Fast to Deploy capstone: after go-live, who tunes the load-bearing vocabulary for your product names and compliance phrases, and how long does that change take — your team on the platform, or a change request back to the vendor?

Coverage says the agent speaks the customer's languages. Fluency is whether it can follow the customer from one to the other without dropping the thread. See how mid-call switching and scenario tuning work on the Language Engine, Wizlynn, and Talkbot pages, or book a demo and bring recordings where your customers switch languages — that is the test that matters. The next piece in this series covers the failure mode that survives even a perfect switch: getting the register wrong.