Most contact center STT conversations start with the wrong question. Teams evaluating speech recognition ask which vendor is most accurate, what languages are supported, and what the pricing looks like. Almost no one asks which transcription mode they actually need before they start comparing systems.

That omission matters because real-time transcription and batch transcription are not the same product with different speeds. They have different accuracy profiles, different infrastructure requirements, different cost structures, and they serve fundamentally different use cases. Choosing the wrong mode does not just create a technical problem. It creates a deployment that does not do what the business needed it to do.

This guide explains what each mode is, where each one fits, and how to make the right call for your contact center before you commit to an architecture.

What Real-Time Transcription Actually Means

Real-time transcription, also called streaming transcription, processes audio as the speaker talks and returns text with minimal delay. The audio is sent to the STT system in small chunks over a persistent connection, typically using WebSocket protocol, and partial transcripts are returned incrementally as each chunk is processed.

The critical metric is latency: the time between a word being spoken and that word appearing in the transcript. For real-time transcription to be genuinely useful in live voice applications, this gap needs to be short enough that downstream systems can act on the text while the conversation is still in progress.

The production-ready threshold is P95 latency under 200ms. P95 means that 95% of all transcription events complete within that window. Gnani STT API achieves P95 latency under 200ms in streaming mode, which is the threshold below which real-time agent assist and voice bot applications can function reliably without introducing perceptible lag into the conversation.

Real-time transcription is not a single-accuracy-setting system. Most streaming STT implementations produce provisional transcripts, partial outputs that are updated as more audio context becomes available, and then a final transcript once the speech segment ends. Provisional transcripts are faster but less accurate. Final transcripts are more accurate but arrive slightly later. The architecture of your application determines which you use and when.

What Batch Transcription Actually Means

Batch transcription processes completed audio recordings after the conversation has ended. You submit a file or a set of files to the STT API, and the system returns completed transcripts, typically within seconds to minutes depending on file length and system load.

Because batch transcription has access to the full audio before producing output, the language model can use bidirectional context: it knows what came before and after each word before committing to a transcription. This produces meaningfully higher accuracy than streaming transcription on equivalent audio, particularly for noisy audio, heavily accented speech, and code-switched sentences where context is the primary disambiguation mechanism.

Batch transcription is also simpler to implement. There is no persistent WebSocket connection to maintain, no partial transcript state to manage, and no latency-sensitive infrastructure to provision. You send audio, you receive text. For teams starting their first STT deployment, batch is almost always the right entry point.

The Accuracy Trade-Off Between Modes

The accuracy gap between real-time and batch transcription is not trivial and is worth understanding before you design your architecture.

In streaming mode, the STT system processes audio in short windows, typically 20 to 100 milliseconds per chunk, and must produce output with limited future context. On clean audio with a single speaker speaking standard vocabulary, this constraint has a modest impact on accuracy. On noisy audio, code-switched speech, or audio with heavy dialectal variation, the language model's inability to look ahead increases word error rate meaningfully.

In practice, for Indian contact center audio, the WER difference between streaming and batch mode on the same audio is typically 2 to 5 percentage points. That gap closes when the system has been specifically trained on telephony audio and code-switched speech, because a model that has learned the patterns of real Indian contact center speech can make better predictions from partial context. But the gap does not close to zero.

For use cases where accuracy is the primary requirement and latency is not a constraint, batch transcription is the right choice. For use cases where the value depends on the transcript being available during the call, real-time is necessary regardless of the accuracy trade-off.

For a full understanding of how WER is measured and what the numbers mean for your specific deployment, see What Is Word Error Rate? The Only STT Accuracy Metric That Actually Matters.

Which Use Cases Need Real-Time

Three contact center use cases genuinely require real-time transcription. If your deployment does not include at least one of these, you almost certainly do not need streaming mode.

Live agent assist.
‍ A system that surfaces relevant information, suggested responses, or compliance alerts to an agent during a call must process the transcript in real time. If the transcript arrives after the call ends, the assist value is zero. Real-time transcription is non-negotiable here, and P95 latency under 200ms is the minimum spec for the application to feel responsive rather than lagged.

Real-time compliance monitoring.
Some BFSI and insurance deployments require that specific disclosures be made during a call, and that the system flag or alert supervisors if those disclosures are missed or delivered incorrectly. This monitoring must happen during the call to be actionable. A post-call alert that a disclosure was missed is useful for training. A real-time alert is useful for intervention.

Voice bot and conversational AI.
‍ Any deployment where a voice bot is conducting the conversation, rather than a human agent, requires real-time transcription as the input layer. The bot must understand what the customer said before it can respond. The end-to-end latency of the voice bot response, which includes STT transcription, NLU processing, response generation, and TTS playback, must be short enough that the conversation feels natural. STT latency is the first link in that chain.

If your use case is live agent assist or voice bot, real-time transcription with a P95 latency spec is a hard requirement. Everything else is secondary.

Which Use Cases Are Better Served by Batch

