How to add a voice assistant to your website

This page may contain affiliate links from which Blur Studio earns commissions.

A voice assistant on a website is a real option now, not a novelty, but it solves a narrower problem than most people assume: it helps visitors who'd rather speak a question than type it, especially on mobile or when they're doing something else while browsing. It isn't automatically better than a well-built text chat widget, and it comes with its own failure modes (background noise, awkward pauses, people unsure when to talk) that a chat box never has.

Start with a chat widget first if you don't have one

If your site has no conversational help at all, a text chat widget is the cheaper, lower-risk starting point. Most visitors are entirely comfortable typing a question, and a text widget has none of voice's technical overhead (microphone permissions, background noise, knowing when it's your turn to talk). Add voice specifically once you've identified a real reason visitors would prefer it, not because it sounds more advanced. Setup without keys is covered in how to add an AI chatbot to your website without handling API keys.

Where a voice agent fits

ElevenLabs' agent platform builds a voice assistant from a written script, a chosen voice, and a knowledge base of your actual product or service information, then embeds it on your site as a widget visitors can talk to. Pro is $99 a month with roughly 1,238 minutes of agent conversation included, Scale is $299 with about 3,738 minutes, and Business is $990 with about 12,375 minutes; usage beyond your included minutes runs close to $0.08 a minute, with the underlying language model billed separately. See ElevenLabs' current plans before choosing a tier based on expected visitor volume. The phone version is covered in ElevenLabs Agents for a phone agent.

Two different jobs that both get called "a voice widget"

"Add a voice assistant" means something quite different depending on what your site actually does, and it's worth being specific before you build anything.

• An ecommerce or service site mostly wants quick product or service questions answered: sizing, shipping, return policy, whether something is in stock. These are short, factual exchanges, and a voice widget earns its place by being faster than searching a help page, especially on mobile where typing is more friction than talking.
• A software or online-tool site often wants something closer to guided onboarding: walking a new visitor through what the product does, answering "does this do X," and routing anyone who's ready to buy toward a demo or trial signup. This is a longer, more exploratory conversation, and it benefits more from a deeper knowledge base (your docs, your pricing page, common objections) than from speed alone.

Write the agent's brief for the specific one of these that matches your site, rather than a generic "answer whatever visitors ask" instruction, since the two jobs reward different lengths of response, different tones, and different things to hand off to a human.

What the embed actually involves

Adding the widget to your site is a small, mechanical step once the agent itself is built: it's a short script snippet you add to your site's template, similar to adding any other third-party chat or analytics widget, not a rebuild of your site's front end. The real work is everything before that point, writing the script, loading the knowledge base, and testing the conversation, not the embed itself. If your site is built on a common platform (Webflow, Shopify, WordPress, a custom build), the snippet drops in the same way a chat widget's would, usually in a header or footer include.

Step by step

1. If you don't have a chat widget, start there and see how much of your visitor-question volume it actually handles.
2. Decide the specific job the voice assistant should do: answer product questions, qualify a lead, help someone find the right page. A vague "general assistant" brief produces a vague, unreliable agent.
3. Load your real product or service information into the agent's knowledge base so it answers from your actual content, not a generic script.
4. Test it yourself with background noise playing and on a real mobile connection, not just a quiet office with fast wifi, since that's closer to how most visitors will actually use it.
5. Launch to a small share of traffic first and read the conversation transcripts before rolling it out site-wide.

Practical tips from actually testing one of these

• Noise and latency are the real adoption blockers, not the voice quality. ElevenLabs reports a typical response time around 680 milliseconds and up to about 1,560 milliseconds in slower cases. On a good connection that feels natural; on a noisy phone connection or a slow network it can feel like the assistant is lagging or mishearing, which is usually what actually turns visitors off, not the voice itself. Speed fixes are in why your AI phone agent replies slowly.
• Give visitors an obvious way to switch back to typing. Not everyone wants to talk in a public space, an open office, or on a call with someone else nearby. A voice-only widget with no text fallback loses those visitors entirely.
• Keep the first response short. A long opening line before the visitor can say anything feels slower than it is. Start with a brief greeting and let the conversation build from there.

A recent shift worth knowing about

ElevenLabs released a conversational-specific version of its v3 model built for exactly this kind of back-and-forth dialogue rather than reading out a single block of text, supporting more than 70 languages with a per-request character limit of 5,000. If you're building a voice widget now rather than a year ago, that's the model worth testing against your actual script, since a model built for one-shot narration and one built for live conversation behave differently on interruptions, short replies, and the kind of back-and-forth a real visitor produces. Don't assume whichever model a tutorial used six months ago is still the best default.

How to tell if it's actually working

Don't judge this on whether visitors use it, judge it on what happens after they do. Track three things from the start: how many conversations end in the outcome you actually wanted (a booking, a qualified lead, a question answered without a support ticket), how many get handed off to a human versus resolved by the agent alone, and whether visitors who use it convert at a different rate than visitors who don't. A widget that gets used constantly but never leads anywhere useful isn't a success just because people are talking to it; usage without outcome is a vanity metric here, the same way raw chatbot message counts often are. Pull these numbers after the first few weeks, not just once at launch, since early usage from curious visitors testing the novelty doesn't tell you much about steady-state value.

What I'd tell a site owner weighing this

Voice on a website is genuinely useful for a specific kind of visitor and a specific kind of question, usually something simple enough to ask out loud ("do you ship to Canada," "what's included in the basic plan") while they're half paying attention to something else. It's a weaker fit for anything that benefits from reading, comparing numbers, or taking time to think, which is most of what serious buyers actually do before purchasing. I'd add it as an option alongside text, not a replacement for it, and I wouldn't build it before you have real data from a text widget showing what visitors actually ask. That data does double duty: it tells you whether voice is worth adding at all, and it gives you the actual question list to build the voice script around, instead of guessing what visitors want to ask out loud.

One more honest point: a voice widget is a visible, somewhat novel feature, and that novelty can create pressure to ship it because it looks impressive on a sales call or a demo, not because visitors are actually asking for it. Resist building it for that reason alone. The sites that get real value from this are ones where a genuine, frequent visitor need exists for a spoken interaction, not ones adding it as a differentiator with no evidence anyone wants it.

How I'd approach this

The basic setup, a voice widget answering from your product content, is something you can build directly on ElevenLabs' own platform without custom code. Where I get involved is connecting the assistant to live data, real inventory, real pricing, a real booking calendar, so it's answering from what's actually true right now rather than a document that goes stale, and building the logic for when it should hand a visitor to a human instead of guessing.