TL;DR: The voice is not a branding choice, it is an engineering component with a latency cost, a locale, a set of pronunciations it will get wrong, and a provider who can change it under you without telling you. Almost every voice decision I have watched go badly was made in a browser preview player, which is the one place a phone agent will never be heard. Shortlist two or three voices, run the same sixty second script through each one over a real phone line on a real mobile, listen to the four moments that carry risk rather than the sales pitch, then commit and write down which voice and which version you shipped.
Clients pick the voice first. Before the flow, before the refusals, before anyone has decided which call is actually being lost, someone has opened the platform's voice library and started clicking play. It is the most fun part of the build and the part with the least information available, which is a bad combination.
I have shipped Retell agents for a US product at Tested Media and for UK hospitals, vet clinics, estate agents and garages at Fortell AI. The voice mattered every time, and it never mattered in the way it was chosen.
The preview player is not a phone line
The voice library plays you studio audio at full bandwidth through whatever headphones you own. Your caller hears the same voice compressed into a narrowband telephony channel, on a mobile, outdoors, possibly on speaker in a car.
That channel throws away most of the high frequency content, which is exactly where the breathiness, the sibilance and the fine texture live. Those are the qualities that make a premium voice sound premium in the demo. Strip them and two voices that sounded completely different in the browser can land within a hair of each other on the phone, while a third that sounded slightly dull in the preview turns out to be the clearest of the set because its intelligibility never depended on the top end.
This is the same asymmetry that makes phone transcription a different problem from recording a lecture. Information that never arrives cannot be recovered on either side of the call. So the only voice test that means anything is a test conducted over the phone, and the only opinion worth collecting is one formed after hearing it there.
The voice is a latency component
Time to first audio is part of the voice, not separate from it. Some voices synthesise and stream faster than others on the same platform, and the gap is audible at the exact moments that matter most: the greeting, and the first word after a caller finishes a sentence.
A voice that adds a couple of hundred milliseconds before every turn does not sound slow, which is the trap. It sounds hesitant. Callers do not think the system is lagging, they think it did not understand them, and they repeat themselves into the agent's opening syllable. Now you have an interruption to recover from that the caller caused and the tuning created.
I treat voice selection as one line in the turn latency budget alongside endpointing, the model and any tool calls on the critical path. If a more expressive voice costs meaningful time on every single turn, that is not a small price. It is a tax charged for the entire call, paid at the moments when the caller is already deciding whether this thing works.
Match the caller's ear, not the client's taste
The person choosing the voice is almost never a representative caller. They are the business owner, they have heard the greeting four hundred times, and they are picking something that sounds like the brand they wish they had.
The useful question is what a caller expects to hear when this specific number is answered. A vet clinic in a market town in the north of England answered by a polished mid-Atlantic voice reads as a call centre, and callers behave differently towards call centres. They get terser, they ask fewer questions, and some of them hang up to ring back later hoping for a person.
Locale is the concrete half of this and it is not only about accent. A US-configured voice on a UK line will also want to spell things the American way, read dates in the wrong order and put the stress in unfamiliar places. That is part of a broader set of things that break when a US-built agent answers a UK phone, and the voice is the most immediately obvious one to a caller.
There is a floor here too. Below a certain quality, callers start speaking to the agent as though it is a machine: clipped, loud, over-enunciated. That behaviour change hurts recognition accuracy, which hurts capture, which shows up in your numbers as a data problem rather than a voice problem. A voice that sounds like a person gets treated like one, and gets given better audio to work with as a result.
What a voice cannot fix
A good voice will not rescue writing that was composed for the page. Every rule about writing prompts for the ear still applies at full strength, and the better the voice, the more it exposes bad phrasing rather than hiding it, because there is no synthetic flatness left to blame.
Two specifics are worth checking before you commit to any voice.
The business name. It is the first thing every caller hears and it is the single most common mispronunciation. Clinic names, surnames, place names and anything with an unusual vowel are all candidates. Test the actual greeting, not a generic sample sentence, and if it comes out wrong, fix it with phonetic spelling in the prompt before you conclude the voice is unusable. Different voices in the same family often fail on different words, so this can genuinely decide a tie.
Numbers, times and readbacks. The moments where the agent confirms a booking time or reads back a phone number are the moments where clarity beats warmth. Some voices rush digit strings into an unbroken run. Hear that before launch, not from a client forwarding you a complaint.
The honesty rules
Two things I hold as non-negotiable regardless of what the voice can do.
The agent never claims to be human. If a caller asks directly, it answers honestly. A client asking for a voice specifically so callers cannot tell is a request I decline, and it is one of the red flags I listen for in the scoping call, because it usually signals a broader disagreement about what the system is for.
Cloning a real person's voice needs that person's explicit consent, not their employer's enthusiasm. Cloning the owner is sometimes genuinely good: their voice is what regulars expect and it carries the brand better than any stock option. Cloning a receptionist who was not asked is a different thing entirely, and it becomes an unpleasant conversation the moment they find out.
Neither rule costs anything on a well-scoped build. Callers do not mind being told they are speaking to an assistant. They mind being handled.
The voice is the least portable thing you own
Everything else in the build can be made portable with some discipline. The prompt is text. The post-call automation lives in n8n behind a webhook that any platform can call. The tools point at your own endpoints.
The voice does not move. It belongs to a provider, it is exposed through the platform you happen to be on, and it is the one asset your callers actually recognise. This is the quiet part of platform lock-in that people miss while worrying about their prompts: migrate, and regulars notice on the first call.
It also changes without you. Providers update voices. A model refresh can shift pace and intonation slightly on a Tuesday with no announcement you will see in time. Pin the voice and version in your config, keep that config in git with everything else, and treat a voice update the way you treat any other change you did not make, which is to say run the frozen scenario set and listen to a few real calls yourself.
How I actually pick one
Shortlist two or three. More than that and nobody can hold the differences in their head, and the fourth candidate is never the winner anyway.
Write one script of about sixty seconds that contains the four moments that carry risk: the greeting with the real business name, a time and a phone number read back, a refusal, and a handoff line. Run the identical script through every candidate. Never compare voices on different text, because you will end up choosing the sentence rather than the voice.
Then listen on a phone. Ring the agent from a mobile, once indoors and once somewhere noisy, and if the client will play along, get them to ring it too rather than emailing them audio files. Ask a narrower question than whether they like it: would you trust this voice with your booking, and does it sound like your business answering.
Then stop. Record the voice id, the version and the date in the config, and move on to the parts of the build that decide whether the agent is any good, which are the exits, the capture and everything that happens after the call ends. The voice gets a caller to keep listening for ten seconds. What you do with the rest of the call is the actual product.
I build production AI voice agents and the automation, CRM and telephony layer behind them for founders across the US, UK and Europe. More about my work here, or book a call.