The majority of contact center STT use cases are post-call, and for all of them batch transcription is the better choice.

Post-call quality monitoring.
Reviewing calls for agent performance, script adherence, and customer experience scoring does not require the transcript before the call ends. Batch transcription gives you higher accuracy, simpler infrastructure, and lower cost for this use case.

Compliance review and audit trails.
Transcribing calls for regulatory record-keeping, dispute resolution, or compliance audit does not have a real-time requirement. Accuracy matters more than speed. Batch is the right mode, and the higher accuracy on noisy or code-switched audio is particularly valuable for BFSI deployments where every word in a disclosure statement needs to be captured correctly. For a full breakdown of speech recognition requirements specific to BFSI, see Speech Recognition for BFSI: What Indian Banks and NBFCs Must Verify Before Going Live.

Speech analytics at scale.
‍ Running topic detection, sentiment analysis, intent classification, and call categorisation across thousands of calls per day is a batch operation. The analytics pipeline ingests completed transcripts and processes them asynchronously. Real-time transcription adds cost and complexity without adding value to this use case.

Agent coaching and training.
Call review for coaching purposes is done after the call. Batch transcripts, with their higher accuracy, produce better coaching material than streaming transcripts.

How Noise and Code-Switching Factor In

The choice between real-time and batch is not purely a use case decision. The audio profile of your calls should factor into it as well, particularly for Indian enterprise deployments.

Noisy telephony audio and code-switched Hindi-English speech are the two conditions that most increase the accuracy gap between streaming and batch mode. If your deployment involves calls from rural regions on mobile connections, agents and customers who code-switch between Hindi and English within sentences, or audio with background noise from contact center environments, the accuracy penalty of streaming mode is larger than it would be on clean wideband audio.

For deployments that must use real-time mode despite these audio conditions, the relevant question to ask your STT vendor is whether their streaming model was trained on telephony audio specifically, not just downsampled from a wideband model. A streaming model trained on clean audio that encounters 8kHz GSM telephony in production will show higher WER than one trained on the actual audio profile it is handling.

For a detailed analysis of how noise degrades STT accuracy and what the benchmark numbers look like on real Indian telephony audio, see Speech Recognition in Noisy and Rural India: Why Your STT Fails Where It Matters Most.

A Simple Decision Framework

Before choosing a transcription mode, answer three questions.

Does the business value of the transcript depend on it being available during the call? If yes, you need real-time. If no, use batch.

What is the audio quality profile of the calls you are transcribing? If your calls involve noisy telephony, code-switching, or dialectal variation, factor in the additional accuracy cost of streaming mode and confirm your vendor's streaming WER on equivalent audio.

What is your team's infrastructure capability? Real-time streaming requires WebSocket connection management, partial transcript handling, and latency-sensitive provisioning. Batch requires none of this. For a first deployment, the operational simplicity of batch is a significant advantage.

Most contact centers are best served by starting with batch transcription for post-call analytics and quality monitoring, validating accuracy on their actual audio, and then layering in real-time transcription for specific live use cases once the baseline is established.

Frequently Asked Questions

Is real-time transcription less accurate than batch?
‍ Generally yes, by 2 to 5 percentage points WER on equivalent audio. Batch transcription has access to full audio context before producing output, which improves accuracy on noisy audio, code-switched speech, and domain-specific vocabulary. The gap narrows on clean audio and with models specifically trained on telephony speech.

What latency do I need for live agent assist?
‍ P95 latency under 200ms is the production-ready threshold for live agent assist applications. Above this, the transcript lag becomes perceptible in the agent's workflow. Gnani STT API achieves P95 under 200ms in streaming mode.

Can I use both modes in the same deployment?
‍ Yes, and this is common. A contact center might use real-time transcription for live agent assist during calls and batch transcription for post-call quality monitoring and compliance review. The two modes serve different parts of the workflow and can run in parallel.

What is WebSocket and why does it matter for real-time STT?
‍ WebSocket is the network protocol used for streaming transcription. It maintains a persistent connection between your application and the STT API, allowing continuous audio to flow to the server and continuous partial transcripts to flow back. Without WebSocket support, real-time streaming transcription is not possible. For a plain-English explanation of WebSocket and other STT infrastructure terms, see our STT Glossary.

Does speaker diarization work in real-time mode?
Yes, though diarization accuracy in streaming mode is lower than in batch because the system has less audio context to distinguish speakers. For use cases where accurate speaker attribution is critical, batch transcription with post-call diarization is more reliable. For more on diarization as an evaluation criterion, see Speaker Diarization, Confidence Scores, Latency: The STT Features Enterprises Overlook Until It's Too Late.

This post is part of The India STT Handbook by Gnani, a practitioner's guide to speech-to-text for Indian enterprises. Gnani STT API supports 12 Indian languages: Hindi, Tamil, Telugu, Malayalam, Kannada, Odia, Marathi, Punjabi, Gujarati, Bengali, Assamese, and English.