Voice AI TTS Selection: Choosing a Production Voice

The decision most enterprise voice AI programmes get wrong is not the platform, the prompt, or the integration architecture. It is the voice.

Buyers evaluate TTS during vendor demos that run on curated audio pipelines: optimal codecs, professionally tuned pronunciation, clean acoustic conditions, and domain vocabulary that has been corrected in advance. The voice sounds natural. The platform is selected. Months later, the deployed agent is serving callers from car parks, landlines, and open-plan offices, reading out product names that were never tested, over a telephony codec that compresses audio in ways the demo never surfaced. The voice that sounded smooth in the demo now clips on plosives, mispronounces the firm name, and adds 350ms of perceptible latency before every sentence.

TTS selection for enterprise production is a multi-axis procurement decision. Naturalness, latency, cost, and language coverage each pull in different directions. The model with the highest naturalness score adds latency. The lowest-cost option lacks accent coverage. The broadest language catalogue does not support the SSML pronunciation depth a regulated enterprise needs. This post is the selection framework for teams committing to a production voice rather than a demo voice, including what to test before signing a contract and how to design for the vendor switch that the current market makes increasingly likely.

This guide is produced by the team behind Dilr Voice -- enterprise voice AI live in 40+ countries. For strategic deployment support see the Dilr Voice product page or our DATS consulting practice.

According to McKinsey's State of AI 2025, 88% of enterprises use AI but only 6% extract material EBIT impact. In enterprise voice AI, implementation quality -- including decisions as specific as TTS voice selection -- frequently determines which side of that gap a programme sits on. The programmes that sustain commercial returns treat voice selection as a procurement discipline, not an aesthetic preference.

Why Does the Demo Voice Always Sound Better Than the Production Voice?

Enterprise TTS demos are optimised for the demo. The vendor presents audio synthesised from short, grammatically clean sentences in studio-grade conditions, using a pronunciation lexicon tuned over time. The voice model is the vendor's largest, highest-quality neural architecture, and there is no telephony compression in the loop.

Production differs in every respect. Calls arrive over PSTN or VoIP connections applying G.711 or G.722 audio codecs that compress speech in ways that flatten the subtle prosodic cues making TTS sound human. Callers ring from environments with background noise -- contact floors, mobile handsets, public spaces -- requiring ASR-layer filtering before the LLM processes intent. The sentences the TTS engine synthesises are not curated; they are dynamically generated by the LLM, often longer and syntactically more complex than demo scripts.

Most critically, the vocabulary is enterprise-specific. A voice AI deployed for a UK housing association will read out street names, postcode areas, and repair-category codes the TTS model was never trained on. An agent for a financial services firm will speak account numbers, regulatory reference codes, and product names requiring phoneme-level pronunciation overrides. The gap between demo-quality pronunciation and production accuracy on domain vocabulary is wider than any MOS (Mean Opinion Score) benchmark would suggest.

The selection implication is direct: test with your vocabulary, over your codec, at your expected call lengths. Everything else is the vendor's best foot forward, not yours.

Understanding how TTS latency compounds across the full voice AI pipeline is covered in our voice agent latency benchmarks guide -- TTS TTFB is one of four additive latency sources that determine end-to-end responsiveness.

The Four Axes of TTS Voice Selection

Enterprise TTS selection cannot reduce to a single quality score. Four axes govern the decision, and each competes against the others.

Axis 1: Naturalness

Naturalness covers prosody (the rhythm, stress, and intonation of speech), expressiveness (appropriate emotional register for the content), and conversational fluency (sounding like dialogue rather than read text). High naturalness requires large neural architectures with strong prosodic modelling, which is why naturalness and latency trade off directly.

For enterprise voice AI, naturalness carries an additional requirement beyond raw sound quality: robustness to domain-specific text. A TTS engine that sounds natural on general English but stumbles on "FCA-regulated advice" or "Category B reactive maintenance" is not production-ready. Test naturalness on your actual call scripts, not vendor-provided samples.

The MOS metric -- Mean Opinion Score -- rates speech on a 1-5 scale under ideal listening conditions. High MOS is a necessary condition for selection, not a sufficient one. A voice scoring 4.3 MOS on general English may score effectively 3.5 on domain-specific enterprise text, because neural TTS models have weaker prosodic modelling on vocabulary outside their training distribution.

