Published: · Machine-readable version (markdown)
You choose a speech-to-text (STT) engine for calls not by a claimed “accuracy in general” but by how it handles your conversations specifically: in your language, on 8 kHz telephone audio, within your per-minute budget, and under your requirements for where the data goes. There is no universally “best” engine — there is one that fits the job. Below are the six criteria to decide on, and why you should test them on your own archive rather than on someone else’s benchmarks.
Step 1. Start with language and accents
The first disqualifying criterion is language. An engine that’s excellent in English can sag noticeably in Russian, and vice versa. If your calls span several languages or carry strong regional accents, look for a multilingual engine rather than a set of monolingual models. For Russian-language telephony, local engines are traditionally strong; for dozens of languages, multilingual cloud models fit better.
Don’t confuse the interface language with the recognition language — they’re different things. Determine which languages your calls actually run in, and in what proportions. If 95% of conversations are in one language, optimize for it; if the flow is mixed, what matters is the engine’s ability to switch languages within a conversation and not “fall back” to a default.
Step 2. Check accuracy on 8 kHz telephone audio
This is the main trap. Most of the pretty accuracy figures come from clean studio audio at 16 kHz and above, whereas telephony is narrowband 8 kHz sound with codecs, line noise, echo and speech overlaps. An engine that shines on podcasts can perform noticeably worse on real calls. So you must test accuracy on recordings as close to yours as possible — the same telephony, the same conditions, the same jargon.
A practical method: take a dozen typical calls where you know exactly what was said, run them through several engines, and compare the transcripts by eye. Look not at the overall percentage but at what’s critical for you: are names, numbers, amounts, product names and specific terms recognized correctly? An error in a contract figure matters more than a dropped “um.” Don’t rely on someone else’s benchmarks — your acoustics are unique.
Step 3. Calculate the cost per minute
Engines differ in cost by multiples, and at volume that’s the deciding factor. Calculate not an abstract price but the cost of a minute of your specific scenario: it depends on call length, the number of channels (a stereo operator/client recording doubles the cost with engines that bill per channel), and your monthly volume.
Engine cost varies widely — from fractions of a cent to several cents per minute. On the platform, operations are charged from your balance at the engine’s cost price, with no markup on top, so your per-minute price is exactly the engine’s price; it’s easy to compare on the pricing page. An expensive multilingual engine is justified where you need maximum accuracy across many languages; for large homogeneous volumes, an inexpensive local engine tuned to a specific language usually wins.
Step 4. Settle diarization and channels
For call analysis, text alone isn’t enough — you need to know who said what: which lines are the operator’s, which are the client’s. There are two paths. If the recording is stereo with roles split by channel (operator on one, client on the other), the separation comes out accurate almost automatically — this is the best option, and worth building in at the telephony setup stage. If the recording is mono, roles are separated by diarization, which splits a single track into speakers.
Note that diarization is a separate operation and a separate line in the cost, and its quality on telephone audio is lower than on clean audio. So where possible, record calls in stereo with channel separation: it’s both more accurate and cheaper than relying on diarization over a mono track. For how the recognition and role-tagging layer works, see the automatic call analysis page.
Step 5. Choose the mode: real-time or batch processing
Not every task needs to be recognized instantly. If you analyze an archive or process calls after the fact for metrics and quality control, real time isn’t required — and deferred batch processing is usually noticeably cheaper. For some engines the deferred mode costs several times less than the synchronous one at the same quality, and at volume that’s tangible savings.
Real time (streaming recognition) is needed where the text is required during the conversation itself: a prompter for the operator, a live transcript, a voice agent. For everything else — post-processing, analytics, retro-tagging of an archive — choose batch mode. You can trim the bill further by cutting silence before recognition (a shorter file means paying less) and by a transcription cache: the same audio with the same parameters isn’t recognized twice.
Step 6. Define your data requirements (cloud or self-hosted)
The last criterion isn’t technical — it’s about trust and regulation. If, by company policy or legal requirement, call audio must not leave your perimeter, a cloud engine doesn’t fit regardless of its accuracy and price. In that case you choose self-hosted recognition: the model runs on your infrastructure and the data doesn’t go outside.
For this scenario, engines like Whisper or Vosk running on your own hardware are a good fit: you can stand them up locally and recognize speech without per-minute payments to a third-party provider and without sending audio to the cloud. On the platform this mode is implemented via a local worker: you download and run it on your side, pair it by code, and transcription with diarization run inside your perimeter — the audio doesn’t leave it. For more on data-isolation models and on-prem options, see the security page.
How to bring the criteria together
There is no single “best” engine, but there’s a simple way to reach a decision. First filter by hard constraints: language (the engine must understand your languages well) and data (if you need self-hosted, cloud is out immediately). Then, among the remaining candidates, check accuracy on the 8 kHz audio of your own archive and calculate the cost per minute of your real flow. Finally, factor in channels/diarization and processing mode — they yield savings that are easy to miss.
It’s practical not to lock yourself into one engine forever. Different scenarios may call for different engines: an expensive, accurate one for important languages or hard calls, a cheap batch one for mass flow, a self-hosted one for sensitive data. The platform lets you connect system engines, bring your own key to an external provider, or run a local worker, so the choice isn’t final — you can change it as you grow and refine it on your own data.
What’s next
Choosing an engine is the foundation, not the goal: the recognized text is valuable for what comes out of it. The next step is turning transcripts into metrics, topics and quality control across all calls at once. If you’re comparing the approach itself — an analysis platform versus “just transcription” — see how call analysis differs from transcription.