How to fix an AI voice that keeps mispronouncing your company or street name

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

A wrong name sitting inside otherwise polished, professional-sounding audio is exactly the kind of mistake customers notice immediately, even customers who wouldn't otherwise be listening that closely to anything else in the recording. It reads as careless, not as a technology limitation, because most people don't know that's what's happening under the hood.

The quick fix versus the lasting fix

If this is a one-off piece of audio, the fastest fix is simply respelling the problem word phonetically directly in the script you're feeding the text-to-speech engine, something like "Nyked" if "Nike" is coming out wrong. It costs nothing and takes thirty seconds, and for a single file that's the right amount of effort.

If you'll generate audio with this name repeatedly, respelling it every single time is how pronunciation dictionaries earn their place. An ElevenLabs pronunciation dictionary lets you define the correction once and have it apply automatically to every future piece of audio, so you're not relying on remembering to fix it each time.

How to set up a pronunciation dictionary

1. List every name that's been mispronounced, not just the one that prompted this. If one street name is wrong, others in the same area probably will be too.
2. Start with an alias rule for each one. An alias rule tells the engine to pronounce a word or phrase the way another word or phrase already sounds, for example telling it to read "UN" as "United Nations." This is the simplest rule type and the one most broadly supported across ElevenLabs' models.
3. Only reach for a phoneme rule if an alias doesn't get it right. A phoneme rule specifies the exact sound using phonetic notation, giving you finer control, but phoneme-based rules aren't supported the same way by every model, so they're the more fragile option if you're not certain which model your generations are running on.
4. Upload the dictionary as a TXT or .PLS file in your project's settings. You can build this file by hand for a handful of names, or generate it from the add-from-rules API endpoint if you're managing dozens of names programmatically.
5. Re-generate a short test clip with every corrected name in it before trusting the dictionary on a real project, since the easiest way to catch a dictionary rule that didn't take is to listen for it directly.

A worked example: a tricky street name in a property listing

Say your listings keep mispronouncing a local street name, "Al Wasl" coming out wrong in every generated voiceover because the model is guessing at a pronunciation it hasn't seen before. Here's the actual sequence to fix it for good:

1. Write down exactly how it's actually pronounced, ideally by listening to a local speaker say it, not by guessing from the spelling yourself.
2. Create an alias rule that respells it the way it should sound, something like mapping the written name to a spelling that reads correctly when a text-to-speech engine sounds it out letter by letter.
3. Generate a test clip using that street name in an actual listing sentence, not the name in isolation, since pronunciation can shift slightly depending on the words immediately before and after it.
4. Add every other local street and area name you already know gets mispronounced in the same pass, rather than fixing them one complaint at a time. If one is wrong, nearby ones probably are too, and it's far more efficient to build the dictionary once with everything you already know about than to keep coming back to add one entry at a time.

Once that dictionary exists, every future listing using that street name, or any of the others you added, is correct automatically, with no one needing to remember to respell it by hand again. Fixing Arabic place and developer names in listing audio goes further for that case.

Which names to fix first, if you have a lot of them

If you're dealing with a large catalog, a distributor's product line, a real estate portfolio with many streets and developments, don't try to build a complete dictionary before generating anything. Start with whatever actually gets said most often: your own company name, the handful of streets or areas you cover most, your most common product lines. Add the rest as you encounter them in real generated audio, since that's a far better use of time than trying to anticipate every possible mispronunciation of a name nobody's actually asked you to voice yet. A dictionary that covers your top 20 most-used names, built in an afternoon, delivers most of the value a dictionary covering 2,000 names eventually would, for a fraction of the setup time. Stopping a phone bot from reading part numbers and SKUs wrong covers product codes.

Testing across models, not just once

If you generate audio using more than one ElevenLabs model (say, a faster model for drafts and a higher-quality one for final output), test your pronunciation rules against each model you actually use, not just whichever one happened to be selected when you built the dictionary. Alias rules are the more consistently supported option precisely because of this: a phoneme rule that works perfectly on one model can behave differently or get ignored entirely on another, which is exactly the kind of inconsistency that slips through unnoticed until a client hears it on a different model than the one you tested on.

What I'd actually tell someone dealing with this

This is one of the lower-stakes fixes in ElevenLabs' whole toolset to get right, and also one of the easiest problems to quietly under-invest in, since each individual mispronunciation feels small on its own. A business that generates recurring audio, listing voiceovers, phone greetings, training content, and never builds a pronunciation dictionary is effectively choosing to re-fix the exact same mistake over and over again, every single time it comes up, instead of just once. If you've caught this problem more than once already, take that as the clear signal to sit down and build the dictionary properly now, rather than waiting for a third customer or colleague to flag the exact same name again. The same approach helps a professional voicemail greeting and hold message that names your business.

When to skip this

For truly one-off audio, a single ad, a single explainer you'll never regenerate, rewriting the spelling directly in the script is simpler than building a dictionary you'll only use once. Reserve the dictionary for names you expect to say again. If the audio is already inside a finished video, fixing one wrong sentence in a recorded video shows how.

Common mistakes worth avoiding

• Fixing names one complaint at a time instead of in batches. If someone flags one mispronounced name, that's the moment to also check the five or ten other similar names you already suspect are wrong, not just the one that happened to get noticed.
• Reaching for a phoneme rule by default. Start with an alias rule every time; it's simpler, more broadly supported, and fixes the large majority of mispronunciations without the model-compatibility risk that comes with phoneme-level rules.
• Never testing the dictionary in context. A name tested in isolation can sound right while the same name embedded in a full sentence, with different words before and after it, comes out wrong. Always test with a real sentence, not just the bare name.
• Treating the dictionary as a one-time setup task. New product names, new locations and new hires' names keep showing up. Treat the dictionary as something you add to as you go, not a project you finish once and never touch again.

How I'd approach this

Building and maintaining a pronunciation dictionary for a handful of brand and location names is squarely within what ElevenLabs' own plans and tooling handle well; you don't need anything custom for this specific problem. Where I come in is when a business has hundreds or thousands of names to manage (a franchise's locations, a distributor's product catalog) and wants that list generated and kept current automatically from the underlying data, rather than maintained by hand in a settings file. A practical version of that build: a small system that pulls your actual product or location names from wherever they already live (a spreadsheet, a database, a CMS), flags any that look likely to be mispronounced based on unusual spelling or non-English origin, and keeps the dictionary file updated via the API as your catalog changes, rather than someone remembering to update a settings page every time a new product or location gets added. For a distributor or franchise adding new SKUs or locations every month, that difference between "someone remembers to update it" and "it updates itself" is usually where the real value sits.