Speech-to-Text for Contact Centers: Which API Handles Call Volume Best?

Self-service interactions cost $0.10–$0.25 per contact. Live agent support runs $6–$12. That's a gap of up to 60x — and it only closes if your speech-to-text for contact centers API handles telephony audio well enough to resolve calls without a human.

You'll often pick STT APIs after watching clean-audio demos. Clean audio doesn't exist in production telephony. Contact center calls run through 8 kHz narrowband codecs. They carry background noise from open-plan agent floors. Callers read back account numbers or policy IDs. When the API can't handle those conditions, calls escalate to live agents.

This article explains what separates a production-ready STT API from a demo performer. You'll learn how telephony conditions degrade accuracy, what concurrency and latency look like at scale, and how to run realistic evaluations before you commit.

Here's what matters most.

• G.711 adds only +0.6 absolute word error rate points for English.
• Reverberation and speaker overlap cause much larger accuracy drops.
• At 40% overlap, WER reaches 34.29% without separation.
• Default streaming concurrency limits often fall below contact center scale.
• Billing granularity can change short-call cost models.

The main problem isn't narrowband telephony by itself. Accuracy usually breaks when narrowband audio arrives with reverberation, overlap, and noise.

Contact center telephony audio operates at 8 kHz narrowband. This removes frequency content above 4 kHz. That bandwidth carries formant information critical for phoneme discrimination.

But codec compression isn't the main problem. A systematic study of telephony perturbations across multiple ASR models found that G.711 adds just +0.6 absolute error-rate points for English. That figure held across weak and strong model tiers. The larger damage came from the acoustic environment. Reverberation added +12 to +25 absolute WER points, depending on model architecture. Far-field microphone conditions pushed one model +65 WER points above its clean baseline.

Speaker overlap is where telephony audio gets punishing. An ICASSP 2025 study measured WER across rising speaker overlap ratios on the LibriCSS corpus. At 0% overlap, WER was 3.80%. At 40% overlap, WER hit 34.29%.

That's roughly 9x the no-overlap baseline. When a speaker separation frontend was applied, average WER dropped from 17.08% to 3.77%. The degradation is acoustically recoverable. But your STT pipeline needs that preprocessing.

Containment often rises or falls on structured data. If the API misses account numbers, member IDs, tracking numbers, or policy numbers, the call usually escalates.

The biggest accuracy gap between STT APIs often appears on alphanumeric input. One misheard digit can force a transfer to a live agent.

At production scale, accuracy alone won't save you. You also need concurrency headroom, workable real-time latency, and pricing that doesn't waste spend on short interactions.

Every STT API enforces default concurrency caps. Those caps often sit below the production contact center scale. A Monday morning spike or a marketing surge can easily double typical concurrency. Enterprise provisioning is the relevant path when that happens. Confirm specific capacity commitments with your provider before you lock in infrastructure plans.

Real-time use cases need fast total pipeline latency, not just fast transcription. Your budget includes ASR, NLU, routing logic, and network transit.

Use cases like agent assist, intent routing, and live sentiment monitoring have tight latency budgets. Your pipeline includes ASR processing, NLU inference, routing logic, and network transit. Each stage adds time. Deepgram's Speech-to-Text API is built for low-latency transcription. That leaves headroom for downstream NLU and routing logic.

If you're routing calls before they reach an agent, every extra millisecond increases misroute risk. Streaming pipelines that process audio as it arrives cut that risk. They don't wait for complete utterances.

Billing granularity can change your cost model fast. Short segments make rounding behavior matter more than teams expect.

Per-minute billing rounds every call segment up. Other billing structures may model short interactions differently. Check Deepgram's scalable voice AI guidance and official pricing documentation before you model current rates and billing structure. Model costs against actual call duration distributions, not average handle time alone.

Clean-audio benchmarks won't tell you much about contact center performance. You need to know how models hold up on noisy, narrowband, multi-speaker calls.

Clean-audio WER benchmarks tell you little about telephony performance. The gap between clean and production accuracy depends on model architecture, training data coverage, and tolerance for acoustic degradation.

One model in the WildASR telephony perturbation study jumped from 6.0% WER on clean audio to 71.0% under far-field conditions. Another went from 3.6% to 5.5% on the same test. That's a 65-point spread in far-field WER between two systems. Clean benchmark scores alone wouldn't predict it. Model selection matters more than the codec. Test candidates on your actual telephony recordings, not vendor-curated samples.

Alphanumeric transcription often decides whether self-service works. If your system misses digits and letters, containment drops fast.

Five9 reported testing Deepgram against alternative STT providers on real-world alphanumeric input. The set included account numbers, member IDs, tracking numbers, VINs, and mailing addresses. Deepgram was reported as 2-4x more accurate on this input category. One healthcare provider using Five9's platform doubled user authentication rates after the switch. Deepgram's Nova-3 model is built for accuracy in challenging conditions.

