A voice support agent is a text support agent with two lossy, latency-sensitive stages bolted on each end: speech recognition before the model and speech synthesis after it. Each stage adds delay, adds a way to be wrong, and adds a line to the bill. None of that makes voice a bad idea, but it does make it a different engineering problem, and you should know which problem you are signing up for before you buy or build.
LayBuild is text-only today. It answers on a web widget, on WhatsApp text messages and through a REST API. It has no phone or voice channel, and WhatsApp voice notes are rejected with a notice that media is not supported. This post explains the trade-offs in general terms, then why we chose text first.
Two pipelines, side by side
Text: customer types -> [retrieve -> generate -> check] -> text reply
Voice: caller speaks -> [detect end of turn] -> [speech-to-text]
-> [retrieve -> generate -> check] -> [text-to-speech] -> caller hears reply
(and meanwhile: listen for interruptions, cancel speech if the caller talks)The middle box is the same in both. Everything around it is what voice adds.
Latency: seconds are fine in chat and painful on a call
In chat, a reply that takes a few seconds is normal. The customer sees a typing indicator, often reads the answer as it streams in, and may be doing something else in another tab. Text is asynchronous; if the agent is slow, nobody is sitting in silence.
On a call, silence is the product failing. The caller hears nothing until every stage has done enough work to produce the first syllable. The delays add up in sequence:
- End-of-turn detection. The system has to decide the caller has finished speaking, which usually means waiting for a pause. Wait too little and you cut people off mid-sentence; wait too long and every turn starts with dead air.
- Speech recognition, ideally streaming so it finishes soon after the caller stops.
- Retrieval and generation, the same work a text agent does.
- Speech synthesis, which has to start producing audio before the full answer exists if you want to keep the gap short.
That last point has a knock-on effect. To keep latency down, voice systems speak the answer while it is still being generated. Any check that needs the complete answer, such as verifying the reply against the retrieved sources before sending it, either has to run on partial text or delay the first word until generation finishes. You end up trading safety checks against conversational speed in a way that text never forces.
Speech recognition errors land in retrieval
Text arrives exactly as the customer typed it, typos included. Speech arrives as the recognizer's best guess. General-purpose recognizers do reasonably on everyday language and worst on the things support conversations are full of: product names, plan names, order numbers, email addresses, postcodes, and anything spelled letter by letter.
In a support agent those errors do not stay cosmetic. The transcript is the retrieval query. A misheard product name retrieves the wrong article, and a model that answers faithfully from the wrong article gives a confident wrong answer. You can mitigate this with custom vocabularies, read-back confirmations ("I heard order 4 7 1 9, is that right?"), and by switching to a typed or SMS channel for identifiers, but each mitigation costs time on the call.
The output side has its own version of the problem. A text answer can contain a link, a numbered list of steps, a code, or a table of plan limits. Read aloud, a URL is useless and a five-step procedure is hard to follow. Voice answers need to be written for the ear, which usually means a separate prompt and often a separate follow-up message with the details in text.
Turn-taking is a real-time systems problem
People interrupt. They say "yeah" and "mm-hm" while you talk, change their mind mid-sentence, and talk over a reply they have already understood. A voice agent needs to hear the caller while it is speaking (with echo cancellation, so it does not hear itself), decide whether a sound is an interruption or a backchannel, stop the audio, discard the rest of the planned reply, and take the new turn. Getting this wrong in either direction is immediately noticeable: an agent that cannot be interrupted feels like a phone tree, and one that stops at every cough feels broken.
Text has none of this. Turns are explicit: the customer presses send.
Cost structure: per minute versus per message
We will not quote prices, because they vary by vendor and change often. The structure is stable enough to reason about:
- A text conversation costs model tokens for each reply, plus your platform fee.
- A voice conversation costs the same model tokens, plus speech recognition billed by audio time, plus speech synthesis billed by characters or audio time, plus telephony minutes if calls come over the phone network.
Voice cost scales with call duration, including the time spent on hold, read-backs and silence, while text cost scales with the number and length of replies. Voice sessions also hold an open, real-time stream for the whole call, so capacity planning looks like concurrent calls, not messages per minute. When you compare options, ask each vendor to price a realistic call length for your queue, not a per-minute headline.
When voice is worth the trouble
Voice earns its complexity when your customers already phone you and will keep doing so, when the questions are short and do not need links or identifiers, or when accessibility for callers who cannot easily type matters to you. It is a weaker fit for product and technical support where answers involve steps, settings and URLs, and for anything that needs an account number read out accurately.
A common middle path is to keep voice for routing and simple status questions and move the rest to text: send the caller a link to chat or a WhatsApp message, so the detailed answer arrives in a form they can reread.
Why LayBuild is text-first
We built LayBuild around one rule: answer only from your content, and when that is not possible, say so. Several parts of that design depend on text.
- The grounding check runs on the complete answer. After the model writes a reply, LayBuild compares its stemmed words with the retrieved sources, and if fewer than 25% of them appear there, it replaces the reply with a fixed "I do not have specific information about that" message. Text can be corrected after the fact: the web widget shows tokens as they stream, and the checked final message replaces the streamed text, while WhatsApp only ever receives the final checked reply. Speech cannot be taken back once the caller has heard it.
- The retrieval query is exactly what the customer wrote. There is no recognizer in the middle to mishear a plan name.
- Answers can carry what support answers usually need: links, short numbered steps and exact values.
- Output PII redaction works on text: card numbers, US Social Security numbers, emails and phone numbers in the reply become
[REDACTED]before it is sent.
We would rather do one channel type well than ship a voice mode where the safety checks are quietly weaker. If voice support is a hard requirement for you today, LayBuild is not the tool for that part of your queue; use a dedicated voice product for calls and consider LayBuild for web chat and WhatsApp text.
If you are evaluating a voice agent
Test it on your own recordings, not a demo script. Include the hard cases: callers reading order numbers and email addresses, background noise, accents your customers actually have, interruptions mid-answer, and questions your documentation does not cover. Check what the agent says when it does not know, and whether it can hand the call to a person with the transcript attached.
Related reading
For how LayBuild keeps text answers tied to your content, read preventing hallucinations in customer support. For the channels LayBuild does support and how they differ, see one conversation model for web chat, WhatsApp and the API, and for moving conversations to your team, safe human handoff and escalation.