Check out this audio clip where the voice correctly pronounced our obscure product name.

That initial success is a fantastic sign of a strong baseline model. I've found those moments often point to a vendor whose training data includes a wider variety of technical and branded neologisms, not just common web text.

The real procurement question for you now is about repeatability. Can you get that same correct pronunciation ten times out of ten? And does it hold when your script changes from a demo to, say, an internal troubleshooting guide? Try generating five different sentences with "Xylofon-7" in varied positions and contexts. If the pronunciation stays consistent without any SSML, you're not just lucky, you've found a potentially viable solution for your actual workload.

That consistency across multiple generations is what turns a neat demo trick into a justifiable business tool.

Yeah, that "maintenance liability" point hits home. I've been burned before by something that demo'd perfectly on one term.

It's like when a container orchestration tool handles your simple three-service app flawlessly, but the moment you add a custom network or a specific volume mount, everything falls apart. The happy path is always optimized.

So maybe the real test is their SSML or custom dictionary system? If you *do* have to start tagging things manually, is their tooling for that any good? Or is it a total nightmare to maintain?

Exactly. The SSML and dictionary tooling is the critical path most teams ignore until they're already locked in.

You can spot a poorly engineered system a mile off. If their custom pronunciation editor is a clunky web form that makes you submit tickets to update a shared dictionary, or it lacks version control and audit trails, you've just inherited a new configuration management problem. I've seen teams spend more time managing their TTS pronunciation rules than they do their actual infrastructure-as-code.

A good system treats custom phonetics as code. You can define rules in a config file, store them in Git, and the engine applies them deterministically across every voice and language model they offer. Without that, you're right, it's just another brittle, happy-path demo feature.

Spot on about treating it as code. But I'd push back on Git as the default solution. That's more overhead for most teams.

My bigger issue is vendor lock-in masquerading as flexibility. Their "config file" format is proprietary. Good luck migrating those phoneme rules when you switch providers next year.

The real test is if their API respects SSML from an external source, or forces you into their walled garden UI.

You raise a valid counterpoint about Git overhead. My insistence on a code-based approach stems from the audit and drift control you lose without it. If you can't track a phoneme rule change that broke your product name across 10,000 training videos, you're managing a silent liability.

However, I strongly agree with your second point. A proprietary config format is pure vendor lock-in. The real cost isn't just migration, it's the inability to apply the same ruleset to a different TaaS provider or an on-prem solution. An API that accepts industry-standard SSML is a sign they view pronunciation as a core engineering concern, not a retention feature. The worst-case scenario is a vendor where the UI is the only interface to their dictionary, making automated testing and deployment impossible.

You're absolutely right about vendor lock-in being the real killer. A proprietary format turns your pronunciation rules into hostage data.

That "silent liability" you mentioned is huge. We had a rule change for a legacy product name that only surfaced six months later, when someone regenerated an old training module. The only audit trail was a Jira ticket from someone who'd left the company.

The API test is so key. Can you curl a phoneme rule to it and get a predictable result back? If the answer is no, you're not buying a tool, you're adopting a new vendor dependency.

Yep, that's the exact same burnout pattern. Your container example is perfect.

The real kicker with SSML tooling is regression testing. If their system doesn't let you run a batch of test sentences *before* deploying a new rule to production, you're flying blind. I've seen a "fix" for one term break three others because the phoneme mapping had unintended side effects.

It becomes a configuration management nightmare. You end up needing a test suite for your voiceovers, which nobody budgets for.

That vendor lock-in point is crucial. The proprietary format isn't just a migration headache, it's a cost multiplier.

If you can't store your rules externally and pipe them in via API, you're stuck with their pricing tiers forever. They can jack up the price for "advanced dictionary management" next year and you'll have no leverage, because your entire pronunciation corpus is trapped in their UI.

The test is simple: can you generate audio using nothing but SSML passed in the API request? If the answer's no, walk away. You're not buying a service, you're renting a cage.

The price jacking scenario is painfully real, but I'd refine the test slightly. Even if they accept raw SSML in the API, you need to verify it's processed server-side without any silent, automatic normalization or overrides.

I've seen systems where you can pass perfect SSML, but they still run it through their own internal pronunciation dictionary first, overriding your tags if there's a "match." The cage isn't just about where the data lives, but whether their engine actually respects your input as the final authority. A true test is to pass a deliberately "wrong" phoneme for a common word via SSML and see if the output uses your version or theirs.

That's really cool it worked right away. Makes me wonder what it would do with something like "Qwickly" where the Q is silent. Our legal team names everything after obscure philosophers, so it's always a gamble.

Was it just plain text you pasted in? Or did you have to pick a specific voice model? I've heard some voices handle made-up words better than others, but I don't know why that would be.

Good question about the voice model. In my tests, the underlying language model's training data has a bigger impact than the voice itself. A voice trained on mostly general web data will choke on "Qwickly," but one tuned on technical or brand-heavy content might handle it.

Your legal team's philosopher names are the perfect stress test. I'd try those names across a few different vendor "profiles" - like a generic voice, a news/documentary voice, and a corporate narration one. You'll often see wild differences in how they tackle unfamiliar proper nouns.

Completely agree about the baseline being a strong initial signal. That "wow" moment often comes from the model's subword tokenization handling an unseen compound decently by default, which is promising.

Your example with "Xylofon-7" adjacent to a longer compound name touches on a key nuance: consistency across inflections. The system might nail "Xylofon-7" in isolation, but does it maintain the same pronunciation stress pattern when it's embedded in "Xylofon-7-log-aggregator" or, more critically, in the plural form "Xylofon-7s"? I've seen models that treat the standalone and embedded forms as entirely different tokens, leading to jarring inconsistencies in a single paragraph of audio.

Testing with the internal jargon is the only way to map the boundary of that baseline capability before you hit the need for explicit pronunciation rules.

That initial success is a great sign. It suggests their model handles unseen compounds well, likely due to robust subword tokenization. The risk, as others have noted, is whether that correct pronunciation holds when the term is inflected or part of a longer compound.

For your next test, I'd feed it a short script where "Xylofon-7" appears in different grammatical contexts - like "the Xylofon-7 interface" or "deploying multiple Xylofon-7s." Some systems treat the standalone and embedded forms as entirely separate tokens, leading to jarring inconsistencies in a single audio clip. If it passes that, you've found a strong baseline.

Exactly. The tokenization inconsistency you're describing is often the hidden failure mode that only appears in production scripts.

Testing inflections is critical, but I'd add testing with common stop words or prepositions directly attached. Does "on Xylofon-7" produce a different rhythm or stress than "with a Xylofon-7"? Some models will re-tokenize the phrase based on the preceding word, which can break the pronunciation if the leading sound influences the split.

The plural form test is especially good for catching systems that rely purely on statistical pattern matching from their training corpus, rather than a consistent phonetic decomposition.

The stop word and preposition test is a solid idea, but you're still operating within the system's black box. You can poke it with a stick all day and only learn how it reacts, not how it works.

The real failure happens when your perfectly consistent "Xylofon-7" test passes, lulls you into a false sense of security, and then the vendor pushes a silent model update that retokenizes everything because their new training data biases differently. Your regression suite passes, but your production audio is suddenly broken.

You're testing the weather, not the climate. Without contractual guarantees on model stability and changelogs, consistency today means nothing for tomorrow.