Multi-language IVR: detect the caller's language and branch the call
Build a multi-language IVR in Omnifox with the Detect language node: one branch per language, localized Play audio and a DTMF menu for each language.
If you serve customers in several languages, making them listen to a menu in the wrong one is the fastest way to lose them. A multi-language IVR solves this in the first second of the call: it detects the caller's language and branches into a fully localized menu. In Omnifox you build this in the IVR editor (Channels -> Calls) with a Detect language node at the start and one branch per language.
Remember that call nodes require a plan with the calling feature. Let's build it.
The Detect language node goes first
The key to a multi-language IVR is placing Detect language as the first node after entry, before any Play audio. This node opens one branch per language (for example, es / en / pt) plus a fallback exit for the undetermined case.
In a call context, detection relies on two main signals:
- Phone: the number's international prefix (
{{$call.from}}) is a strong hint of the country and therefore the likely language. - Text/speech: if at some point you capture what the caller says (for example with speech recognition), the engine can classify the language of the text, optionally with AI help.
For a cold first contact, the phone prefix is usually enough; keep the fallback branch for when there is no clear signal. When the same customer calls again, the language detected the first time stays associated with the contact, so later calls drop straight into their branch without asking anything.
Base flow of the multi-language IVR
The skeleton is simple and clean:
Entry
-> Detect language
es -> Play audio (ES greeting) -> Wait for DTMF digit (ES menu)
en -> Play audio (EN greeting) -> Wait for DTMF digit (EN menu)
pt -> Play audio (PT greeting) -> Wait for DTMF digit (PT menu)
fallback -> Play audio (bilingual) -> Wait for DTMF digit
Each branch is basically a normal IVR, but with its Play audio in the right language. The Play audio node does multi-language TTS, so you only change the script text per branch and the engine synthesizes it in the proper voice.
Step by step
- Entry. Connect the call's entry node.
Detect language. This is the second node. Define the language branches you serve plus the fallback.- Localized greeting. In each branch, a
Play audiowith the script in that language. Use barge-in so returning callers jump straight to the menu. - Localized menu. After the greeting, a
Wait for DTMF digitwith the same options (1 sales, 2 support, 3 billing) but spoken in the branch's language. - Destinations. Each digit leads to
Transfer to team,Transfer to AI voice agent,Voicemailor aSubmenu, just like a single-language IVR.
Tip: share destinations, don't duplicate everything
You don't have to triple all the logic. The final destinations (teams, voicemail, submenus) are usually the same regardless of language; what changes is the audio the caller hears. A tidy pattern:
- Duplicate only
Play audioandWait for DTMF digitper language. - Have the digits of every branch converge onto the same
Transfer to teamorVoicemailnodes.
That way, if you change a team's strategy tomorrow, you edit it once.
Combine it with AI voice
A powerful variant: instead of (or in addition to) a DTMF menu, send each language branch to Transfer to AI voice agent. The AI voice agent converses in the detected language and resolves simple queries; when it needs to, it transfers to a human. Detect language + AI voice agent = natural multilingual service without dedicated operators per language.
Publishing: TTS audio per language
On publish, Omnifox pre-generates the TTS audio for each Play audio, including all language variants. That means zero synthesis latency on the live call. Every time you tweak a script, republish to regenerate that audio in its language.
Common mistakes and best practices
- Don't forget the
Detect languagefallback: a short bilingual menu rescues anyone who couldn't be classified. - Keep the same option map across languages (1 always sales, 2 always support); it confuses less and lets you converge destinations.
- Translate, don't calque. Each
Play audioscript should sound native, not be a literal translation. - Test one real call per language to confirm detection and audio come out right.
- Start with 2 languages and add more branches once the flow is solid.
- Keep the fallback greeting short. A caller who wasn't classified is already slightly confused, so one concise bilingual line ("For English press 1, para espanol marque 2") beats a long speech.
- Review analytics per language to see which branches carry the most volume and staff the matching teams accordingly.
A well-built multi-language IVR makes every customer feel they reached a local company. You can design it by dragging nodes in the Omnifox call editor: put Detect language first, localize the audio and let the call route itself.
Comentarios (0)
Todavía no hay comentarios. Sé el primero en compartir tu opinión.
Dejá un comentario
Tu email nunca se publica. Los comentarios se moderan antes de aparecer.