What is text to speech for IVR?

Text to speech for IVR converts written prompts into spoken audio played back through an interactive voice response phone system, such as menu options, account balances, or appointment confirmations. Unlike web or app audio, IVR audio must be encoded for narrowband telephony and pass through carrier networks before a caller hears it.

Why does IVR audio sound worse than the same text played on a website?

Phone networks compress audio to 8kHz using codecs like G.711, discarding frequencies above 3.4kHz that TTS models generate audio at. If you do not down-sample and re-encode correctly before deployment, sibilants and consonants smear and callers perceive the voice as muffled or robotic even when the source model is high quality.

Which TTS models work best for IVR and telephony?

Models optimized for low latency and consistent, controlled output tend to perform best for IVR, since prompts are short, repeated, and need to sound identical every time. The right choice depends on your latency budget, language coverage, and whether you need real-time generation or can pre-render and cache static prompts.

Can I use any TTS API directly for a phone system?

Not without a conversion step. Most TTS APIs output 22kHz-48kHz WAV or MP3 by default, which must be down-sampled to 8kHz, encoded to G.711 mu-law or a-law, and checked for correct silence padding and loudness normalization before it will play reliably across every telephony vendor and carrier.

How do you keep IVR prompts consistent when you update or swap TTS models?

Lock the model version per deployed prompt set and re-validate the full prompt library any time a provider updates or auto-migrates a model, since even minor version changes can shift pacing, pronunciation, or loudness in ways callers notice immediately on a phone line.

Back

Jul 1, 2026

Text to Speech for IVR: The Production Guide Nobody Writes

Most teams building a phone system treat text-to-speech as a solved problem: pick a voice, call the API, wire it into the call flow. Then the IVR ships, callers report muffled prompts, mispronounced account numbers, and inconsistent volume between menu options, and nobody can explain why the same model that sounded great on the demo sounds wrong on a live call.

The gap isn't the model. It's everything a phone network does to audio between generation and a caller's ear, and almost every TTS-for-IVR guide skips that part.

Why IVR Audio Is a Different Problem Than Web or App Audio

Web and app audio plays back at whatever sample rate you generate it at: usually 22kHz to 48kHz, full-band, plenty of headroom for detail. Phone networks don't work that way.

Traditional telephony runs on the G.711 codec at an 8kHz sample rate, a narrowband standard built for voice-band frequencies between 300Hz and 3,400Hz, a limitation that traces back to analog phone lines and still defines most carrier infrastructure today, IP-based or not (HOLDCOM, cloud.ax). Generate a prompt at 44.1kHz, hand it to a SIP trunk or PBX without converting it, and you're relying on the carrier's own down-sampling, which is inconsistent across vendors and frequently strips clarity from consonants and sibilants exactly where callers need precision most: account numbers, dates, spelled names.

Get the audio format wrong and it doesn't fail loudly. It just sounds bad, callers hang up or mis-key their input, and the ticket that reaches engineering says "IVR sounds robotic" with no diagnostic path back to the actual cause.

Four Things That Break Between Generation and Playback

Sample rate and codec mismatch. Most TTS APIs default to 22kHz-48kHz WAV or MP3. IVR platforms (Twilio, Amazon Connect, Genesys, Asterisk-based PBX systems) expect 8kHz PCM u-law or a-law, commonly called G.711 (Yeastar). Skip the conversion and you inherit whatever the platform does by default, which varies vendor to vendor.

Silence handling. IVR platforms expect precise silence padding at the start and end of prompts to avoid clipped words or awkward gaps between menu options. TTS models don't generate telephony-aware silence by default. That's a post-processing step, not a model setting.

Loudness normalization. A prompt recorded at -16 LUFS and a prompt recorded at -23 LUFS play back at noticeably different volumes on the same call, and callers notice the jump between "press 1" and the next prompt even when both used the same voice.

Model version drift. IVR prompt libraries are built once and expected to sound identical for years. TTS providers update models on their own schedule. An unannounced model update to your provider's default endpoint can shift pacing or pronunciation across your entire prompt library overnight, with no changelog and no rollback path unless you locked the model version yourself.

What "Production-Ready" IVR TTS Actually Requires

Requirement	Why It Matters for IVR	What Gets Missed
8kHz G.711 encoding	Matches carrier network format	Teams ship native 22kHz+ output uncoverted
Silence padding rules	Prevents clipped or run-on prompts	Treated as a platform setting, not validated per prompt
Loudness normalization	Keeps volume consistent across menu options	Left to default TTS output levels
Model version lock	Prevents pacing/pronunciation drift on updates	No changelog tracking, no re-validation trigger
Pronunciation QA on variables	Account numbers, names, dates read correctly	Only tested on sample scripts, not edge-case inputs
Per-prompt audit trail	Debugging without re-recording everything	No record of which model version generated which file

None of this is exotic. It's the difference between a TTS API call and a validated telephony-audio pipeline, and most teams find out the difference exists only after the IVR is live and complaints start coming in.

Building This Yourself vs. Using an Orchestration Layer

You can build the conversion, validation, and version-locking pipeline in-house: a down-sampling step, a loudness normalization pass, a pronunciation test suite for variables, a changelog tracker for whichever TTS provider you use. Teams do this today. It's also ongoing maintenance work that has nothing to do with your actual product, and it has to be rebuilt every time you add a language, switch providers, or a provider silently updates a model underneath you.

Onepin sits above the model layer specifically to remove this work. It orchestrates output across 100+ TTS models, validates every generated prompt against format, pronunciation, and consistency requirements before it ships, retries automatically when a prompt fails validation, and keeps a version-locked, audited record of what generated every file in your prompt library. You're not locked into one model's telephony quirks, and you're not rebuilding the validation layer from scratch when a provider changes something on their end.

If your IVR prompts need to sound the same on caller 1 and caller 50,000, that consistency has to be engineered. The model alone won't guarantee it.

Get Started

Ready to stop debugging muffled IVR prompts one support ticket at a time? Talk to Onepin about validated, telephony-ready TTS output across every model you already use.

Frequently asked questions

What is text to speech for IVR?: Text to speech for IVR converts written prompts into spoken audio played back through an interactive voice response phone system, such as menu options, account balances, or appointment confirmations. Unlike web or app audio, IVR audio must be encoded for narrowband telephony and pass through carrier networks before a caller hears it.
Why does IVR audio sound worse than the same text played on a website?: Phone networks compress audio to 8kHz using codecs like G.711, discarding frequencies above 3.4kHz that TTS models generate audio at. If you do not down-sample and re-encode correctly before deployment, sibilants and consonants smear and callers perceive the voice as muffled or robotic even when the source model is high quality.
Which TTS models work best for IVR and telephony?: Models optimized for low latency and consistent, controlled output tend to perform best for IVR, since prompts are short, repeated, and need to sound identical every time. The right choice depends on your latency budget, language coverage, and whether you need real-time generation or can pre-render and cache static prompts.
Can I use any TTS API directly for a phone system?: Not without a conversion step. Most TTS APIs output 22kHz-48kHz WAV or MP3 by default, which must be down-sampled to 8kHz, encoded to G.711 mu-law or a-law, and checked for correct silence padding and loudness normalization before it will play reliably across every telephony vendor and carrier.
How do you keep IVR prompts consistent when you update or swap TTS models?: Lock the model version per deployed prompt set and re-validate the full prompt library any time a provider updates or auto-migrates a model, since even minor version changes can shift pacing, pronunciation, or loudness in ways callers notice immediately on a phone line.