As a clinic or salon owner, every missed call is a lost customer. Most callers hang up rather than leave a voicemail and just call the next business on the list.
A growing number of SaaS sites try to fix the website side of this with an "AI voice feature" — usually a text chatbot wired to the browser's Web Speech API. A microphone icon captures audio, browser speech-to-text turns it into text, the existing chat logic answers, and text-to-speech reads the response back. It feels like a voice agent. Architecturally, it isn't one, and the difference shows up the moment a real visitor uses it.
A genuine voice agent has to handle three things a chat-widget-with-a-mic doesn't:
Barge-in. A visitor should be able to interrupt the agent mid-sentence ("no, I meant the dental package") without waiting for playback to finish. Pipelines built for chat don't expect this — capture and playback run on separate, unsynchronized timers, so an interruption either gets ignored or both streams talk over each other.
Turn-taking latency. Text chat tolerates a 2-3 second "thinking" pause; nobody notices. Voice doesn't. Past roughly 800ms of dead air after a visitor stops talking, it reads as broken rather than "the AI is working." That forces real architecture decisions: streaming speech-to-text with partial transcripts, and a model call that starts generating before the utterance is even fully confirmed.
Data residency and consent, scoped correctly. Capturing raw microphone audio from an EU visitor is squarely GDPR territory the moment it leaves the browser, and it's a different consent surface than a typed chat message. A few defaults that hold up under DSGVO scrutiny in practice: process and store transcripts on EU-hosted infrastructure, get explicit (not pre-ticked) consent before the mic activates, and keep the raw audio ephemeral — store the transcript, discard the recording unless there's a specific reason to keep it.
We ran into all three of these building the website voice agent inside Hallodesk — the same engineering constraints as our phone-based AI receptionist, just running in a browser tab instead of over a SIP trunk. The interesting part is that "voice on the web" and "voice on the phone" end up needing nearly the same pipeline (streaming STT → low-latency LLM → streaming TTS), just with a different transport layer and a different consent flow at the front.
If you're scoping something similar, the Web Speech API spec is a reasonable starting point for what's natively available in-browser before you need a dedicated streaming pipeline, and GDPR.eu's consent guidance is worth reading closely if your audio capture targets EU visitors — "consent" has a narrower legal meaning than most chat-widget cookie banners imply.
Top comments (0)