Most voicebot buying decisions start the same way. We visit a few vendors’ websites, click “Play demo” and listen to a voice that sounds like a professional narrator: smooth intonation, the right pace, a warm tone. The first thought is immediate: great, our customers on the helpline will love this.
Then comes the rollout, and it turns out the same bot sounds nothing like the demo once it’s on the other end of a phone line. It sounds flat, stays silent too long, sometimes talks over the caller. A website demo and a real phone call are two different worlds. Between the voice generator and the customer’s ear sits something no speech synthesis model can influence: the telephone network infrastructure and the rules of real-time voice transmission.
What happens to the voice before it reaches the handset
The voice generated on a website is studio quality. It carries the full range of sound, from deep tones to the finest detail, and we listen to it on a laptop or in headphones, over a broadband internet connection. The telephone network, even today’s, works by rules set long before the age of AI.
To connect millions of callers at once, telecom infrastructure sharply narrows the audio bandwidth and compresses the signal. G.711, the standard telephone codec and still the basis of most voice calls, carries a band of roughly 300-3400 Hz. Newer standards (HD Voice, and the EVS codec on LTE and 5G networks) widen that band, but they rarely cover the whole route from end to end. Along the way there are call forwarding, transcoding between operators and older devices on the other end of the line.
It’s a bit like playing a 4K film on an old CRT television. No matter how good the voice engine you connect to the phone system (ElevenLabs, Azure or any other), the handset will deliver only as much as the telecom path allows.
Business takeaway: judging a voicebot only by audio samples on a website is like buying a car after seeing it in a well-lit showroom, without a test drive. The same goes for MOS, the score vendors like to use to describe codec quality. It rates a clean signal in a lab, not a real conversation with background noise, packet loss and a weak microphone on the caller’s phone.
It’s not one voice vendor’s fault
Let’s be clear: this is not a weakness of any particular speech synthesis platform. ElevenLabs and similar tools now even offer ready-made telephony integrations. The problem lies elsewhere: every voice, whatever its source, goes through the same limited telephone transmission path.
Business takeaway: “Does this voice sound realistic in the demo?” is easy to verify, which is why it dominates vendor selection conversations. What actually decides the quality of a phone conversation happens elsewhere: in the architecture of the whole system.
What actually determines the quality of a voicebot conversation
The voice is only one piece of the puzzle. Here are the ones that in practice weigh more.
Response time. Callers don’t judge the quality of the voice model. They notice how long they wait for an answer. In many deployments the bot’s response time reaches a second or more, while in a natural conversation we expect a reaction almost immediately. Past roughly a second to a second and a half, callers start saying “hello?” or talking over the bot.
Business takeaway: ask the vendor about response time in production conditions, not in the demo, and what that time looks like for the worst calls, not just the average ones.
Speech recognition in real conditions. A speech recognition (ASR) model tested on a clean recording performs differently with background noise, a choppy connection or unclear pronunciation. There is no single conversion rate for how much is lost over the phone, but we have a hard example of our own. In a deployment for Nexera, a fiber-optic network operator, the same bot, handling exactly the same case, correctly recognized the address in 80% of text conversations and in only 65% of voice conversations.
Business takeaway: require the vendor to test on specific, difficult cases from your industry (proper names, addresses, numbers), not on generic training material.
Interruptions and end-of-speech detection. A bot that doesn’t notice the caller has interrupted and keeps reading its planned line sounds artificial, whatever the voice.
Voicemail and call state detection. Without this mechanism, a bot may try to hold a dialogue with an answering machine or with silence, which hurts the effectiveness of outbound campaigns.
Whether the issue gets resolved. Research on the acceptance of conversational bots indicates that it depends mainly on usefulness and trust, not on how “human” the voice sounds. Callers judge a conversation above all by whether their problem was solved.
How this looks in practice: a KODA example
In the Nexera project, the KODA team tested the available speech recognition and synthesis components on difficult Polish place names (Gietrzwałd, Wąbrzeźno, Zawidz Kościelny) and chose a specific solution only after those tests, not on the vendor’s reputation. For the voice layer, as in the deployment for Veritas Group, we used AudioCodes VoiceAI Connect.
Designing for telephone realities also shows in small decisions. For Nexera, the pace of the mandatory GDPR notice was sped up, and during waits for responses from external systems we added filler sounds so the caller wouldn’t think the call had dropped.
Business takeaway: a good voice deployment is dozens of small decisions like these, not the choice of one best voice.
Questions worth asking your voicebot vendor
- What is the response time in production conditions, not in a recorded (and sometimes edited) demo?
- Was speech recognition tested on names and data specific to our industry?
- How does the system handle the caller interrupting the bot?
- Does it detect voicemail and other call states?
- How is quality measured: by how often issues get resolved, or only by how “natural” the voice sounds?
A realistic voice is a good starting point, but it isn’t the product. The product is the whole conversation.