Most enterprise sales in India, the Gulf, and Egypt doesn't happen in English. It happens in Hindi written in Devanagari, in Arabic that reads right-to-left, and on dialects — Gulf, Egyptian, Levantine — that a translation wrapper can't model. When a voice AI agent handles outbound sales by routing everything through an English-language model and translating the output, the result looks fluent on a slide and sounds broken on the call. Buyers hear it. They tune out.
This isn't a localization preference. It's a script-level problem. Devanagari, Arabic, and the other Indic scripts have shape, joining, and tone rules that an English-first pipeline can't reproduce. When the render side fails — when आप gets transliterated to "aap," when right-to-left rendering breaks, when brand names get mangled inside Devanagari — the buyer's brain flags the agent as untrustworthy in the first five seconds of the call.
This post walks through what script fidelity means for voice AI at the rendering layer, where English-first pipelines fall short on Devanagari and Arabic, and the architectural pieces that have to be in place to handle mixed-direction scripts in the same inference pass. The regional scripts and sales scripts pages have live dialogs; this post unpacks the engineering behind them.
Why English-First Pipelines Get Scripts Wrong
The failure mode is structural, and it's the same one we covered in code-switching but applied at a different layer — the rendering layer. An English-first pipeline transcribes Devanagari audio into a normalized transliteration, then translates that to English, runs the LLM in English, and translates the output back. By the time the response hits the caller's ear, three things have happened, all bad:
- Register collapses. आप (āp, formal) and तुम (tum, familiar) become the same English "you." A buyer who's nominally a senior decision-maker gets a casual address, or vice versa. Either mistake is a relationship-killer.
- Honorifics vanish. "Ma'am," "ji," "sir" — the small attaching particles that signal posture and intent in Indian English-influenced Hindi — get dropped or garbled on the round-trip back.
- Brand names get mangled. "Salesforce," "AWS," "Genesys," and the buyer's own product name lose their phoneme shape on the way through transliteration. The agent says something close, but not right.
The result is the speech equivalent of clothing that doesn't quite fit: technically wearable, structurally wrong. Buyers in Devanagari- and Arabic-speaking markets notice, and conversations die before the value prop lands. The script has to be rendered natively, with the right register, the right attaching particles, and the right brand-name phonemes — and it has to be rendered this way at the same instant the buyer hears it.
Devanagari: Register, Joining, and Brand-Name Phonemes
Hindi sales calls live or die on register. आप (āp) is the formal second-person pronoun — the one you use with a senior decision-maker, a first contact, or anyone whose status you haven't established yet. तुम (tum) is familiar, appropriate between peers or with someone junior (matching the same register distinction that drives multilingual sales calls). An English-first voice AI that translates a generic "you" without parsing context lands on one arbitrarily, and a buyer who's received तुम from an unfamiliar vendor in a first sales call reads it as careless at best, rude at worst.
Beyond pronouns, Devanagari introduces a transliteration challenge that compounds quickly in a sales context. Brand names, product names, and technical terms don't exist natively in the script, and how "Salesforce," "AWS," or your own product name is pronounced and rendered in Devanagari matters — a wrong phoneme breaks the spell of fluency the agent is trying to create. The Hindi outbound sales opener below, rendered in Devanagari with inline English tokens for brand names and product terms, is the pattern that production parity looks like.
Conjunct handling matters too. The Devanagari script joins consonants into ligatures — क्ष, त्र, ज्ञ — that an English-trained model handles poorly. SMS-style confirmations in Devanagari keep the user's script; an agent that drops back to a transliterated render breaks the continuity of the call. Parlo's Devanagari models are trained on real sales-call audio including brand-name pronunciation and conjunct handling, not just clean corpus text.
The transactional support excerpt below — a loyalty-program helpline call from regional scripts — illustrates what this looks like in production. Notice how loyalty IDs, point balances, tier names, and SMS confirmations stay in the user's native script, with English gloss marks on the inline switch tokens like 9842 points, "Indigo Plus Silver", and 24 months.
Arabic RTL: Direction, Mixed-Direction Tokens, and Dialect
Arabic for sales calls is not a single language choice, and it isn't a single-direction problem either. Modern Standard Arabic (MSA) is understood everywhere but sounds formal to the point of stiffness in a live outbound call — it's the register of news broadcasts, not business conversations. Gulf Arabic (the dialect spoken across the UAE, Saudi Arabia, Kuwait, Bahrain, Qatar, and Oman) is the right register for most enterprise sales calls in the GCC. Levantine Arabic covers Syria, Lebanon, Jordan, and Palestine. Egyptian Arabic is widely understood across the region. Picking the wrong dialect signals that the platform didn't think about the buyer's market.
The script-level problem sits alongside the dialect problem. Arabic reads right-to-left, but inside an Arabic sentence, English switch tokens — SKU numbers like SD-90317, place names like Dubai Marina, time references like 10 minutes — stay in their natural left-to-right order. A naive renderer that wraps the whole utterance in dir="rtl" garbles the tokens. A renderer that drops render direction entirely renders the Arabic wrong. Both are wrong.
The Dubai delivery dialog below — from a real retail-desk call on regional scripts — illustrates the shape of the problem. Notice how the caller's address (Sheikh Zayed Road, Tower 4, Apt 1208) stays LTR inside its surrounding RTL body, and how the time tokens (10 minutes, 15 minutes) keep their natural direction while the rest of the sentence flows RTL.
The Genesys-integration reply below — from the sales scripts MENA cold call — shows the same shape inside an enterprise context: the agent's question is rendered in native RTL, the technical terms (Genesys, Parlo, SIP trunk, 70%) are kept LTR, and the bidi markers in the renderer carry the mixed-direction sequence correctly.
How Native-Script Models Handle Bilingual Direction
The architecture that handles script fidelity isn't a separate bidi pass — it's the same single-model inference that code-switching already requires, with render-side training added to the loop. The acoustic model has been trained on Devanagari audio, the language model knows आप vs तुम and Gulf vs MSA Arabic, and the rendering layer emits mixed-direction sequences with the right Unicode bidi markers per token rather than wrapping the whole utterance in dir="rtl" and hoping for the best.
The practical effect is that a Devanagari sales-call conversation and an RTL Arabic sales-call conversation don't run as separate inference pipelines with a translate-back hop on the side. They run on the same model that handles monolingual turns — with the rendering layer doing bidi-correct mixed-direction output as part of the same pass. There's no separate "is the caller mixing scripts?" classifier and no second-pass transliteration step that breaks brand-name phonemes.
Why script fidelity drives conversion and retention: Buyers in Devanagari- and Arabic-speaking markets read a translated-script agent as low-trust within the first five seconds of a call. Production cold-call programs in regional markets show sub-1% abandonment on enterprise Arabic calls served in native-script RTL with inline LTR tokens, against double-digit abandonment on the same cohort when the agent renders the call in translated/transliterated script. The script isn't a surface detail — it's the trust signal on which the entire call is graded.
Where It Matters Most
Script fidelity matters most in the markets native to those scripts. India is the dominant Devanagari market — and not the only one: Tamil, Telugu, Bengali, Marathi, and Gujarati scripts all have their own renders and their own register conventions, and the parity problem applies across the full Indic set. MENA is the dominant market for Arabic in RTL: Modern Standard Arabic plus the three enterprise-relevant dialects — Gulf, Egyptian, and Levantine. Beyond the home markets, diaspora plays a role in the US, UK, and Canada: Hindi-speaking and Arabic-speaking decision-makers whose call fluency is in their native script, not English.
If your enterprise pipeline covers India (Devanagari, plus the parity of Tamil / Telugu / Bengali / Marathi / Gujaradi), MENA (MSA, Gulf, Egyptian, Levantine), or diaspora markets where the buyer operates in their native script, the script fidelity problem is yours. A voice AI that handles the buyer only through English translation is producing a structural disadvantage at the top of the funnel.
Evaluating Vendors for Script Fidelity
When evaluating voice AI vendors for an enterprise script-fidelity deployment — Devanagari, RTL Arabic, or any non-Latin script — the questions to ask are architectural:
- "Is your ASR model trained on native-script audio for the target script — Devanagari, RTL Arabic — or only on transliterated corpus?" — A vendor whose training data is mostly Romanized text hasn't seen the script in audio. Recognition confidence on rendered output drops sharply.
- "Can you render mixed-direction tokens correctly inside an RTL Arabic or LTR English sentence?" — Ask to see an example with both scripts interleaved in the same line. A single
dir="rtl"wrap that breaks the LTR tokens is the wrong architecture. - "What's the recognition accuracy on mixed-direction transcripts vs. clean monolingual Arabic or Hindi?" — A vendor that has to choose between RTL and LTR recognition drops the wrong one inside mixed tokens; ask for the comparison on each.
- "Where did the dialect and register training come from — clean corpus or sales-call audio?" — Dialect selection and register — आप vs तुम, Gulf vs MSA — only calibrate on real call audio. Corpus-clean training sounds off to native buyers.
- "How is brand-name transliteration handled inside Devanagari and RTL output?" — A vendor that defaults to a transliteration table will mangle every brand. The right answer is training on real call audio where the brand gets said correctly.
Script fidelity is the single biggest signal that a buyer gets about whether your voice AI was built to handle their call. It precedes code-switching on the call list, precedes tone, precedes the response speed. It's the first five seconds, and it determines whether the conversation continues.
Parlo's models are trained on native-script audio and multilingual text across 50+ languages. Look at the native-script dialogs — Devanagari with inline English tokens, RTL Arabic with mixed-direction LTR tokens — and compare them to the persona-led sales samples for India and MENA. Try the live demo with your own audio: it handles it natively. Developers: API documentation →
Ready to put script-fidelity-aware voice AI on your enterprise pipeline?
Enterprise rollout or self-serve — pick the path that fits.
Enterprise pilot → Self-serve pilot →Script fidelity — common questions
dir="rtl" on the whole utterance that breaks the LTR tokens is the wrong render. The mixed-direction output is the test case, not the exception.