When an enterprise evaluates an STT vendor, the conversation almost always centres on what the system does well. Accuracy on clean benchmarks. Language coverage. API response time. Supported features. The conversation that rarely happens is the one about what low accuracy actually costs when the system goes live on production audio.

This is not a hypothetical. Every contact center that has deployed a general-purpose STT system on Indian telephony audio has experienced it. The WER on the vendor's benchmark was 8%. The WER on production calls from tier-2 cities in noisy environments is 22%. The gap does not show up as a failed deployment. It shows up as a compliance team that keeps finding transcript errors in audits, a CRM with corrupted amount fields, agents who spend more time correcting automated outputs than they saved by having them, and a voice bot that customers abandon at twice the expected rate.

The cost accumulates quietly. By the time it surfaces in a board review, it has already compounded across months of operations.

This post puts numbers on the cost. Not theoretical numbers. Cost categories that map directly to the operational, financial, and regulatory consequences that Indian contact center leaders have encountered when STT accuracy falls below the threshold their use cases require.

The Baseline Problem: Why Production WER Is Not Benchmark WER

Before quantifying cost, the mechanism needs to be clear. The WER a vendor shows you in a benchmark is not the WER your system will produce in production. The gap between these two numbers is the root cause of every cost category in this post.

Indian contact center audio has a specific profile that most STT benchmarks do not test: 8kHz telephony, GSM codec compression, background noise from mobile environments, spontaneous speech with regional dialectal variation, and code-switching between Hindi or a regional language and English within sentences. These conditions exist on the majority of calls in collections, insurance, microfinance, and telecom contact centers across tier-2 and tier-3 India.

When tested on Gramvaani, a dataset of rural Hindi telephony audio that represents real Indian contact center conditions, global STT providers show WER between 26 and 34%. Systems that publish single-digit WER on clean benchmarks. The degradation is not marginal. It is the difference between a system that works and a system that produces corrupted output at scale.

Gnani STT API achieves 22.0% WER on Gramvaani (Standard WER), the lowest in its category on this dataset, compared to 26.4% for Microsoft, 23.4% for Sarvam, 27.5% for ElevenLabs Scribe, and 34.0% for Deepgram Nova. Even at 22%, there are errors. The question is not whether any system produces zero errors. It is whether the error rate is low enough, on the right vocabulary, for the automation built on top of it to function reliably.

For a full analysis of why benchmark WER diverges from production WER on Indian telephony audio, see Speech Recognition in Noisy and Rural India: Why Your STT Fails Where It Matters Most.

Cost Category 1: Compliance Failures and Regulatory Exposure

In regulated industries — BFSI, insurance, telecom — compliance is not a secondary concern. It is an operational constraint that shapes every interaction. STT accuracy failures create compliance exposure in three specific ways.

Missed disclosures in regulatory records. RBI-regulated banks and NBFCs are required to maintain accurate records of customer interactions. IRDAI requires that specific policy disclosures be made and recorded. When the STT system misrecognises or drops words from disclosure language, the transcript does not reflect what was actually said. The compliance record is incomplete. In a dispute or audit, the enterprise cannot produce evidence that the required disclosure occurred.

The cost of a single unsubstantiated compliance violation depends on the regulatory regime and the nature of the violation. For Indian BFSI, penalties for disclosure failures range from regulatory censure to monetary fines to, in severe cases, restrictions on specific business activities. The operational cost of defending against a compliance allegation, including legal fees, management time, and regulatory correspondence, typically exceeds the cost of the underlying penalty.

Consent records that do not hold up. Collections contact centers and outbound voice AI deployments rely on call transcripts as evidence of customer consent: consent to pay, consent to be contacted, consent to specific repayment terms. When STT accuracy on consent language is insufficient, the transcript may show a garbled version of what the customer said rather than the actual consent expression. In a dispute, this transcript is not evidence. It is a liability.

False negatives in automated compliance monitoring. Automated quality monitoring that flags calls for compliance violations is only as reliable as the transcription it runs on. A system with 20% WER on compliance-critical vocabulary will miss violations that occurred on calls where the relevant language was misrecognised. The monitoring program reports a clean compliance rate that does not reflect reality. This false negative is arguably more dangerous than a compliance failure that is detected, because it provides management with false assurance about the compliance posture of the operation.

For a detailed breakdown of the regulatory requirements that STT deployments in BFSI must meet, see Speech Recognition for BFSI: The Accuracy, Compliance, and Language Requirements That Matter.

Cost Category 2: CRM Data Corruption and Agent Rework

The most visible day-to-day cost of low STT accuracy is the impact on data quality and agent time. It manifests in two forms that compound each other.

Corrupted CRM fields from unreliable auto-population. Contact center CRM auto-population extracts structured data from call transcripts: payment amounts committed, next action dates, customer disposition, account identifiers. When STT accuracy on financial vocabulary is insufficient, these fields are populated with incorrect values. Amounts are wrong. Dates are wrong. Dispositions are misclassified.

