Contact centers experience average annual agent turnover of 40–45%, reaching up to 60% in high-stress sectors such as financial services and healthcare, with replacement costs running $10,000 to $20,000 per departing agent. That math makes voicebots one of the most compelling cost levers in the operation, but most contact center modernization projects treat the voicebot as a single application rather than a stack of interdependent layers. The result is a bot that performs cleanly in a controlled pilot, then degrades when it encounters a non-native speaker, a noisy open-plan office, or a telephony codec stripping high-frequency consonants.
The bottleneck is almost always the speech-to-text layer. Get that layer right and the downstream systems follow. Get it wrong and every QA score, coaching note, and CRM entry that depends on the transcript inherits the error.
Core components of modern voicebot architecture
A voicebot is a layered pipeline where each component depends entirely on the speed and accuracy of the layer below it. If the STT engine is slow, the LLM waits, the TTS waits, and the caller experiences an unnatural pause that destroys the illusion of conversation. If the STT engine is inaccurate, the LLM receives garbled input, the bot responds to the wrong intent, and the call escalates to a live agent, registering as a containment failure.
The architecture itself is straightforward: audio enters via SIP trunk or WebRTC, the STT layer transcribes in real time, an LLM interprets the text and generates a response, and TTS synthesizes the reply. The caller's audio arrives as a stream of small packets (typically 20ms each), passes through a media server, and forks to the AI processing layer. The fastest implementations stream LLM output to TTS in sentence-sized chunks so playback begins while the model is still generating.
Voicebot, IVR, and agent roles compared
Traditional IVRs are menu trees. They accept only DTMF keypad input or tightly constrained voice commands and break immediately when a caller deviates from the expected path. Modern voicebots understand natural language intent, handle open-ended queries, and escalate contextually when they reach the boundary of their capability.
| Capability |
Traditional IVR |
Modern voicebot |
Live human agent |
| Input handling |
DTMF / fixed commands |
Natural language, open-ended |
Unconstrained |
| Language support |
Single or limited |
Multilingual with code-switching |
Agent-dependent |
| Post-call data output |
Call log only |
Full transcript, entities, sentiment |
Manual note entry |
| Setup complexity |
Low (flow builder) |
Medium (STT + LLM + TTS integration) |
High (recruitment, onboarding) |
Voicebot roles in call routing
Before a call reaches a live agent, the voicebot serves a critical second function: intent capture and intelligent routing. A voicebot that accurately identifies the caller's intent in the first 30 seconds can route the call to the right queue on the first attempt, eliminating the misrouting that drives transfer rates up and customer satisfaction (CSAT) scores down. High-accuracy STT is the prerequisite for this. If the bot mishears "account cancellation" as "account activation," the routing logic fires correctly against the wrong intent, and the caller lands in the wrong queue before the agent has said a word.
The role of STT in real-time call automation
Real-time transcription is the sensory input for every decision the voicebot makes. Without accurate text arriving fast enough to match conversational pace, the downstream AI has nothing reliable to act on. The STT engine is not a supporting component. It is the bottleneck that sets the ceiling for everything above it, across the full pipeline from audio capture to CRM output.
Instant transcription for phone agents
Real-time STT powers two distinct workflows in the contact center. In a fully automated voicebot, the bot is the only agent on the call and STT drives every response. In an agent-assist workflow, the STT layer transcribes the live conversation alongside a human agent and surfaces knowledge-base suggestions, compliance flags, and sentiment alerts in real time on the agent's screen. Both workflows share the same latency requirement: the transcript must be fast enough that the response feels immediate, whether you're routing audio via Twilio's WebSocket interface or the Amazon Connect real-time path for AWS-based deployments.
Reducing delays in voicebot flows
When the STT layer returns transcripts too slowly, the voicebot and the caller speak at the same time. The caller finishes a sentence, the bot is still processing the previous turn, and it begins responding while the caller has already started the next sentence. This overlapping speech is the clearest signal to a caller that they are talking to a machine, and it drives abandonment faster than any other interaction failure. Managing this requires the STT layer to return partial transcripts fast enough that the bot can detect end-of-utterance and begin formulating a response before the conversational pause has expired.
Minimizing STT latency for real-time voicebots
Latency in a voicebot pipeline is the cumulative sum of four sequential steps: STT processing time, network transit to the LLM, LLM token generation time, and TTS synthesis. Each step competes for the same narrow window between when the caller stops speaking and when they expect to hear a response.
Latency thresholds for natural voicebots
Human conversational pauses average 200ms to 300ms, per Stivers et al.'s cross-linguistic turn-taking study across ten languages (PNAS, 2009). The International Telecommunication Union's G.114 recommendation sets the threshold for high-quality real-time voice traffic at less than 150ms one-way end-to-end delay, with delays between 150ms and 400ms described as acceptable and anything above 400ms creating unacceptable quality for interactive communications.
For a voicebot operating within those constraints, production systems typically target a final transcript in under 300ms, with partial transcripts (the incremental output the voicebot uses to detect end-of-utterance before the speaker has finished) arriving fast enough to avoid cutting off the caller. Solaria-1 delivers those partials under 103ms (p95). Per our STT latency measurement methodology, time-to-first-byte is approximately 270ms and the final transcript arrives at approximately 698ms. WebSocket maintains a persistent bi-directional TCP connection, avoiding the per-request connection overhead that makes HTTP REST unsuitable for real-time voicebot audio streaming. Solaria-1 is the model for real-time streaming. Solaria-3 is async-only and should not be used in real-time voicebot pipelines.
How latency impacts bot performance
The ITU-T G.114 standard treats one-way delays under 150ms as high quality, 150ms to 400ms as acceptable, and anything above 400ms as unacceptable for interactive voice. Applied to total pipeline latency, that tolerance collapses fast: once STT, LLM, and TTS combined push past the acceptable band, research on conversational delay confirms that gaps and overlapping speech increase measurably. Callers begin re-initiating turns before the bot has responded, which compounds the latency problem by injecting new audio into an already-queued pipeline, with measurable downstream effects on CSAT and abandonment rates in production contact center deployments.
Defining STT accuracy for reliable QA scoring
Latency determines whether the voicebot sounds natural. Accuracy determines whether it works. For post-call QA automation, CRM synchronization, and coaching scorecard generation, the transcript is the only record of what happened on the call. If the transcript is wrong, everything built on it is wrong.
Accuracy thresholds for production voicebots
Lab benchmarks measure clean audio recorded in controlled conditions. Production telephony is a different environment. Telephony codecs like G.711 encode audio at 8 kHz, stripping the high-frequency consonant information that helps a model distinguish similar-sounding words. A model that scores well on a clean academic corpus can degrade substantially on contact center audio recorded over VoIP, where background noise, codec compression, and spontaneous speech patterns compound against each other.
The table below shows how production audio conditions affect accuracy:
| Audio condition |
Representative WER range |
QA automation reliability |
| Solaria-1 on real customer English audio |
12.9% WER |
Moderate |
| Solaria-3 on real customer English audio |
9.6% WER |
High |
| Contact center audio with background noise |
Higher degradation |
Unreliable without a production-tuned model |
For European contact center audio, Solaria-3 ranks #1 against AssemblyAI, ElevenLabs Scribe v2, Deepgram Nova-3, Mistral Voxtral, and Speechmatics on real customer recordings, including on Earnings22, a publicly-available earnings call benchmark where it is the only provider to clear the 7% accuracy threshold. These are async workflows: Solaria-3 processes post-call recordings at approximately 60 seconds per hour of content, not in real time.
Maintaining accuracy across accents and noise
Regional accents and dialects create a compounding problem for models trained primarily on American English. A model that handles a US-based caller at acceptable accuracy can degrade substantially on the same content delivered with a strong regional British, Indian, or Southeast Asian accent. For BPO operations serving customers across multiple regions, this degradation means the QA scoring framework produces systematically different reliability across sites without anyone noticing until coaching scores start diverging.
Solaria-3 is specifically trained on noisy, fast-paced, conversational business audio and delivers 26% higher accuracy than Solaria-1 on real English customer recordings. That improvement reflects the difference between a model optimized for broad-language coverage and one optimized for the specific acoustic conditions of European contact centers, including open-plan floor noise and G.711 codec distortion, which are conditions that compound across the language-diverse regions most BPO operations serve.
Transcription gaps and FCR performance
A high word error rate on a 5-minute call produces a meaningful cluster of incorrect words, and those errors concentrate on exactly the words that matter most: product names, account numbers, phone numbers, and compliance phrases. A wrong account number sends the resolution flow to the wrong record. A missed disclosure fails a compliance audit. A misheard phone number means the callback never lands.
Because compliance audit cycles typically run on weekly or monthly review schedules, a transcription error from a call processed today can surface as an audit flag weeks after the interaction, at which point the original audio may be the only way to reconstruct what was actually said.
This is where transcription accuracy ties directly to FCR. If the entity extraction layer pulls a wrong account ID from a degraded transcript, the voicebot resolves the call against the wrong account and the customer calls back. That callback registers as a failed FCR event on a supervisor's scorecard, and the root cause, a bad transcript, is invisible in the system.
Reducing cost per contact with voicebots
Live agent calls typically run $12 to $20 per interaction in fully-loaded cost, according to Gartner, MetricNet, and Forrester customer service benchmarks, factoring in agent wages, software, telecom, overhead, and idle time. Voicebot automation changes that math structurally, and the STT layer is what determines whether that automation holds up at production scale or collapses under real call conditions.
Optimizing voicebot deflection metrics
A voicebot that successfully resolves a billing inquiry, order status check, or account balance query without transferring to a live agent eliminates the entire labor cost of that call. Containment rate is the metric: the percentage of calls the voicebot handles to resolution without a live agent transfer. Every percentage point of containment improvement at scale represents a meaningful reduction in cost per contact.
Containment rate is influenced by several factors, such as intent taxonomy coverage, knowledge base depth, and transactional capability, but STT accuracy sets the floor for all of them. If the voicebot mishears the caller's intent, the downstream intent detection layer receives corrupted input regardless of how well the rest of the pipeline is tuned, and the caller either abandons or requests a transfer. High-accuracy STT on the names, numbers, and phrases that drive routing decisions is a prerequisite for the other containment levers to function reliably.
How voicebots lower cost per interaction
Our Growth plan real-time transcription runs as low as $0.25 per hour, with all audio intelligence features included in that base rate: diarization (post-call, async), sentiment analysis, named entity recognition, translation, and summarization.
For teams evaluating the build-vs-buy tradeoff on self-hosted models, the operational reality is that self-hosted setups typically produce word error rates above 10% in production on real telephony audio and require significant infrastructure and engineering resources to maintain at contact center scale.
Scaling automation without breaking SLA
Gravite, a French CCaaS quality-monitoring platform, cut call quality review time by 93%, from approximately 15 minutes to 1 minute per call, while processing 50,000 hours of audio per year through our API. Their team chose us specifically for French-first accuracy, European data sovereignty, and Solaria-3's production performance on telephony audio. This enabled full call coverage at scale without the manual review bottleneck.
Aircall demonstrates the infrastructure case at higher volume: they cut transcription time by 95% (from 30 minutes to 1.5 minutes per call) and now process over 1 million calls per week through our API, powering search, AI summaries, sentiment, agent coaching, and CRM webhooks from a single integration.
The table below summarises the measured outcomes from both deployments.
| Metric |
Before |
After |
| Call quality review time (Gravite) |
~15 minutes per call |
~1 minute per call (93% reduction) |
| Audio hours processed per year (Gravite) |
Manual sampling only |
50,000 hours at full coverage |
| Transcription time per call (Aircall) |
~30 minutes |
~1.5 minutes (95% reduction) |
| Weekly call volume handled (Aircall) |
Fragmented pipeline |
1M+ calls per week |
| Integration time to production |
Days to weeks |
Under 24 hours (customer-reported) |
What to evaluate in a voicebot STT provider
Running an RFP for a contact center technology stack typically takes 6 to 18 months. These criteria are designed to focus the evaluation on what actually determines production performance.
Testing STT with live call data
No vendor benchmark is a substitute for your own audio. Models are often evaluated on clean lab recordings that share nothing with production telephony conditions. Bring your own noisy, accented, multilingual call recordings to the evaluation and test every provider on that material.
We built a blind ELO-ranked comparison tool that lets you test your own audio and compare Gladia, Deepgram, AssemblyAI, ElevenLabs, Speechmatics, and Mistral without knowing which provider returned which transcript until you score them. For serious evaluation, we do recommend running your audio on a reproducible benchmark before you commit. The current leaderboard reflects community-validated rankings across real-world audio conditions. Rankings move as new audio is tested, so use the tool on your own recordings rather than relying on any vendor's published benchmark. The test methodology is transparent and reproducible.
Deploying voicebots in existing stacks
The integration path matters as much as the model quality. Our lightweight Python and JavaScript SDKs connect via REST (async) or WebSocket (real-time), with pre-built connectors for Twilio, Vonage, Telnyx, LiveKit, Pipecat, and Vapi. Multiple customers are live in production in under a day, whether migrating from Deepgram, migrating from AssemblyAI, or starting fresh with direct access to our engineers on Slack rather than a ticket queue.
Governance requirements for voice data
Voice recordings qualify as personal data under GDPR Article 4, and processing them through an uncertified API creates direct financial exposure. For enterprise and regulated use cases, the recommended baseline includes SOC 2 Type II, ISO 27001, HIPAA, and GDPR, plus PCI DSS documentation for any workflow touching cardholder data, alongside a signed Data Processing Agreement specifying processing purposes, data types, retention duration, and protection obligations.
We run on dedicated cloud clusters across EU and US regions. The model training question is the one most often buried in vendor terms of service. On our Growth and Enterprise plans, customer data is never used for model training by default. On the Starter plan, data can be used for training by default, so teams handling sensitive audio should move to Growth and verify the certification scope, DPA terms, and regional data residency options before signing.
Budgeting for STT at scale
The most common pricing surprise in contact center STT evaluations comes from unbundled feature fees. A competitive-looking base rate expands significantly once diarization, sentiment analysis, translation, and entity extraction are each priced as separate line items. At Gravite's volume of 50,000 hours per year, each $0.02/hour add-on costs an additional $1,000 annually. Stack five of them and that is $5,000 in annual variance on features most production QA pipelines require.
On our Starter and Growth plans, diarization (async), sentiment analysis, named entity recognition, translation, summarization, and code-switching are all included in the base rate. The per-hour rate is the rate you pay, with no add-on stacking, across both real-time and async workflows at any call volume.
Start with €50 in free credits and have your integration in production in less than a day.
FAQs
What is the maximum latency allowed for a real-time voicebot STT layer?
The 300ms target is a total pipeline budget, STT, LLM, and TTS combined, not a requirement on the STT layer in isolation. The STT layer's contribution to that budget needs to be small enough to leave headroom for the downstream steps. Partial transcripts are the key STT-specific target and the voicebot uses them to detect end-of-utterance before the full transcript is ready. Solaria-1 delivers partials under 103ms (p95), a TTFB of approximately 270ms, and a final transcript at approximately 698ms. The ITU-T G.114 recommendation sets 150ms as the threshold for high-quality real-time voice, with 150ms to 400ms acceptable and anything above 400ms unacceptable for interactive communications.
Does Gladia support real-time speaker diarization?
No. Speaker diarization is powered by pyannoteAI's Precision-2 model and is available strictly in asynchronous, post-call workflows. For live calls, speaker attribution should be handled in post-processing for maximum accuracy.
Are customer audio files used to train Gladia's models?
On Growth and Enterprise plans, customer data is never used for model training by default, with no opt-out action required. On the Starter plan, data can be used for training by default, so teams handling regulated or sensitive audio should use Growth or Enterprise.
What is the cost of Gladia's real-time transcription?
Real-time transcription starts at $0.75/hr on the Starter plan (pay-as-you-go, with a one-time €50 in free credit) and drops to as low as $0.25 per hour on the Growth plan, with all audio intelligence features included in the base rate. Diarization is post-call/async only.
Key terms glossary
Word Error Rate (WER): The standard metric for measuring speech recognition accuracy, calculated by dividing the sum of insertions, deletions, and substitutions by the total number of words spoken. Lower is better.
Diarization Error Rate (DER): The metric used to evaluate speaker diarization performance, measuring the percentage of call time attributed to the wrong speaker. Critical for QA workflows where agent and customer statements must be distinguished.
Code-switching: The practice of alternating between two or more languages within a single conversation. Our Solaria-1 model detects language changes automatically mid-utterance without requiring a session restart.
First Call Resolution (FCR): The percentage of customer issues resolved during the initial interaction without requiring a follow-up call. Directly affected by STT accuracy at the entity extraction and intent recognition stages.
Containment rate: The percentage of calls a voicebot handles to a resolution outcome without transferring to a live human agent. Calculated as (calls resolved by voicebot / total calls entering voicebot) x 100. STT accuracy directly influences this metric by enabling correct intent detection and entity extraction.
WebSocket streaming: A persistent, bi-directional TCP connection protocol used for real-time audio streaming to an STT API. Avoids the per-request connection overhead of HTTP REST, making it the required connection method for real-time voicebot architectures.
