Why do transcripts keep misreading my part names and technical terms?

This page may contain affiliate links from which Blur Studio earns commissions.

Speech-to-text models are trained on huge amounts of ordinary spoken language, which makes them good at normal sentences and genuinely bad at anything that isn't common outside your specific trade or industry. A part number, a brand name, a piece of internal jargon, none of that shows up often enough in general training data for the model to be confident about it, so it guesses at the closest common word instead. That's why "the 4R70W transmission" can come back as something that sounds similar but means nothing, and why a wrong part name in a transcript quietly turns into a wrong order or a wrong note in someone's file.

Why this happens, the actual mechanism

Modern speech-to-text models are genuinely accurate on ordinary speech. ElevenLabs' Scribe v2, for one, benchmarks under 5% word error rate across 35 languages the company rates as "excellent," and independent testing has put its best-case word error rate around 2.2%, with speaker labeling accuracy around 98%. That's a strong baseline. But accuracy figures like that are measured on general speech, not on your specific vocabulary, and the gap between "accurate overall" and "accurate on the ten words that actually matter to your business" is exactly where this complaint comes from. The tool itself is described in ElevenLabs Scribe speech to text.

The fix: custom vocabulary

Most serious transcription tools let you supply a list of terms you expect to hear, and bias the model toward recognizing them correctly. On ElevenLabs' Scribe v2, this is called keyterm prompting: you give it a list of the specific words (part numbers, product names, technical terms) likely to come up, and it weights its guesses toward those terms instead of the nearest common word. It costs an extra $0.05 an hour on top of the standard $0.22-an-hour transcription rate for batch jobs, and supports up to 1,000 keyterms (50 characters each) in a batch job, or up to 50 keyterms (20 characters each) for real-time transcription, at a slightly different extra cost on that mode. You can check the current rates and limits directly on ElevenLabs' own pricing page before committing a workflow to it.

This genuinely helps, but it isn't a guarantee. It raises the odds the model picks the right word when it hears something close to one of your terms; it doesn't make the model perfect, especially on a noisy recording or an unusual pronunciation. Cleaning up the audio first, as described in how to clean up audio before you send it to be transcribed, helps on noisy recordings.

A concrete before-and-after helps make this real. A technician describing a job might say "replaced the 4R70W transmission solenoid pack and the TPS sensor." Without a keyterm list, a transcript has come back as something like "replaced the four R seventy W transmission solenoid pack and the T P S sensor" split oddly, or worse, with the part number dropped entirely and replaced with a vague "the transmission part." Add "4R70W" and "TPS sensor" to the keyterm list and the model has something concrete to match the audio against instead of guessing at the nearest common phrase, and the part number comes through intact far more often. The same pattern shows up across trades: a plumber's "PEX" and "ABS" fittings, a distributor's SKU codes, a clinic's drug names and dosages, a property manager's unit and building codes. None of these are rare words in the sense of being hard to say; they're rare in the sense that a model trained mostly on everyday conversation has barely seen them.

Building a keyterm list that actually works

The quality of the fix depends entirely on the quality of the list, and the most common mistake is building it from memory instead of from a real source. A technician or office manager trying to recall "the terms that usually get messed up" will reliably forget half of them, usually the ones used rarely enough to cause the exact problem you're trying to fix. Pull the list from something authoritative instead: your actual parts catalog, your product SKU list, your CRM's drug or treatment code list, whatever system already has the correct spelling of every term you'd want recognized. This also means the list can be regenerated automatically whenever your catalog changes, rather than someone remembering to update a spreadsheet.

A second mistake is treating the list as a one-time setup. Run a handful of real recordings through after your first list goes live, read the output against what was actually said, and note every term that still came back wrong. Add those specifically, even if they seem like they should have been covered by a similar term already on the list; keyterm matching isn't fuzzy enough to generalize from "4R70W" to "4R75W" automatically. Expect two or three rounds of this before a list stabilizes, especially if your vocabulary includes a lot of similar-sounding codes or part numbers that differ by only a character or two.

A third thing worth knowing: longer, more distinctive terms tend to transcribe more reliably than short, common-sounding ones. A part number like "4R70W" stands out acoustically; a short code like "A12" that sounds like it could be several different things is harder for the model to pin down even with it on the keyterm list, since there isn't much acoustic signal to distinguish it from a similar-sounding alternative. If your codes are short and easily confused with each other, expect a slightly higher error rate on those specifically, and weigh whether a human review step is worth keeping on just those lines even once the rest of the list is working well.

What I'd actually tell someone dealing with this

If wrong part names are causing real problems (wrong orders, wrong repair notes, a customer getting billed for the wrong thing), don't treat keyterm prompting as optional. Build your term list from your actual catalog or parts list, not from memory, since the terms people forget to include are usually the ones that show up wrong later. And don't skip the human check on anything that triggers an order or a bill; even a 98% speaker-labeling and sub-5% word-error-rate tool will still get your least common, most important ten words wrong some of the time, and those are precisely the words a human catches in five seconds that cost real money if nobody looks. Meeting recordings follow the same approach, covered in getting meeting notes without a note taker joining.

How to set this up

1. Pull together the actual list of terms that matter: part numbers, product names, brand names, abbreviations specific to your trade.
2. Add that list as keyterms (or your tool's equivalent custom vocabulary feature) before transcribing, not after.
3. Transcribe a real recording, one you already know the correct terms for, and compare the output line by line.
4. Add any terms that still came back wrong to your list, and re-test. This is iterative; your first list usually isn't complete.
5. For anything that drives a real decision (an order, a bill, a repair note), have a person glance at the specific lines mentioning technical terms before acting on them, even after the keyterm list is dialed in.

Batch vs real-time: which one matters for this problem

Keyterm prompting works differently depending on whether you're transcribing a finished recording afterward (batch) or transcribing live as someone talks (real-time). Batch gives you the larger allowance, up to 1,000 keyterms, which matters if your technical vocabulary runs into the hundreds of distinct part numbers or product codes. Real-time caps at 50 keyterms, a genuine constraint if you're trying to catch live, in-the-moment dictation (a technician talking through a job as they do it, a dispatcher taking details over the phone) rather than cleaning up a recording after the fact. If your vocabulary is large, you may need to prioritize which 50 terms matter most for the live case, and rely on a batch re-transcription with the full list afterward to catch anything the live pass missed. Don't assume the same list that works well in batch will behave identically in real time; test both separately if you use both. Setting up automatic transcripts for every call is covered in how to transcribe every call automatically.

When to skip the tool

If you're only transcribing a handful of recordings a month and the technical terms involved are few and well-known to whoever reviews the transcript, a quick manual correction pass is simpler than setting up and maintaining a keyterm list. Keyterm prompting earns its keep once you're transcribing enough volume, or have enough distinct technical terms, that manual correction becomes the real bottleneck.

How I'd approach this

I've built keyterm lists straight from a client's own parts catalog or product database before, so the vocabulary stays current automatically instead of someone maintaining a manual list that goes stale. If your technical vocabulary changes often (new products, new part numbers) and keeping a term list updated by hand is itself becoming the chore, that's a small, genuinely useful piece of custom work, not something you need a bigger platform for. The build itself is usually small: a scheduled job that pulls your current catalog, formats it to the keyterm limits (character counts, list size) for whichever mode you're using, and keeps batch and real-time lists in sync if you use both. It's the kind of fix that pays for itself quickly once you're transcribing enough volume that a stale or incomplete keyterm list is quietly costing you wrong orders every week.