How to stop an AI phone line from reading part numbers and SKUs wrong

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

A misread part number on a phone line isn't a cosmetic problem the way a mispronounced name is. A customer who hears the wrong SKU and orders based on it gets the wrong part, and someone has to catch and fix that mistake downstream, usually after it's already cost a return or a wasted trip.

The two separate problems hiding in this one

There are two different things that can be going wrong, and it matters which one you have. The first is that the voice is reading a correct SKU in a confusing way, saying "two hundred twenty seven" when you need it read digit by digit as "two, two, seven." That's a pronunciation problem, and an ElevenLabs pronunciation dictionary fixes it directly. The second is that the underlying catalog data feeding the voice is wrong, inconsistent, or formatted differently across different records. No pronunciation dictionary fixes that, because the dictionary is correcting how a given string is spoken, not whether it's the right string to begin with.

These two problems also tend to get reported to you the same way, which is part of why they get conflated. A customer or a staff member who notices a wrong number on a call says "the AI got the part number wrong," and that single sentence covers both a pronunciation glitch and a data error identically from the outside. The practical difference shows up only once you actually check: a pronunciation issue reads the same wrong way every single time for that SKU, consistently, because it's the voice misinterpreting a correctly-stored string. A data issue is inconsistent in a different way: the SKU might read back perfectly clearly, digit by digit, exactly as written, and still be the wrong part number, because what's written in the record itself doesn't match what's actually in stock or in your system of record. If you fix the pronunciation and the complaints don't stop, that inconsistency is usually the tell that you're looking at the second problem, not a dictionary rule that still needs tuning.

How to fix the pronunciation piece

1. Write out exactly how each number format should be spoken. Decide, deliberately, whether "227" should be read as "two twenty-seven," "two two seven," or "two-two-seven," and be consistent across your whole catalog rather than letting the engine guess differently for each one.
2. Build an alias rule for recurring formats, not just individual SKUs if your part numbers follow a predictable pattern. A rule covering how your SKU format is generally structured goes further than hand-fixing numbers one at a time.
3. Test with a sample of real SKUs, not made-up examples. Pull an actual batch from your catalog, including edge cases like letters mixed with numbers or unusually long codes, since those are exactly where a generic rule tends to break.
4. Upload the dictionary as a TXT or .PLS file to the project powering your phone line, so the correction applies to every call, not just the one you tested manually.
5. Have someone on your team listen to a handful of real calls after the fix, not just the test clip, since live calls sometimes surface formats your sample didn't include.

Alias rules vs phoneme rules, and which one you actually need

ElevenLabs' pronunciation dictionaries support two kinds of rules, and for part numbers and SKUs, you almost always want the first one. An alias rule swaps the written text for different written text before the voice ever reads it, so "PN-4471-B" becomes the literal string "P N four four seven one B" and the model reads that out loud, digit by digit, exactly as written. A phoneme rule works differently: it tells the model how a specific word should sound using a phonetic alphabet (IPA or CMU), which is built for correcting how a real word is pronounced, not for forcing a string of characters to be read digit by digit. Phoneme rules also have less consistent support across ElevenLabs' different models than alias rules do, so for a catalog of part numbers, stick with alias rules; they're simpler to write, easier for a non-technical team member to maintain, and they work the same way across models.

A worked example makes the difference concrete. Say a plumbing distributor sells a part numbered "CPV-3/4-90," meant to be read as "C P V, three quarter inch, ninety degree." Written as-is, a voice model might read it as "C P V slash three slash four dash ninety," which is both wrong and confusing on a phone call. An alias rule mapping that exact string to "C P V three quarter inch ninety degree" fixes it outright. Compare that to an electronics distributor with SKUs like "R-10K-5," meant to be read "resistor, ten kay, five percent": same approach, different alias text, same underlying rule type. The pattern that matters is writing out the full, unambiguous spoken form and mapping the written SKU to it, not trying to coach the model's pronunciation of individual characters with phonemes. Names rather than numbers follow the same dictionary method, covered in fixing an AI voice that says company and street names wrong.

What I'd actually tell someone dealing with this

If you've already fixed the pronunciation and numbers are still coming out wrong, stop tuning the voice and go look at your catalog data directly. I've seen this exact pattern before: a business spends real time refining pronunciation rules for a problem that was actually duplicate SKUs, inconsistent formatting between systems, or a sync lag between the catalog and whatever's feeding the phone line. Pronunciation rules can't fix bad data, and chasing a voice problem that's actually a data problem wastes the time you'd rather spend fixing the thing that's actually broken. Answering product questions from a clean catalog is covered in answering product catalog questions by phone or chat.

A quick way to tell which problem you actually have: pull up the exact record the phone line is reading from for a SKU that came out wrong, and read it yourself, character by character, exactly as it's stored. If what's stored is correct and the voice just said it strangely, that's pronunciation, fix the alias rule. If what's stored is itself wrong, duplicated, or doesn't match what's in your actual inventory system, no dictionary fixes that; the record itself needs correcting at the source, and everything downstream of it, including the phone line, inherits the fix once the data is right.

A testing checklist before you trust it on live calls

A dictionary that sounds right on the handful of SKUs you tested can still misfire on formats you didn't think to check. Before pointing real call volume at it, work through this list:

• Pull a genuinely random sample, not your easiest examples. Grab 20-30 real SKUs spread across every product line you carry, not just the ones you used while building the rule, since different product lines often use different numbering conventions.
• Specifically include the ugliest formats you have. Mixed letters and numbers, unusually long codes, codes with slashes, dashes or decimal points, anything that looks like it could trip up a generic rule. If your rule handles your worst-case SKU cleanly, it will almost certainly handle the easy ones.
• Listen with sound on, at normal call volume, not just reading the transcript. A transcript can show the right text while the actual audio still sounds wrong or unnatural, especially with letter-number combinations; you catch that only by actually listening.
• Test with more than one voice if your phone line can use more than one. Alias rules generally hold up consistently across voices, but confirm it rather than assume it, especially if you're running different voices for different call types or languages.
• Re-test after every catalog update that adds a new SKU pattern. A new product line with a different numbering convention is exactly the kind of thing that slips past a one-time dictionary build and surfaces as a fresh complaint weeks later.

When to skip this

If your catalog has fewer than a few dozen SKUs and the numbers are simple, this might genuinely not be worth building; just spell out numbers clearly in the script each time. Pronunciation dictionaries earn their keep once you have enough recurring part numbers that hand-fixing each one becomes tedious or inconsistent across your team. There's a middle case worth naming too: if your SKUs change often (a seasonal catalog, frequent new product codes), a dictionary built once and left alone will drift out of date just as fast as the data it was built from, so budget for someone to actually own updating it when new formats show up, not just the initial build. A dictionary nobody maintains quietly becomes as unreliable as having no dictionary at all, just with more confidence behind the wrong answer. For generating audio across a whole catalog, see generating audio for every product in your database.

How I'd approach this

For the pronunciation side alone, ElevenLabs' own plans and a well-built dictionary solve this cleanly. If what you're actually dealing with is dirty or inconsistent catalog data feeding the voice, that's a different job, and the right fix is cleaning and syncing that data properly, not tuning pronunciation rules around bad input. That's the kind of build I take on for distributors and ecommerce businesses once the catalog itself, not the voice reading it, is the real source of the complaints. If you are new to the tool, how to use ElevenLabs as a beginner covers the basics.