← Back to Blog

Voice AI in APAC Customer Support: What Works, What Breaks, and Why Latency Kills Adoption

Voice waveform visualization overlaid on a map of Southeast Asia showing call center connections

Voice AI for customer support has been "six months away" from mass adoption for about four years now. The demos are impressive. The production reality is considerably more complicated — particularly in APAC, where the acoustic and linguistic conditions are genuinely different from the English-speaking markets where most voice AI models were trained.

This is not a pessimistic article. Voice AI works. We have deployments running voice support in Bahasa Indonesia, Mandarin, and Thai. But the failure modes are specific and predictable, and understanding them in advance is the difference between a pilot that converts to a production contract and one that quietly gets shut down after three months.

The Latency Problem Nobody Talks About Enough

Speech-to-text, language model inference, text-to-speech. Three sequential steps, each with a processing time. In a local call centre, the round-trip time from end of speech to start of AI response needs to be under 800 milliseconds to feel natural to most callers. Above 1,200 milliseconds, abandonment rates climb sharply.

Achieving sub-800ms latency is feasible with the right architecture: streaming STT (not batch), a model hosted in-region (Singapore or Tokyo AWS), and TTS synthesis that starts before the full response is generated. The challenge for APAC is that "in-region" matters more here than in the US. A voice AI processing call audio in us-east-1 from a caller in Jakarta adds 180–220ms of network latency before any computation starts. That round-trip from Surabaya to Virginia and back to Jakarta costs you before the AI even starts thinking.

We host all voice processing on AWS ap-southeast-1 (Singapore) for Southeast Asian deployments and AWS ap-northeast-1 (Tokyo) for East Asian markets. The latency difference compared to US-based hosting is 120–160ms per round-trip — enough to move from "slightly awkward" to "genuinely conversational".

Accent Variability Is the Main ASR Challenge

Automatic Speech Recognition (ASR) accuracy is typically measured on benchmark datasets that don't reflect production conditions. Google's ASR benchmark on Bahasa Indonesia uses newsreader-quality audio. Your customers are calling from motorcycles on Jakarta's Sudirman Road.

The accent variability problem in APAC is compounded by the fact that "Mandarin speaker" or "Thai speaker" does not describe a homogenous population. A Mandarin-speaking customer in Singapore has a measurably different accent profile from a Mandarin speaker in Taipei or Chengdu. Standard Mandarin ASR models trained primarily on Putonghua data from Mainland China perform noticeably worse on Singapore Mandarin, which incorporates different tonal realisations and frequent code-switching with English and Hokkien.

The practical approach is accent adaptation: collect real call recordings from your target population, fine-tune the ASR model on those recordings, and measure Word Error Rate (WER) specifically on your user base rather than generic benchmarks. A 12% WER on a benchmark is not meaningful if your actual WER on production traffic is 31%.

For the deployments we've run, WER on Bahasa Indonesia improves from an average of 23% with off-the-shelf models to 11% after fine-tuning on client-specific recordings — a reduction that meaningfully changes resolution rates in production.

Background Noise: The Consistent Killer

A significant portion of support calls in Southeast Asia are made from environments that Western voice AI labs don't design for: outdoor markets, vehicle interiors, shared-space offices without acoustic separation, and home environments with multiple people speaking.

Modern noise cancellation handles steady-state noise (traffic hum, AC units) reasonably well. It handles sudden transient noise (horn blasts, door slams) poorly — these often register as brief speech segments, corrupting the transcript. And it handles cross-talk from a nearby human conversation almost not at all.

One practical mitigation is VAD (Voice Activity Detection) tuned for the deployment environment. Standard VAD thresholds are calibrated for office noise floors. For a client running a consumer insurance hotline in Indonesia, we recalibrated the VAD silence threshold downward by 8dB to reduce false positives in noisy street environments. This reduced ASR "hallucination" events (where the model transcribes ambient noise as words) by about 40%.

The Two Voice Scenarios That Actually Work Well Today

Despite the challenges, two voice AI use cases are reliably working in APAC production deployments:

Inbound IVR replacement. Replace the traditional DTMF IVR ("Press 1 for billing, press 2 for technical support") with a conversational intake agent that collects the customer's name, account number, and the nature of their query — then routes to the right human agent queue with that context already filled in. This doesn't require high WER accuracy because the task is structured: you're asking specific questions with a narrow range of expected answers. WER of 25% is acceptable because the AI can ask for clarification when the response doesn't match expected patterns.

Outbound follow-up calls. Scripted outbound calls for appointment confirmation, payment reminders, and delivery status updates. These are low-complexity, one-way information exchanges where the AI reads content and captures a simple binary response (confirm/cancel, yes/no). Latency requirements are also lower because the AI is initiating, not responding to spontaneous questions.

What doesn't work well yet: open-ended inbound voice support for complex queries. A customer calling to dispute a charge, explain a product malfunction, or navigate a multi-step refund process requires the kind of free-form conversation that current voice AI handles inconsistently in noisy APAC environments. This will improve. It's not production-ready at acceptable error rates today.

Measuring Voice AI Performance Correctly

The metrics that matter for voice AI are different from chat support. Don't use CSAT as your primary voice AI metric — customers rate the overall experience, not the AI specifically, and a bad product experience will tank CSAT regardless of how well the AI performed.

The three metrics that predict voice AI success or failure:

Transfer rate: The percentage of calls the AI cannot handle and transfers to a human. For the IVR replacement use case, a transfer rate above 35% means the AI is failing its intake function. Below 20% means it's working. Track by call type — appointment confirmations should have near-zero transfer rates; billing disputes will legitimately have higher ones.

Containment rate: The percentage of calls the AI handles end-to-end without human intervention. For outbound confirmation calls, 90%+ containment is achievable. For inbound open-ended support, aim for 40–60% on a mature deployment.

Repeat call rate within 48 hours: A customer who calls back within two days is a customer whose issue wasn't resolved. Track this by AI-handled vs human-handled sessions. If your AI-handled calls have a 15% repeat rate versus 8% for human-handled calls, you have a resolution quality problem that CSAT alone won't surface.

The TTS Voice Selection Problem

Text-to-speech voice selection affects CSAT in voice deployments more than most teams expect. In Southeast Asia, a generic "neutral English" voice with an American accent creates immediate friction for customers calling in Bahasa or Thai. This sounds obvious, but many vendors ship one TTS voice and don't offer per-market customisation.

The preference for naturalness over neutrality is strong in APAC markets. In a user study we ran with 200 participants across Singapore, Indonesia, and Thailand, 73% preferred an AI voice with a regional accent over a "neutral international" voice, even when they rated the neutral voice as "clearer". The regional voice created a sense of cultural familiarity that influenced their willingness to continue the conversation.

TTS for non-English APAC languages should use voices trained specifically on native speaker data — not translated from English TTS models. The prosody (rhythm and intonation patterns) in Bahasa Indonesia, Cantonese, and Thai are structurally different from English, and a model that imposes English prosody onto these languages sounds unnatural to native speakers even if the words are phonetically correct.

Where Voice AI Is Heading in the Next 18 Months

Two developments will change the voice AI picture in APAC significantly: end-to-end speech models and in-region LLM inference.

End-to-end models — where the AI processes raw audio directly without an intermediate text representation — eliminate the ASR-then-LLM pipeline latency and handle prosodic cues (tone of voice, speaking pace, emotional intensity) that text-based models cannot. Google's AudioPaLM and OpenAI's audio-in GPT-4o are early versions of this architecture. Production-ready versions that work in APAC languages are 12–18 months away.

In-region LLM inference is improving rapidly. AWS Bedrock in ap-southeast-1 already offers Claude and Titan models. As more frontier models become available in Singapore-region endpoints, the network latency bottleneck for APAC voice AI will largely disappear.

The teams that invest in building clean voice AI infrastructure today — with proper ASR fine-tuning, noise handling, and latency optimisation — will be positioned to swap in better models as they become available without rebuilding from scratch.

Exploring voice AI for your support operation?

Level3 AI's voice support module handles inbound IVR and outbound follow-up in Bahasa Indonesia, Mandarin, Thai, and English. We'll walk you through what's realistic for your use case before you commit to a pilot.

Talk to Our Team