Axis 2: Latency (TTFB)

Time To First Byte -- how long before any audio begins streaming after text is submitted -- governs perceived conversational responsiveness. In a voice AI call, every 100ms of added TTFB perceptibly lengthens the pause after a caller finishes speaking. At 300ms TTFB, the pause registers as hesitation. At 500ms, callers interpret it as confusion or system failure.

The enterprise production target is TTFB under 200ms across the full pipeline, which includes LLM inference and TTS synthesis start combined. Achieving this requires streaming TTS, where the engine begins transmitting audio while still synthesising the remainder of the sentence, rather than buffered TTS, which transmits only after the complete utterance is generated. The pipeline architecture that achieves sub-200ms end-to-end response is: LLM begins generating text and immediately pipes tokens to the TTS streaming endpoint; TTS begins synthesising from the first sentence fragment; audio starts playing before the sentence is finished generating. This overlap is how the best enterprise deployments achieve 150-200ms perceived response latency even on complex queries.

Test TTFB under load. Vendor-quoted average latency is measured in ideal conditions. The P95 latency -- experienced on 5% of calls -- is what callers experience on their worst interactions. If P95 TTFB exceeds 400ms, that latency is perceivable as a hesitation and, in regulated contexts (FCA Consumer Duty, NHS patient services), risks being interpreted as confusion by the caller.

Axis 3: Cost

TTS pricing models vary significantly: per character of text submitted, per second of audio output, per API call, or bundled into platform fees. At enterprise call volumes -- 50,000 to 500,000 calls per month -- TTS becomes a meaningful variable cost line. An agent generating an average of 400 characters of spoken text per call at 100,000 calls per month produces 40 million characters monthly. Pricing that appears modest per thousand characters compounds sharply at that scale.

Hidden costs compound further. Premium naturalness voices are priced higher than standard neural voices on most platforms. Custom cloned voices carry one-time training fees plus ongoing per-character premiums. Long SSML documents (with phoneme tags, prosody markup, and break tags) may increase character counts by 15-25% beyond the plain text equivalent, depending on the vendor's billing model.

The detailed breakdown of voice AI total cost of ownership treats TTS as one of the most frequently undermodelled variable cost components in enterprise deployments -- alongside LLM tokens, telephony egress, and transcription.

Axis 4: Language and Accent Coverage

Most TTS vendors claim support for 20-50 languages. The claim obscures the more relevant question: what is the quality of coverage within each language, especially for regional accent variation?

UK English is not a single acoustic space. An enterprise voice AI deployed across a UK contact centre network will serve callers from Scotland, Wales, Northern England, and the South in the same call queue. The TTS output does not need to match each caller's accent, but it must be intelligible and credible across all of them. RP (Received Pronunciation) British English is the standard enterprise default, but its delivery must sound sufficiently British to avoid registering as American-accented, which research consistently shows reduces caller trust in regulated contexts.

For multilingual deployments, quality within a language matters more than the count of languages. A vendor claiming 45 languages with one undifferentiated French model is not the right choice for an EMEA deployment serving Belgian French and Parisian French callers in the same programme.

The cost-per-call economics of TTS sit within the broader AI voice cost per call framework -- which models TTS as one of four variable cost components alongside LLM tokens, telephony, and transcription.

The TTS Vendor Landscape in 2026

Enterprise buyers have more options than at any previous point, and the selection decision is correspondingly harder. The vendor landscape has stratified into three tiers with distinct trade-off profiles.

High-naturalness, latency-sensitive providers -- ElevenLabs, PlayHT, Rime -- prioritise perceptible voice quality and invest heavily in prosodic modelling and emotional expressiveness. ElevenLabs has built market leadership on naturalness, with dedicated streaming endpoints (Eleven Turbo v2, Eleven Flash v2.5) designed specifically for latency-sensitive voice AI applications. These providers offer custom voice cloning at enterprise tier, strong SSML support for pronunciation control, and growing language coverage. The trade-offs: per-character pricing escalates at high volumes, streaming TTFB under telephony conditions can exceed 200ms on complex or long utterances, and data residency options -- critical for UK regulated deployments -- require enterprise-tier negotiation rather than default configuration. ElevenLabs at $11B valuation (February 2026) signals financial strength but also accelerating pricing pressure as revenue targets increase.

