One entry and one habit fix most of what an engine gets wrong

A speech engine is trained on the language most people use, which means the word it mishears is never a common one — it is the surname you say fifty times a week, the service your team named internally, the acronym invented in a meeting eighteen months ago. None of that is a flaw you can wait out. It is a gap between what the engine has heard before and what you actually say, and closing it takes two things working together: how you say the term out loud, and one dictionary entry that fixes it for good.

Say it the same way every time

The single biggest thing in your control is consistency. If you sometimes say "Kubernetes" in full and sometimes say "k8s," you are asking for two different words to both come out right, and a dictionary entry only fixes the one you actually typed in. Pick one way to say a given term and stick to it. This matters more for names and acronyms than for ordinary words, because the engine has far less prior exposure to any one of them to fall back on.

Give the term a sentence to live in

A name or an acronym said in isolation is the hardest case for any speech engine, because there is nothing around it to narrow down what it probably was. Say it inside the sentence you actually mean, not as a test word on its own — "ask Priyanka about the Redis migration" gives the engine two neighboring words of context that "Priyanka" alone does not. This is not specific to this app; it is true of dictation generally, and it costs nothing to do.

Spell out an acronym that has no entry yet

For a three- or four-letter acronym you have not added to your dictionary, saying the letters individually — "A P I," with a short pause between each — tends to transcribe as separate capitals rather than being folded into an ordinary word. It does not work identically for every acronym, so the first time you use a new one, glance at what landed before you keep going. If it came out wrong, that is your cue to add an entry rather than keep spelling it out by hand every time.

Build the entry once the term has actually failed

Do not front-load your dictionary with every proper noun you might ever say — how to teach a dictation app your jargon covers the full method for building one, including what belongs in it and how the matching rules work. The short version for this page: wait for a term to misfire, then add a rewrite entry mapping exactly what the engine heard to exactly what you meant, casing included. A single clean entry for "kubernetes → Kubernetes" fixes both the wrong case and any consistent mishearing in one move, because the entry is applied as a rewrite over the finished transcript.

This is where the two techniques meet. Saying an acronym letter by letter gets it into the transcript as capitals in the first place; a dictionary entry is what keeps a term that does not spell out cleanly — a surname, a compound product name, a phrase your team abbreviates a certain way — correct without you doing anything differently next time.

Compound names and multi-word terms

A single word is the easy case. A compound product name — two ordinary words mashed into one with a capital in the middle, or a phrase your company always says a specific way — is harder, because the engine has no reason to guess that "data pipeline" should come out as one internal tool's proper name rather than two ordinary words describing a concept. Treat the whole phrase as one dictionary entry rather than trying to fix each word separately: an entry that matches the full phrase and rewrites it in one step is more reliable than two entries hoping to combine correctly on their own. If your team has several related terms built the same way — a family of internal service names sharing a prefix, say — add them as separate entries rather than one entry with a wildcard; the matching here is exact and literal on purpose, so it never rewrites something you did not mean.

Symbols and punctuation in technical dictation

Names and acronyms are one half of technical dictation; the other is the punctuation and symbols that ordinary prose never needs — underscores, dots, parentheses, slashes. Say them the way you would explain them to a colleague reading over your shoulder: "open paren," "underscore," "dot," "forward slash." This produces the literal character in the transcript because punctuation and spacing are part of the same fixed post-processing chain that runs on every dictation, not a separate mode you switch into. How to dictate code comments covers this in more depth for anyone spending most of a day dictating around a codebase, but the underlying habit is the same one this page is about: say precisely what you mean, and let a small number of dictionary entries handle the parts that saying it precisely still is not enough for.

Check the raw transcript before you blame the engine

Every dictation keeps two versions: the words as spoken, and the words after your rules run. When a term comes out wrong, look at the raw transcript first. If the raw version already has the right word and only the processed version is wrong, the fix is in your dictionary — an entry is misfiring, or missing. If the raw version is wrong too, the problem is upstream of any rule you can write: audio quality, distance from the microphone, or background noise loud enough to eat the word entirely. How to dictate with a headset is worth reading before you assume a name is simply beyond the engine — a lot of "it never gets this right" turns out to be a laptop mic three feet away picking up a fan.

Names the engine has never heard, and the honest limit here