Consider a collections contact center processing 1,000 calls per day with a CRM auto-population system. If the STT system produces errors on financial vocabulary at a rate of 15%, approximately 150 calls per day will have at least one incorrect field in the CRM record. Over a month, this is 3,000 corrupted records. Over a quarter, nearly 10,000. The downstream consequences cascade: follow-up calls are made on wrong amounts, payment promises are tracked against incorrect figures, dispute resolution draws on data that does not reflect what the customer agreed to.

Agent time spent correcting automated errors. When agents discover that CRM auto-population has produced incorrect fields, they correct them manually. This correction time erodes and eventually eliminates the productivity gain that auto-population was supposed to deliver.

At a conservative estimate, correcting a single incorrect CRM record takes two to three minutes of an agent's post-call time. If 150 calls per day produce incorrect records that agents detect and correct, this is 300 to 450 minutes of agent time per day consumed by error correction. Across a 500-agent contact center, even if only one in five agents encounters an error correction task daily, the aggregate productive time lost is substantial.

The deeper problem is the error correction rate that goes undetected. Agents correct errors they notice. They do not correct errors they do not notice. Amount fields that are wrong but plausible, dates that are off by a day, dispositions that are close but not accurate: these pass through uncorrected and accumulate in the CRM as noise that degrades the quality of every downstream report and workflow that draws on CRM data.

Cost Category 3: Quality Monitoring That Does Not Catch What It Should

Automated quality monitoring is one of the highest-value applications of contact center STT. The ROI case is compelling: replace a manual sampling program covering 2 to 5% of calls with automated coverage of 100% of calls, at a fraction of the cost per call reviewed.

The ROI case only holds if the underlying transcription is accurate enough for the monitoring to produce reliable results. Low STT accuracy corrupts quality monitoring in two directions simultaneously.

False positives that create alert fatigue. When STT accuracy is insufficient, the monitoring system flags calls for violations that did not actually occur: a correctly delivered disclosure that was misrecognised as incomplete, a compliant agent statement that was transcribed in a way that triggers a policy violation rule. Reviewers who see high rates of false positive alerts stop treating alerts as reliable signals. The quality monitoring program becomes background noise rather than an operational tool.

False negatives that miss real violations. More seriously, low accuracy on compliance-critical vocabulary means that real violations pass through undetected. An agent who failed to deliver a mandatory disclosure on a call where the relevant language was misrecognised will not be flagged. The monitoring program reports compliance when non-compliance occurred. This is the worst possible outcome of a quality monitoring deployment: it costs money to operate, gives management false assurance, and fails to catch the violations it was built to prevent.

The combination of alert fatigue and false negatives means that a quality monitoring program built on low-accuracy STT may be worse than no quality monitoring program at all, because it actively undermines the operational processes and management attention that would otherwise be directed at the compliance problem.

Cost Category 4: Voice Bot Abandonment and Customer Churn

Voice bots built on low-accuracy STT fail in a specific, observable way: customers abandon conversations at higher than expected rates, and those abandonment events do not look like technology failures in the data. They look like customer disengagement.

Here is the failure sequence. A customer responds to an outbound collections call or IVR flow. The customer's response involves code-switched Hindi-English speech, a regional accent, or audio from a noisy mobile environment. The STT layer misrecognises the response. The intent detection model receives a corrupted transcript and either misclassifies the intent or fails to classify it at all. The voice bot responds with a clarification prompt. The customer responds again, correctly. The same failure recurs. After one or two failed clarification loops, the customer disconnects.

This abandonment is recorded in the analytics as a dropout, not as a transcription failure. The transcription failure that caused it is invisible unless someone specifically investigates the correlation between STT accuracy and completion rates by call type and geography.

At scale, this failure mode has direct revenue consequences in collections. A collections voice bot with a 60% completion rate on urban calls but a 35% completion rate on rural calls is not delivering the geographic coverage the business case assumed. The 25-point gap in completion rate maps directly to payment promises not made and recoveries not achieved. In a collections book of material size, this difference is measurable in crore-level recovery shortfalls per month.

For a full analysis of how code-switching and noise degrade STT accuracy on Indian telephony audio in the contact center context, see Why Hinglish Breaks Most STT APIs: The Code-Switching Problem in Indian Voice AI and How Speech-to-Text Powers Contact Center Automation Without Burning Agent Productivity.

Cost Category 5: The Compounding Cost of Late Discovery

All four cost categories above share a characteristic that makes their aggregate cost higher than the sum of their individual parts: they accumulate before they are discovered.

Compliance exposure from inaccurate transcripts does not appear as a cost until an audit, a dispute, or a regulatory inquiry surfaces it. By that point, the exposure has been accumulating for months. CRM data corruption does not appear as a cost until a data quality review reveals the extent of the problem. Quality monitoring failures do not appear as a cost until a compliance event reveals that the monitoring was not actually catching violations. Voice bot abandonment rates appear immediately in the analytics, but the STT root cause is often not identified until someone does the investigation.