Platform-grade, enterprise-SLA providers -- Azure Cognitive Services TTS, Google Cloud TTS (Chirp models), AWS Polly -- offer the infrastructure guarantees regulated enterprise procurement requires: SOC 2 Type II, ISO 27001, HIPAA BAA availability, EU data residency with explicit contractual terms, and SLA-backed uptime with financial credits. Azure's HD Neural voices and Google's Chirp 2 model have closed the naturalness gap with the high-naturalness tier significantly in 2025-2026. These providers support deep SSML including custom lexicons (pronunciation dictionaries exportable in SSRML/PLS format) at the enterprise level. Per-character pricing is competitive at volume. The trade-offs: voice persona customisation is narrower -- you select from a catalogue rather than cloning a unique voice -- and the naturalness ceiling on general prose remains perceptibly below ElevenLabs' top-tier models for shorter conversational sentences.

Latency-optimised newer entrants -- Cartesia, Deepgram Aura -- have built specifically for sub-100ms TTFB in voice AI applications, sacrificing some naturalness for speed. They produce voices that are clear and functional, with narrower expressive range but exceptional TTFB consistency at volume. For high-volume contact centre deployments where TTFB stability matters more than prosodic expressiveness, these are compelling options. Language coverage is narrower than the platform providers, and enterprise compliance infrastructure (SOC 2, data residency, BAAs) is newer and deserves additional diligence.

Our assessment of voice AI vendor consolidation risk is directly relevant here: the consolidation wave reshaping the voice AI stack means enterprise buyers should evaluate TTS vendor stability -- capitalization, client base, pricing trajectory -- alongside voice quality.

The LLM versus scripted voice agent architecture also influences TTS vendor choice: LLM-driven agents generate text variably in length and complexity, making TTFB consistency more important than in scripted deployments where utterance length is predictable and can be pre-warmed.

What Should You Test Before Committing to a TTS Provider?

A procurement evaluation that passes on a vendor demo is not an evaluation. These five tests reveal production behaviour before contract signature.

Test 1: Domain Vocabulary Test

Build a test corpus of 100 terms and phrases specific to your deployment: product names, company names, regulatory terms, street names in your service geography, abbreviations your agents will read aloud, and numbers in the exact format they appear in your CRM data. Run this corpus through each candidate vendor. Score pronunciation accuracy: correct on first pass; correctable with SSML phoneme tag; and uncorrectable.

Any term marked uncorrectable is a production risk. A TTS engine that cannot correctly pronounce your organisation's name -- even with phoneme-level SSML override -- cannot be your production voice. Domain vocabulary failure is the most common TTS failure mode in enterprise deployments and the least visible in vendor evaluations.

Test 2: SSML Depth and Portability

Submit identical SSML to each vendor's API and compare output. Test: <phoneme alphabet="ipa" ph="..."> tag support and accuracy; <break time="Xms"/> precision across values; <prosody rate="X%"> and <prosody pitch="X%"> behaviour; <say-as interpret-as="telephone"> for phone number reading; and <emphasis level="strong"> for compliance disclosures.

Document which SSML features each vendor supports natively versus ignores silently. Silent ignoring of SSML tags is a production risk: your agent sends the tag, receives audio back, assumes the instruction was followed, and serves callers a mispronounced number or incorrectly paced compliance statement with no error surfaced.

Test 3: Streaming TTFB Under Telephony Conditions

Do not test TTFB from a cloud VM co-located with the TTS endpoint. Simulate telephony: route audio through a G.711 codec, apply realistic network jitter (20-80ms), and measure TTFB at P50 and P95 across 200 test calls. The P95 number is what your callers experience on their worst 1-in-20 interactions.

If P95 TTFB exceeds 400ms for typical utterance lengths in your use case, the latency will register as hesitation. In regulated contexts -- FCA Consumer Duty financial services, NHS patient communications -- a hesitation pause before a critical disclosure risks being interpreted as agent uncertainty by the caller, undermining trust and potentially the legal validity of the disclosure.

