Voice input is sold in one sentence: you say it and the system writes it down. We built such a tool ourselves, we use it daily, and this article is about what that sentence leaves out.
Every figure below comes from our own tool, not from somebody else's case study. The measurement conditions are given with each of them, because without conditions a number about transcription speed is worthless.
Why we built it at all
The reason was not technological. It was operational, and you may recognise it.
A task that requires somebody to sit down and write it out gets postponed. And it hurts just as much in the other direction: a client who sends ten five-minute voice messages in one morning has sent fifty minutes of speech that somebody has to listen to in full to extract three tasks from it. By 26 August 2026 our setup had transcribed 641 of them. It is not a staggering number, and that is exactly what makes it instructive: listening by hand stops paying off long before you get round to calling it a problem.
The tool does one thing: it turns speech into a written task with a deadline and an owner, and creates the card in Trello. More interesting than what works, though, is what did not.
Three things that did not work first time
The first version of the prompt summarised too hard. The transcript was fine, but the model turned it into a brief so economical that the conditions fell out of it - which is precisely what the task was being written for. We only noticed because tasks came back with questions. The lesson is dull and applies well beyond voice: a summary nobody compared with the original is an assumption about the content.
Transcription initially took a minute or two. At that delay voice input stops being faster than typing, and people only come back to it when both hands are busy. Speed here is not comfort, it is the condition of use.
Replies to clients sounded unprofessional. When we used the same setup to dictate chat replies, the text came out almost word for word as dictated, with all the filler of spoken language. It was fixed by rewriting the prompt, not by changing the model. Spoken and written language are two different registers, and converting between them is a task of its own, not a side effect of transcription.
Measured on 3 September 2026: speed against names
This is the core of the article. Ten typical phrases containing our own names, paths and commands; one machine, eight threads, three recognisers.
| Recogniser | Median per phrase | Total | Model load | Our names |
|---|---|---|---|---|
whisper medium |
5.04 s | 50.7 s | 13.2 s | 7 of 14 |
whisper small |
1.98 s | 19.8 s | 1.9 s | 7 of 14 |
| parakeet TDT 0.6b v3 int8 | 0.65 s | 6.2 s | 7.4 s | 1 of 14 |
The fastest model is almost eight times faster than the slowest and failed on proper nouns. It preserved the meaning of the sentences; what it lost was exactly the names, paths and commands - the one thing in a task brief that cannot be guessed from context. It wrote the tool's name phonetically and fused the command name into a single word.
The cause is structural, not a question of quality. The whisper family has an initial prompt where you can write how our names are spelled, and we use it. The exported transducer we measured as the fastest has no such place in our setup - nowhere to say that this word is spelled like this. A prompting mechanism for that family of models does exist, but it requires a different deployment path; we did not try it and it did not enter the measurement. The row in the table is a difference between two specific setups, not a verdict on a technology.
What we did with it: conversation runs on small (1.98 s), the button for longer dictation stayed on medium. The fast model stayed in the code and switches on with one line of configuration, in case a version with prompting arrives.
An honest caveat about the measurement: the phrases were spoken by a synthetic voice that pronounces Latin script by Czech and Russian rules. On live speech, where an English name sounds English, the fast model may do better. Only a person with a microphone can verify that, and we have not done it yet.
Silence is measured differently in a conversation and in a command
The second number the guides do not mention, because it is only tuned in production.
The system has to work out that you have finished. It does that from the length of the silence, and that value is not one number. For a short command 900 ms suits us. In a conversation, where somebody thinks out loud, the same value is unusable - it cuts them off mid-thought. There we use 1,200 ms.
End-of-utterance detection is usually quoted with shorter thresholds than ours, and that difference is deliberate rather than an oversight. The cost of too short and too long is asymmetric: a long threshold costs half a second of waiting, a short one costs a truncated sentence and having to repeat the whole brief.
Add to that three cheap fixes that replaced a clever detector:
- Filler words do not open an utterance. A segment recognised as "um", "well", "so", "hang on" is not sent anywhere and only extends the wait.
- Shorter than 0.7 s and longer than 25 s is not sent. The lower bound guards against hallucination on silence: give a model silence and it will occasionally invent a sentence. The upper one guards against the end of a long utterance disappearing without notice.
- An early cut is not fatal. The truncated sentence goes out and the next one queues up. In a phone call that would cost you a customer; here it costs one extra line.
A model can find the end of an utterance. A loudness threshold cannot
Originally we looked for the start and end of speech by loudness. That works in a quiet room and falls apart exactly where you need it - in a noisy office and in a car.
The measurable difference: with background noise at 0.01 RMS, above our 0.006 threshold, the loudness threshold never closes the utterance at all and sends the entire recording. A speech detection model pulls 3.3 seconds of actual speech out of the same input. It costs 0.05 s of CPU per 6.9 s of audio, which is practically nothing.
This is also the best example of a silent fault in the whole tool. Nothing breaks, no error appears - noise simply starts going into transcription and the results degrade in a way you will blame on the model rather than on the input.
A trap that has nothing to do with voice, and stops you anyway
The last lesson is worth mentioning because it applies to choosing tools generally, not only to voice.
The library we originally planned on installs without an error and only fails on first import: a Windows security policy blocks its binary component. That policy can be switched off with an ordinary setting; the trouble is the other direction - on those machines it cannot be switched back on without reinstalling the system. That was not worth it for one library, so we served the same model files through a runtime that is signed. It works, but it is extra work we did not know about when deciding.
The rule that follows: for a library with a binary component, check the policy and the import before the decision goes into the brief. A successful install is not proof that it will run.
When voice input makes sense and when it does not
Summing up what we measured:
It makes sense when somebody's hands are busy, they speak in a structured way, and somebody reads the output before acting on it. Task briefs, notes from site visits, construction reports, dictating a draft.
It does not make sense where the result goes straight into a system without human confirmation, and especially where the speech contains proper nouns, codes and numbers. Those are the first things lost, and they are lost silently - the sentence stays grammatically correct and means something else.
What this means in practice: voice input belongs before the step where a person sees the thing, not after it. Skip that rule and you are building an automation that occasionally writes down the wrong number - and why that is worse than writing none is covered in a separate article on numbers in automated messages.
What to measure on voice input is not transcription accuracy. It is how many proper nouns out of ten survive - because a name is the one thing the system cannot infer.
Want to try it on your own operation
Tell us what your people enter by hand today and when their hands are not free while doing it. We will come back with an estimate of whether voice input pays off and, more importantly, at which step a human has to stay.
We build the scenarios, the integrations and the running of them on the automation page. Which channel a tool like this should speak through is covered in a separate article on choosing between WhatsApp, Telegram and SMS.
Write to info@lamapixel.com or call +420 775 599 009.
