Skip to content
All posts
9 min read

Why AI answers your customers by text before it answers by voice

Voice is the thing every vendor demos. Text is the thing that holds up right now. The gap between them isn't hype-cycle noise — it's structural, and it changes what you should ask before you sign anything.

aicustomer communicationtext messagingvoice aivendor evaluation
Cover illustration for “Why AI answers your customers by text before it answers by voice”

It's a Thursday morning and a homeowner has a dishwasher leaking onto her kitchen floor. She calls the first plumber on her list. What answers is a recorded voice offering a menu of options, none of which is the thing she needs. She waits it out and asks for a representative. The line pauses, then reads her the same menu again. She asks a second time, louder, enunciating at the machine the way everyone does, as though the problem were volume. It offers the menu once more.

She hangs up, texts her neighbor to ask who they used last spring, and has a name and a number back before she's finished mopping.

Both halves of that matter. The automated voice failed her in under a minute. The text thread worked immediately. That contrast isn't an accident of one bad phone tree, and it isn't a temporary state of the technology that the next model release will quietly fix. It's structural — and it's the most useful thing to hold onto while being pitched an AI answering service.

the demo is the easiest day that software will ever have

If you've sat through a voice AI pitch, you've heard a clean, warm, startlingly human-sounding agent take a call and book an appointment without a stumble. It's genuinely impressive. It's also the least representative artifact in the entire sales process.

Consider the conditions it was built in. A quiet room. A good microphone, or a direct browser connection that never touches a phone carrier at all. A speaker with no accent the model finds difficult, at a measured pace, walking a path the builder has walked a hundred times. Engineers who write about why voice agents fall over in production are blunt about this: the demo environment is clean speech, quiet rooms, direct connections, and prompt paths the builder already knows by heart. Almost any modern voice stack performs well under those conditions. That's exactly why demos sell and deployments disappoint.

Real calls arrive differently. Someone is in a truck cab with the window down. Someone is standing next to the running dishwasher that's the whole reason they're calling. There's a television, a dog, a kid. The audio has been squeezed through a carrier codec built for different priorities. None of that is in the demo. All of it is there on Tuesday.

what voice is actually up against

Four things make live voice genuinely hard, and none of them are about the language model being clever enough.

It has to hear correctly, on the first pass. Speech recognition sets the ceiling for everything downstream — wrong words in, wrong actions out. Research presented at speech-technology conferences has found that overlapping speech in a noisy environment can push transcription error rates several times higher than the same words spoken into clean audio. And the failure isn't always a blank: work investigating a widely used open speech-recognition model found that non-speech audio — silence, music, a television in the next room — could induce it to emit fluent, confident text nobody had spoken. Mishearing produces gibberish, which is obvious. Hallucinating produces a plausible sentence, which is far harder to catch.

It has to be fast. Contact-center research has consistently found that once a reply takes longer than about a second, callers register it as a fault, and abandonment climbs from there. A voice pipeline has to transcribe, think, and speak, and every stage adds delay. Text has no such clock. A reply that arrives twenty seconds later is an ordinary text message. Twenty seconds of silence on a call is a hang-up.

It has to survive interruption. Barge-in — the caller talking over the machine — is normal human behavior and a persistent source of failure. The software has to notice someone started talking, stop, work out whether they've finished, and remember where things were. Interruptions also chop the audio in ways that make recognition worse, at the moment accuracy matters most.

It has no undo. On a call, every mistake is delivered live into a person's ear. There's no editing it, no catching it before it lands. And patience is short: studies of automated phone menus have found that a large majority of callers try to bypass the menu entirely, and that a striking share have hung up on such a thing out of frustration — which is what the homeowner did, before the software ever got a chance to be useful.

text is forgiving exactly where voice isn't

Put the same job in a text thread and the constraints fall away one at a time.

There's no microphone, so there's no room noise, no accent problem, no codec, no barge-in. The message arrives as the customer typed it. Typos and autocorrect exist, but they're cheap failures — the words are on the screen, and the customer can see what they sent. It's asynchronous, so nobody stands in silence waiting for a machine to think, which removes the latency problem outright. Everything is written down by default — the address, the appointment window, the description of what's wrong — without anyone transcribing a thing.

A wrong turn is recoverable. If the reply misreads a request, the next message corrects it and the thread carries on; the customer re-reads it and sees the fix sitting next to the error. On a call, the same mistake has already gone into the air, and repairing it takes an apology, a re-explanation, and a caller who has now noticed they're talking to software.

And here's the property that matters most: a person can take over mid-thread and the customer never has to know. In a text conversation a short pause is normal, so a human stepping in reads as nothing at all — the next message simply arrives. A voice handoff, by contrast, is an event. Practitioners who write about escalation design are direct about the difference: in chat a short delay is expected and the human just answers, while on a call a transfer needs hold protocols, warm-transfer briefings, and live transcription so whoever picks up knows what was discussed — because even a couple of seconds of dead air makes a caller think something's gone wrong.

That property is why text is safe to put in front of customers before it's perfect. When the software gets confused, a human absorbs it invisibly. On voice, the seams show.

what text gives up

It'd be dishonest to write all that and skip the other side.

Some people want to talk to a person, and no amount of tidy threading changes it. Emergencies want a voice. A customer trying to explain something complicated or upsetting is badly served by a text box. Plenty of callers — often, though not always, older ones — will just call, and keep calling, and a business that answers only by text is failing them. Text carries its own friction too: business texting sits behind carrier registration, a compliance step voice doesn't have, so the channel that's technically easier is administratively slower to switch on.

And there's something I genuinely can't tell you: what the split looks like for your customers, in your trade, in your town. Nobody can. The right answer probably isn't a single channel — it's a phone a human still picks up when they can, and a text lane that catches what the phone drops.

three questions worth asking any vendor

None of this requires hiring anyone. It does give you a short list that separates a real deployment from a good demo.

What happens on a mishear — can you show me? Ask them to demo the failure rather than the success. Have someone speak with a strong accent, or take the call next to a running blender. Every vendor can show you the happy path; the recovery path is the actual product.

Can a human take over mid-conversation, and will the customer notice? This reveals fast whether a vendor has run this with real people. There should be a specific answer: where the takeover happens, what the person sees, how they know to step in. If the answer is a plan rather than a screen, the honest translation is that it doesn't exist yet.

Where was that demo recorded? If the answer is a browser tab in an office, you haven't seen the product. Ask for a recording of a real call, over a real phone network, with a real customer who didn't know they were part of a pitch. A vendor who has that will be glad to play it; one who doesn't will change the subject to the roadmap.

That last question is one we have to answer too, so here it is plainly: on Catalyst Growth, Sarah communicates with leads by text today, and voice is coming rather than live. Live texting for a business switches on as carrier approval for business messaging clears, and until then a person on our team runs the front desk by hand. It isn't the most impressive version of the story. It's the one that survives contact with a customer.

the point

Voice will get there. The people working on it are serious, and the recognition problems are engineering problems rather than mysteries. But the honest read today is that voice is the thing that demos well and text is the thing that holds up while nobody's watching.

Text is forgiving. It waits for you, it lets you fix your mistakes, it writes itself down, and it lets a person quietly step in when the software runs out of road. None of those are exciting properties. They're the properties that get a homeowner with a leaking dishwasher an answer before she's finished mopping — which was the only thing she ever needed.

Building something? Let's talk.

Tell us what you're working on and a real person will reply.