Our guide to evaluating voice AI accuracy beyond WER covers how production-condition performance diverges systematically from benchmark-condition testing.

Test 4: Long-Form Utterance Quality

Most vendor demos use sentences of 8-15 words. Production voice AI generates utterances of 25-50 words when reading confirmation details, terms-and-conditions summaries, or multi-step instructions. Test how each vendor's prosody holds across long utterances: does the voice maintain natural stress patterns through a 45-word sentence, or does it flatten to monotone at length? Does it appropriately emphasise the most information-dense words, or does stress become random?

Long-form utterance degradation is a consistent differentiator between TTS tiers that short demos never reveal.

Test 5: The Switch Test

Ask each vendor directly before contract signature: what assets are portable if we change providers? Specifically: is our pronunciation lexicon exportable in a vendor-neutral format (PLS, LEXICON, or JSON)? Do our SSML customisations transfer to another vendor without re-testing? Are call recordings, evaluation datasets, and configuration files accessible for download on exit?

The answers reveal the switching cost before lock-in occurs. A vendor unable to answer this question clearly before signature is providing the answer implicitly.

Is TTS Voice Selection a Brand Decision?

The TTS voice is not a technical parameter. For the duration of every call, it is the organisation's voice -- its tone, authority, warmth, and credibility. The selection decisions that follow from this are brand decisions with compliance dimensions.

Gender and age are the most visible choices. Neither should default to convention (female, young-adult) without testing against the actual caller demographic and call purpose. Research consistently shows that perceived voice gender affects caller trust and perceived authority in ways that vary by subject matter and caller age profile. For regulated financial services and healthcare contexts, the voice should signal competence and consistency. For customer service contexts where warmth drives CSAT, different calibration may be appropriate. Test with real callers from your audience, not internal stakeholders.

Accent carries geographic signal. A UK council deploying voice AI for local residents should present a voice that is credible in that region -- not necessarily matching the local accent, but not so markedly different that it registers as foreign. An enterprise deploying nationally should use a neutral voice that is credible across all served regions.

Bias and Equality Act compliance are active considerations, not hypothetical ones. Voice design can inadvertently create bias in how callers perceive decisions made by the agent. A voice associated with youth or informality delivering a regulatory outcome -- a declined claim, a collections prompt, a compliance disclosure -- may face challenge under FCA Consumer Duty's fair treatment obligations or Equality Act 2010 reasonable adjustment duties. Document the voice selection rationale, including alternatives considered and why they were rejected. This documentation is part of the audit trail.

Custom voice cloning -- training a model on recordings of a specific speaker -- creates maximum brand differentiation but maximum lock-in. The cloned voice is exclusive to the TTS vendor who trained it and cannot be transferred. It is also legally a biometric asset: the speaker's vocal pattern is special category data under GDPR Article 9. Our post on voice cloning and deepfake risk for enterprise covers the consent, IP, and compliance obligations that must be fulfilled before a custom voice is trained.

If custom voice cloning is on the shortlist, factor it into the switch cost calculation: the cloned voice stays with the vendor. Moving to another provider means not only rebuilding integrations and pronunciation lexicons but also losing the brand voice asset entirely unless re-training on the new platform is contractually and practically feasible.

How Do You Design Around the TTS Switch Cost Problem?

SSML is described as a W3C standard. In practice, TTS vendor implementations are only partially compatible, and the gaps are precisely where enterprise pronunciation work lives.

The <phoneme alphabet="ipa"> tag -- the IPA-based pronunciation override used to force correct synthesis of domain-specific terms -- is supported by Azure, Google, and partially by ElevenLabs, but each interprets the same IPA string differently for edge cases, particularly for consonant clusters and diphthongs common in British place names and surnames. A pronunciation lexicon validated for Azure TTS cannot be transferred to ElevenLabs without re-testing every entry. At enterprise scale -- a lexicon of 200-400 domain terms -- this represents two to four weeks of QA work.

The <prosody> and <emphasis> tags behave inconsistently across vendors. ElevenLabs prioritises its own voice design system over prosody overrides for some voice models; Azure and Google honour prosody tags more literally for their neural voices. An agent tuned to slow down during a compliance disclosure (<prosody rate="90%">) on Azure TTS may deliver the same disclosure at normal pace after switching to another provider if the prosody tag is honoured differently.