Some names do not have a phonetic shortcut. An uncommon surname, a name from a language whose sounds do not map cleanly onto English spelling, a client's name you have never typed before — the first time, you are as likely to get it wrong as the engine is. This app's dictionary does not learn from context or guess at a spelling from how something sounded; it does exactly what you typed, and nothing more. Correct it once, add the exact spelling as an entry, and every dictation after that is right. That is more manual effort than an app that learns your vocabulary as you go — worth saying plainly rather than glossing over.

Wispr Flow is that other kind of tool: its dictionary documentation describes entries that can be "automatically learned" from the corrections you make, separately from the ones you add by hand. For someone whose vocabulary of names and jargon changes every week and who would rather not maintain a list, that is a real advantage and it is fair to say so. The trade is the one on every comparison page in this library: a system that learns from your speech needs an account to learn into, and this one keeps the whole dictionary, like the rest of your data, on the machine in front of you and touches nothing else. Which one is worth more depends on whether you would rather type ten entries once or let an account quietly build a profile of you over months — Coii VoiceInput vs Wispr Flow goes through the rest of that trade in full.

When two terms sound almost the same

Context does most of the disambiguating work when two technical terms sound alike but mean different things — "queue" and "cue," a service called "Sable" against the word "stable," a client called "Loom" against the word "loom" used literally. Speaking the whole sentence rather than the term alone, as above, is the first line of defense, because the surrounding words usually make the correct reading obvious even to a system with no idea what either proper noun refers to. Where a specific pair keeps colliding despite that, a dictionary entry can only rewrite one direction reliably — matching the wrong reading and replacing it with the right one — so pick whichever of the two comes up far less often in your own dictation and write the entry to correct toward the one you actually need more.

Fix it in your history, not by redictating

Once you have corrected an entry, you do not need to say the whole passage again. Both the raw and processed transcripts for that dictation are already sitting in your history — how to dictate on a Mac covers the mechanics of a history row — so the fix is to update the dictionary and reprocess the existing row, not to redo the recording. This matters most for code comments and technical writing, where the sentence around the misheard term is often long and re-speaking all of it for one wrong word wastes more time than the fix itself. How to dictate code comments walks through the same idea applied to a codebase full of function and variable names that no general-purpose engine has ever seen.

Numbers, versions and measurements

Technical writing is also full of numbers that read differently spoken than typed: version strings, IP-style addresses, measurements, currency. Say the punctuation the same way you would for a symbol — "two dot four dot one" for a version number, "one hundred ninety two dot one six eight dot one" for an address — and it lands as the literal characters rather than the app guessing at a written-out number. Where a number comes out wrong more than once, the fix is the same dictionary entry used for anything else: match what the engine actually produces, rewrite it to what you meant. There is no separate numbers mode to learn, which is deliberate — one mechanism doing every kind of correction is easier to reason about than five specialized ones each with their own rules.

Test a new term before you rely on it in something that matters

Before you dictate a term into an email you are about to send or a pull request you are about to open, say it once somewhere low-stakes — a blank note, a scratch document — and check what landed. This costs ten seconds and tells you three things at once: whether the engine gets it right unaided, whether spelling it out helps, and whether you need a dictionary entry at all. Skipping this step is how a wrong client name ends up in a sent email instead of a test note, and the fix after the fact is always more expensive than the ten seconds would have been.

This habit matters more the first time you use a new term than any time after. Once a name or an acronym has either proven reliable on its own or gotten a dictionary entry, it stays fixed — there is nothing to re-test unless you change how you say it.

Where this pays off most

Developers, recruiters reading resumes full of company and candidate names, and anyone dictating into a codebase or a CRM full of proper nouns hit this problem daily rather than occasionally — dictation for developers and best speech-to-text for developers both build on the same method described here, applied to the specific vocabulary those jobs carry. A developer's dictionary tends to fill up with service names and third-party library names inside the first week; a recruiter's fills up with candidate surnames and the specific way each client company writes its own name. Neither list is very long once it stops growing, which is usually within the first few dozen dictations of actual use.

The habit is the same regardless of field: say it consistently, give it context, spell out what needs spelling, and let one dictionary entry do the rest of the work for every dictation after the first.

Ready to see how your own vocabulary holds up? Try Coii VoiceInput and start the dictionary with the five terms that come up most in your work — that is usually most of the fixing done in one sitting.