Voice AI on your website — what it is, when to ship it, and what to watch out for

Voice on a website chat widget is one of those features that demos beautifully and underperforms in production — unless you ship it for the right use cases. Here's the honest cut: when voice actually helps, when it's noise, and the architecture decisions that decide whether it's a feature or a bug.

When voice on a chat widget is actually used

From real-world deployment patterns, voice gets used in three contexts and is largely ignored elsewhere.

1. Mobile with one hand busy

A shopper in a parking lot. A patient holding paperwork. A driver pulled over. Places where the visitor would type if they could, but finds typing awkward. Mic-button engagement on mobile is meaningfully higher than on desktop for this reason alone.

2. Accessibility

Visitors with motor impairments or visual impairments use voice input + spoken output as primary modalities, not novelties. If your audience includes accessibility-first users, this is a real product requirement.

3. Hands-busy professional contexts

Kitchens, repair sites, factory floors, field service. Places where the worker would otherwise call you — voice chat is a lower-friction call. If your customer base includes trades, healthcare, hospitality staff: voice gets used.

When voice is just demo theater

SaaS prospects browsing pricing pages on a desktop. B2B buyers researching during a meeting they shouldn't be in. People reading transcripts later. In these contexts the mic button gets clicked once for curiosity and then ignored — text is faster, transcript-friendly, and silent.

If your buyer persona is "office worker at a laptop", voice is a feature you list, not a feature that moves conversion.

The architecture that decides whether it works

Voice chat has two halves: speech-to-text (visitor speaks → text) and text-to-speech (agent's answer → audio). Each has a "right" way and a "shipped-fast" way.

Speech-to-text: in the browser, not on your server

The right architecture: the visitor's browser handles speech recognition through the Web Speech API, and only the transcribed text is sent to your server. The audio does not reach you — you do not receive it, store it, or pay to transcribe it. Worth knowing precisely: by default the Web Speech API is not on-device — in Chrome it forwards audio to the browser vendor's own recognition service — so the honest claim is that the recording stays out of your systems rather than out of the network entirely. On-device recognition is an opt-in the page has to request, and Edge and other Chromium forks expose the API but often fail to recognise speech.

The wrong architecture: visitor's audio is uploaded to your server, then forwarded to a speech-to-text API. This is technically valid, but it adds latency (audio is big, text is small), it raises privacy questions ("you recorded my voice and sent it to a third party"), and it tends to fail under bad WiFi.

Catch: Web Speech API browser support is uneven (Safari support has historically lagged Chrome / Edge). The fix is graceful degradation — hide the mic button when the API isn't available, keep the text chat unchanged.

Text-to-speech: server-side, streamed

The right architecture: server generates the audio chunk-by-chunk as the LLM produces the answer, and streams it back over WebSocket / Server-Sent Events / chunked HTTP. The visitor starts hearing the first sentence within ~1s; the rest streams while they listen.

The wrong architecture: wait for the full answer to render, then synthesize the full answer, then play. By the time audio starts, the visitor is reading the text response.

Catch: TTS pricing is per-character. A 200-character answer is cheap. A 2,000-character answer is 10× as expensive. Plan quota carefully and surface it to admins.

The grounding question — does the voice agent still cite sources?

It should. The voice layer is purely input/output transformation; the agent's grounding contract (answer only from your content, with sources shown on grounded replies) shouldn't change because the visitor used the mic. The audio just reads out the answer that would have been displayed.

If a voice agent goes off-script and starts inventing answers because the spoken context "felt more conversational" — that's a system-prompt bug, not a voice-specific limitation. The constraint should be identical.

What to enable, what to leave off

• Enable on: e-commerce on mobile, home services, restaurants, hospitality, healthcare intake, real estate, creative-service intake
• Leave off on: desktop-heavy SaaS, B2B sales sites, technical docs sites
• Offer a mute / pause control — visitors in shared spaces don't want autoplay audio
• Provide a text alternative — the mic button is an add-on, not a replacement

Our setup

NovixAgent AI runs the browser-side STT described above: the mic button uses the Web Speech API, and only the transcribed text reaches us.

Playback is deliberately not the streaming case. The agent's answer is already on screen by the time a visitor wants to hear it, and the visitor decides whether they do — tap Listen on an answer, or switch on auto-read and each answer plays as it arrives. Because the text is finished before audio is asked for, there is no audio to stream ahead of the text: the clip is synthesized server-side, delivered as one finished clip, and cached in the browser for the session so replaying a recent answer needs no further synthesis. Streaming matters when the visitor is listening instead of reading; here they are doing both.

Voice unlocks from the Pro plan ($99/mo) with 150k chars / mo of TTS per month; Business ($399/mo) ships 500k chars / mo. See the voice use case for the full breakdown.