The architectural response is a TTS abstraction layer. The agent's dialogue logic outputs clean text. A thin translation layer applies TTS-specific SSML markup based on the active vendor configuration. The pronunciation lexicon is maintained in a vendor-neutral format -- a structured dictionary mapping each term to its target pronunciation -- and a vendor-specific rendering function applies the appropriate SSML tag syntax for the active provider. Switching TTS vendors then means updating the rendering function and re-running validation against the domain vocabulary test corpus. The prompt, the conversation design, and the pronunciation dictionary remain intact.

This abstraction is also the mechanism that makes voice AI vendor exit tractable rather than operationally catastrophic. A programme built directly against a vendor's proprietary SSML and voice model is not portable. A programme built against an abstraction layer retains its investment when switching becomes necessary.

Stanford AI Index 2026 found fewer than 10% of enterprises have fully scaled any AI capability into production operations. The switch cost problem is one structural reason: programmes that chose for the demo rather than the architecture face rebuilding work when the first vendor choice proves inadequate under production load, and the rebuilding work consumes the organisational momentum that was driving expansion.

Our framework for the enterprise voice AI accuracy evaluation covers how WER benchmarks miss the pronunciation and prosody failures that surface only in production, reinforcing why the five-test pre-commit protocol matters more than demo scores.

Frequently Asked Questions

What TTS Voice Should an Enterprise Choose for a Regulated UK Deployment?

There is no single correct answer, but the selection framework is consistent: prioritise EU or UK data residency with explicit contractual terms first; verify deep SSML support including custom phoneme lexicons; confirm streaming TTFB under 200ms at P95 under telephony conditions; and select neutral RP British English as the default accent for national deployments. Azure Cognitive Services HD Neural voices and Google Chirp 2 both meet enterprise compliance requirements and have sufficient naturalness for regulated applications. Validate against your domain vocabulary before committing.

How Much Does Enterprise TTS Cost at Scale?

TTS is one of the most frequently undermodelled variable costs in voice AI programmes. At 100,000 calls per month with 400 characters of TTS output per call, monthly TTS volume reaches 40 million characters. Pricing across enterprise tiers ranges from approximately GBP 0.80-2.00 per 1,000 characters before volume discounts, producing a monthly TTS cost of GBP 32,000-80,000 at that volume depending on provider and voice tier. Premium naturalness voices and custom cloned voices carry additional premiums. Evaluate at your actual call volume and voice tier, not at starter-tier rates.

Can You Change TTS Provider After Go-Live?

Yes, but the cost depends on how the programme was built. A direct integration against a single vendor's proprietary API and SSML syntax makes switching expensive: plan four to eight weeks of redevelopment and QA, plus pronunciation lexicon re-validation. A TTS abstraction layer reduces switching to two to three weeks of rendering-function updates and validation. Design for portability from day one.

What Is SSML, and Does It Matter for Enterprise Voice AI?

SSML (Speech Synthesis Markup Language) is the annotation format used to control how TTS engines render text -- specifying pronunciation, pace, emphasis, pauses, and number formats. For enterprise voice AI, SSML matters primarily for domain vocabulary: organisation names, product codes, regulatory terms, and addresses that standard neural models mispronounce. Evaluate SSML support by running your actual domain vocabulary through the phoneme tag, not by reading vendor documentation. The gap between documented support and functional support on edge cases is where enterprise deployment surprises occur.

How Do You Handle Pronunciation of Brand Names and Product Codes?

Build a pronunciation lexicon (a structured dictionary mapping each problematic term to its target IPA pronunciation) and maintain it in a vendor-neutral format. Test the lexicon quarterly against production call recordings: mispronunciation rates above 2% for any high-frequency term indicate a lexicon gap. Assign lexicon maintenance as a named responsibility -- it is an operational asset, not a one-time setup step.

Next steps: try the production voice AI platform at app.dilr.ai (free, with credits), book an AI placement diagnostic to scope the right TTS architecture and vendor selection for your deployment, or read our deployment methodology to understand how Dilr.ai manages TTS evaluation and voice tuning in production programmes.

Written by the Dilr.ai engineering team -- practitioners who deploy enterprise voice AI in production across regulated industries. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.