The common pattern across enterprises that have deployed STT on Indian contact center audio without adequate pre-deployment validation is a 90 to 120 day window during which the system appears to be working, automated reports show acceptable metrics, and the real failure modes are accumulating invisibly. The cost at the point of discovery is the cost of months of compounded errors plus the remediation cost: re-annotation of CRM records, compliance remediation, vendor replacement, and the sunk cost of the automation stack built on top of the wrong transcription foundation.

This is why pre-deployment validation on production audio matters not just as a procurement best practice but as a cost avoidance mechanism. For a complete methodology on how to evaluate STT systems on Indian contact center audio before going live, see How to Benchmark a Speech-to-Text API on Indian Languages Before You Sign Anything.

What the Right Accuracy Threshold Actually Is

The question every contact center buyer should be asking is not "what WER does the vendor publish?" It is "what WER do I need on my audio for my use cases to function reliably?"

The answer varies by use case. Post-call speech analytics for topic and sentiment analysis can function with WER up to 12% on production telephony audio if errors are randomly distributed. CRM auto-population of financial fields requires below 8% WER with specific accuracy on domain vocabulary. Compliance monitoring requires below 8% WER on disclosure and consent language specifically, which means domain fine-tuning is mandatory, not optional. Voice bot intent detection requires WER low enough that the entity and intent vocabulary is preserved, which in Indian telephony conditions means below 15% WER at minimum and significantly lower for financial use cases.

The threshold is not a single number. It is a use-case-specific requirement that must be tested on your audio before you build automation on top of it.

For a plain-English explanation of how WER is calculated and how to interpret benchmark numbers in the context of your deployment, see What Is Word Error Rate? The Only STT Accuracy Metric That Actually Matters. For the full evaluation framework including diarization accuracy, confidence score calibration, and latency testing alongside WER, see Speaker Diarization, Confidence Scores, and Latency: The STT Metrics Buyers Ignore Until It's Too Late.

Frequently Asked Questions

1. ‍What is the real cost of low STT accuracy in a contact center?Low STT accuracy creates cost across five categories: compliance failures and regulatory exposure from inaccurate transcript records, CRM data corruption from unreliable auto-population, agent rework time spent correcting automated errors, voice bot abandonment from failed intent detection, and the compounding cost of late discovery when these problems surface months after deployment. The aggregate cost typically exceeds the cost of the STT system itself by an order of magnitude.‍
2. What WER is acceptable for contact center automation in India?It depends on the use case. Speech analytics tolerates up to 12% WER. CRM auto-population of financial fields requires below 8%. Compliance monitoring requires below 8% WER specifically on disclosure and consent vocabulary. Voice bot intent detection requires below 15% WER at minimum, lower for financial vocabulary. All thresholds must be measured on production telephony audio, not on clean benchmarks.‍
3. Why does STT accuracy degrade on Indian contact center audio?Indian contact center calls involve 8kHz telephony audio with GSM codec compression, code-switching between Hindi or regional languages and English within sentences, background noise from mobile environments in tier-2 and tier-3 cities, and spontaneous speech with regional dialectal variation. These conditions degrade WER by 15 to 30 percentage points compared to clean benchmark conditions for systems not specifically trained on this audio profile.‍
4. How does low STT accuracy cause compliance failures in BFSI?Inaccurate transcripts create three compliance risks: disclosure language that is misrecognised produces incomplete regulatory records, consent expressions that are misrecognised produce consent records that cannot be relied upon in a dispute, and automated compliance monitoring running on inaccurate transcripts produces false negative results that give management false assurance about compliance posture.‍
5. How do I know if my contact center STT is accurate enough before going live?Build a test set from your own production audio, segment it by audio quality, and calculate WER per language and per audio condition using ground truth transcripts annotated by native speakers. Test specifically on domain-critical vocabulary. Run the benchmark on the same audio across multiple vendors and compare degradation deltas from clean to noisy conditions. Do not rely on vendor-supplied benchmarks. For the complete methodology, see the Gnani STT benchmarking guide.‍
6. What is the difference between WER on a benchmark and WER in production?Benchmark datasets like Kathbath Clean use controlled 16kHz audio from speakers in structured conditions. Production Indian contact center audio is 8kHz telephony with noise, code-switching, and dialectal variation. The WER gap between these two conditions is 15 to 30 percentage points for most providers. ElevenLabs Scribe, for example, achieves 9.3% WER on Kathbath Clean (Standard WER) but 27.5% WER on Gramvaani, a rural Hindi telephony dataset. This inversion — best on clean, worst on real-world — is the most dangerous scenario for an enterprise that evaluates on benchmarks and deploys on production audio.