Every speech engine gets the same class of word wrong: the surname of the colleague you mention ten times a day, the internal service nobody outside the building has heard of, the product spelled with a capital in the middle, the three-letter acronym your team invented last spring. It is the most common accuracy complaint about every dictation product ever sold, and unlike a general accuracy problem it has a direct fix.
This page is how to build that fix: what belongs in a dictionary, how to write entries that do not misfire, and the honest difference between an app that learns your terms and one you teach.
Two ways apps handle this, and what each costs
Learning. Some apps watch what you correct and pick terms up over time. Wispr Flow advertises that it learns your names and jargon as you go. This is genuinely less work: you correct a word twice and it stops being wrong. The costs are that it needs a profile of you to learn into, usually an account and usually synced, and that you cannot see the list — when it learns something wrong, the fix is less obvious than deleting a row.
A dictionary you write. Other apps, this one included, give you a list to type into. It is more work up front and it is completely inspectable: every substitution that happens is one you authored, and removing one is deleting a line.
Neither is the better design in the abstract. If you have fifty internal terms and no patience for data entry, learning is the right purchase and the comparison against Wispr Flow marks that row as a loss for us. If you want to know exactly what your tool substitutes — which is most people in regulated work, and most people who have been burned by an autocorrect — the explicit list is the one to have.
What actually belongs in the list
Not everything the engine gets wrong is worth an entry. The ones that pay for themselves:
Names of people you mention often. Surnames are the single worst category for any general engine, and a name in a message to the person it belongs to is an error you cannot leave in.
Product and service names. Anything with unusual capitalisation, a fused compound, or a spelling that differs from the ordinary word it sounds like.
Internal acronyms. An outside engine has no reason to know that your team's three letters are three letters rather than a word.
Technical vocabulary specific to your stack. Anyone who dictates about databases, infrastructure or libraries hits this constantly — the terms are shared by thousands of engineers and still absent from a general engine's everyday vocabulary. Dictation for developers covers the wider shape of this, and speech-to-text for developers is the round-up of which tools handle it at all.
Expansions you type constantly. A rule that turns a spoken shorthand into the full phrase saves more time than it looks — this is the part of a dictionary that is not about accuracy at all.
What does not belong: ordinary words the engine occasionally mishears. Those are a microphone problem or an audio problem, and an entry for them will fire in sentences where the engine was right.
Writing entries that do not misfire
In Coii VoiceInput an entry is a term and optionally a target. A term on its
own means "spell this correctly wherever it appears". A term with a target is a
rule: btw → by the way.
Four things govern how they behave, and knowing them prevents most bad entries.
Longest first. When two entries could both match, the longer one wins. An entry for a two-word product name beats an entry for the first word of it, so you can have both without the short one eating the long one.
Word boundaries only. A Latin-script entry never fires inside a longer
word. An entry for arc leaves architecture alone. This is why short entries
are safe, and it is also why an entry for a fragment that is genuinely part of
other words will not do what you hoped.
Case-insensitive matching, exact output. The match ignores case; what gets written is exactly what you typed as the target. That is how you fix a product name with a capital in the middle.
Never fuzzy, never phonetic. Nothing is substituted for merely sounding similar. This is a deliberate limit rather than a missing feature: an entry that rewrote things that sounded alike would corrupt sentences that had been transcribed correctly, and you would have no way to tell which of your correct sentences it had damaged.
Ask Nakagawa whether the ingest job still writes to the staging cluster before we cut over.
Where entries are used, and why that order matters
The dictionary does its work twice.
Before recognition, entries are passed to the engine as a hint, biasing it toward hearing those words in the first place. This is the half that matters most: a term the engine heard correctly needs no repair, and a correct transcription is always better than a correct substitution.
After recognition, the entries are applied over the transcript, catching what the hint did not. This is the fallback, and it is what covers the case where the engine simply had no such feature.
The practical consequence is that an entry helps even when the substitution step could not safely act on it. A CJK term has no word boundaries to anchor a substitution to, so it is not rewritten over the finished text — but the hint still fired, and the engine was more likely to get it right before anything needed rewriting.
Building the list without a sitting
The list that works is the one you built as you went, not the one you tried to write in advance.
Week one: add on contact. When a name comes out wrong, add it then. It takes ten seconds and you will never think about that word again. Resist the urge to seed fifty entries speculatively — half of them will be words the engine already had, and every unnecessary entry is a small chance of a misfire.
Week two: read your history. Look through what you actually dictated and find the words you corrected by hand. Those are the entries worth having, and they are visible in a way your memory is not.
Then stop. Most people land between twenty and forty entries and never need more. A dictionary that keeps growing is usually a sign that something else is wrong — an input device picking up noise, or an accent the engine handles badly, neither of which a word list will fix.
Expansion rules, which are a different tool wearing the same coat
Half of what a dictionary is good for has nothing to do with accuracy. A rule with a target rewrites one thing into another, and once you have that, the obvious use is typing less.
Boilerplate you say all day is the candidate: a standard sign-off, the full name of a team you refer to by initials, a URL you paste into every ticket, the formal name of a document you mention constantly. Say the short form, get the long one.
Two cautions. First, pick a trigger you would never say for its own sake — the whole point of an expansion is that it always fires, and a rule on a word with an ordinary meaning will fire in the sentence where you meant the ordinary meaning. An invented shorthand is safer than a real abbreviation. Second, keep expansions short. A rule that produces three sentences from one word is building a template system inside a dictation app, and the place for that is a text expander or a snippet tool that knows about cursor position and fields.
The dividing line is roughly whether you would want the result inside a sentence you are speaking. A phrase, yes. A paragraph, almost never.
What to do about the terms a list cannot fix
Some words stay wrong no matter what you put in the dictionary, and it is worth recognising them so you stop fighting.
Words that are correct in one sense and wrong in yours. If your product is named after an ordinary noun, an entry cannot know which one you meant, and forcing it means the ordinary noun stops working. Some people solve this by speaking a distinctive shorthand and letting a rule expand it; most decide the two-second fix afterwards is cheaper than the misfires.
Names that are genuinely ambiguous in speech. Two colleagues whose surnames sound identical cannot both win. The dictionary is a text substitution, not a listener; it cannot use the context of the sentence to decide which person you meant.
Accented or unusual pronunciations of common words. These read as accuracy problems and are usually audio problems. A closer microphone does more than any entry.
Anything you only say once. An entry for a word you will not use again is pure risk with no return. Correct it by hand and move on.
Being deliberate about which of these you are looking at saves more time than any individual entry. A list of thirty good entries makes a dictation habit usable; a list of two hundred speculative ones makes the output unpredictable, which is the problem you were trying to solve.
Auditing it when something looks wrong
Because every entry is one you wrote, a bad substitution is traceable, and the history is where you trace it. Both the raw transcript and the processed one are stored on every row, so you can see the engine's own output next to what was written. If they differ on a word you did not expect, an entry fired.
The fix is almost always a more specific entry rather than deleting the dictionary. A term that matched somewhere unwanted usually needs to be longer — the full two-word name rather than the distinctive half of it.
What this does not do
It does not learn, it does not sync between machines, and there is no shared team vocabulary. Three machines mean three lists. For a team that wants one canonical glossary across everybody, an account-based tool is the right answer and this is not it — the superwhisper comparison covers the nearest local alternative and where each of us stops.
It also does not rewrite your phrasing. The dictionary fixes words; nothing in the app reshapes a sentence, adjusts tone, or tidies a hedge, which is the longer argument here.
Moving the list to a new Mac
An explicit dictionary has one practical drawback and it shows up the day you get a new machine: nothing syncs it for you. There is no account, so there is no server holding your list.
What there is instead is a settings file on disk, which means the list is yours to copy. Take it across with the rest of your settings when you move, and the twenty minutes you spent building it are not spent again. A licence covers three machines, so this is a thing most people do at least once.
If syncing a vocabulary across machines automatically is something you need rather than something you would like, that is a genuine reason to buy an account-based tool instead, and it is the same trade as everything else on this page: no account means nothing to sync, and also nothing held about you anywhere.
Who gets the most out of it
Recruiters, who say more unfamiliar surnames per hour than anyone — see dictation for recruiters.
Developers writing code comments and review notes, where a wrong library name makes the sentence meaningless rather than merely untidy.
Anyone in a field with its own vocabulary — clinical, legal, scientific — where the specialist terms are precisely the ones a general engine has never been asked to produce.
Coii VoiceInput is $19 once for macOS 13 or later, with a 30-day trial and no account; the trial is long enough to build the list and find out whether twenty entries fixed the thing you were annoyed about.