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:

  1. 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.
  2. 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.
  3. 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.

Hindi outbound sales opener — Devanagari + inline English switch tokens
"नमस्ते ma'am, आपके recent LinkedIn post पर NPS बढ़ाने का जिक्र देखा था — हमारे पास एक ऐसा post-call summary प्रॉडक्ट है जो native Hindi में कॉल का सारांश बनाता है, in 14 Indian languages."

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.

Indigo Cares Mumbai — loyalty helpline (Devanagari extract, dir="ltr")
"आपके अकाउंट में वर्तमान में 9842 points हैं। अगली tier upgrade के लिए आपको 10000 points की जरूरत है।" / "अगला स्तर है "Indigo Plus Silver" — प्राइऑरिटी चेक-इन और एक फ्री सीट अपग्रेड मिलेगा। Congrats in advance!" / "आपके points अंतिम उड़ान के बाद 24 months तक valid रहते हैं।"

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.

Souq Retail Dubai — order-status dialog (RTL Arabic + LTR inline tokens, dir="rtl")
"وعليكم السلام، أرى الطلب SD-90317 وهو الآن مع مندوب التوصيل في منطقة Dubai Marina. هل يمكنك تأكيد عنوان التسليم؟" / "نعم، نفس العنوان المسجّل — Sheikh Zayed Road, Tower 4, Apt 1208." / "عندي سؤال مهم — can it arrive before 6pm? We're prepping for iftar والطلب مهم للعائلة." / "نعم، سيصل قبل الساعة 6 بإذن الله — المندوب الآن على بُعد 15 minutes من عنوانك. سأؤكد له على الأولوية."

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.

MENA cold call — Director of Digital reply (RTL Arabic, dir="rtl")
"شكراً على الاتصال — نحن بالفعل نستخدم Genesys في مركز الاتصال. هل يمكن لـ Parlo التكامل مع بنيتنا الحالية؟" / "بالتأكيد — Parlo sits inside your existing Genesys flow via SIP trunk, وكيلنا الصوتي يتولى 70% من المكالمات الواردة بالعربية و English code-switch, ويصعّد الباقي إلى فريقك."

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:

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