When a caller reads "Policy ID B-R-7-4-2-9" and the STT returns "B-R-7-4-2-5," the IVR can't match the record. The call escalates. Not elegant, but that's the production reality.

Diarization quality matters because attribution errors break downstream analytics. Raw transcript accuracy isn't enough if the wrong speaker gets the words.

Sharpen used Deepgram across its contact center platform. Adding speaker change detection introduces measurable WER overhead on top of raw transcription accuracy. Test diarization accuracy alongside raw WER. Don't assume a vendor that's strong on general transcription will be equally strong on diarized output.

Default API limits can fail before your contact center reaches full scale. If you don't verify peak behavior early, you may discover the cap during a live spike.

Default streaming concurrency on standard API tiers may fall below contact center production needs. Verify current WebSocket connection limits directly with your provider and official documentation before you design around them. These limits manage shared infrastructure. They weren't designed for a 5,000-seat contact center during open enrollment.

When you exceed your cap, requests get queued or rejected. In a contact center, that can mean dead air or dropped interactions. Large-scale real-time deployments often require purpose-built infrastructure rather than a default API tier.

A spike in call volume doesn't announce itself. Plan your concurrency ceiling for peak traffic, not a normal afternoon average.

Enterprise tiers are about negotiated capacity, not fixed public defaults. For regulated teams, deployment control matters as much as raw concurrency.

Enterprise STT tiers use "starting at" language for concurrency. These are negotiable floors, not hard ceilings. You work with your provider to set limits that match peak volume projections. For regulated industries, deployment flexibility matters as much as raw concurrency.

Deepgram offers cloud, dedicated single-tenant, and self-hosted deployment models. Self-hosted keeps audio within your own infrastructure. That's critical for healthcare and financial services centers. Review Deepgram's scalable voice AI guidance for architecture details.

Compliance certifications and deployment controls vary by provider and model. Confirm specific SOC 2, HIPAA BAA, PCI, and data privacy details through official documentation before you commit.

The fastest way to choose well is to test on your own telephony audio under your own load. Vendor demos and benchmark slides won't tell you how an API behaves in your queues.

Your test set should reflect the audio your production system actually processes. Include samples across these categories:

• 8 kHz narrowband recordings from your telephony system
• Calls with background noise, hold music bleed, and open-plan chatter
• Alphanumeric input sequences: account numbers, policy IDs, zip codes
• Multi-speaker segments with varying overlap ratios
• Accented speech from your actual caller demographics
• Short IVR segments alongside full-length calls

Don't test with vendor-provided sample audio. Don't test with wideband recordings downsampled to simulate narrowband. Use real calls from your production queues. Anonymize them for PII, but keep them acoustically authentic.

Run a phased load test. Start at 100 concurrent connections. Then step up to 500, 1,000, and your projected peak. At each tier, measure both WER and latency. Watch for degradation thresholds where accuracy or response time drops sharply.

If your provider can't support a load test at your projected peak volume, that's the answer. You'll need enterprise provisioning with custom limits or a different provider.

The right choice comes from production fit, not demo quality. Match the API to your telephony conditions, peak call volume, and compliance requirements, then prove it with realistic testing.

Start with your real workload. Then map vendors against those requirements instead of generic benchmark claims.

Map your actual requirements: peak concurrent call count, call duration distribution, real-time versus batch split, and any regulated data types in your audio streams. Then test candidates against those specifics. Deepgram's Audio Intelligence features include sentiment analysis, topic detection, summarization, and compliance monitoring. They add post-transcription analytics without requiring separate ML pipelines.

If you're embedding STT into a CCaaS product, multi-tenant architecture and predictable billing affect your unit economics directly. If you're building a custom voice stack, self-hosted deployment and HIPAA BAA availability may be non-negotiable.

The fastest way to find out whether an API holds up is to test it on your own audio at your own scale. That's less glamorous than a polished demo, but it's much more useful.

Deepgram offers $200 in free credits through the Deepgram Console. That's enough to run a meaningful evaluation against actual call recordings and concurrency patterns. Start building free today.

There isn't one universal threshold. Reverberation, far-field capture, and speaker overlap can change outcomes fast. Validate on production recordings, not clean benchmark scores.

Yes. Most production STT APIs support streaming and batch modes. Batch processing runs asynchronously, while streaming connections stay open and count against your concurrency cap.

Enterprise limits are negotiable floors, not fixed caps. Bring peak concurrent call projections, burst duration, and failover requirements.

Verify SOC 2 Type II, HIPAA BAA availability, and data residency controls. Execute a BAA before you transmit any ePHI.

Misattributed speaker labels corrupt downstream analysis. Test diarized and non-diarized output through your full speech analytics pipeline to measure the trade-off.