Website voice assistant (embedded widget)

Website visitors often need more than a static answer but do not want to leave the page and place a call. A form makes them translate a question into fields, while a large navigation tree can hide the relevant policy or product detail. Live chat may solve the problem, but it still asks the visitor to type and may use a workflow separate from the phone team.

A website voice assistant gives the visitor a spoken path from the page they are already viewing. ThunderPhone’s embeddable voice widget can use an agent’s approved prompt, knowledge, and integrations, while widget sessions create call-history records and can produce the same transcript, recording, and grading data as phone calls. It is another entry point to a defined workflow, not a license for the agent to answer every question on the site.

A concrete website conversation

Consider a visitor comparing a business product on a pricing page.

Agent: I’m the website’s AI voice assistant. I can answer questions from approved information and help request a follow-up. What would you like to know?

Visitor: Will this product work with the system our team already uses?

Agent: Which system are you using, and which product configuration are you considering?

Visitor: I can give you the system name, but I am not sure which configuration I need.

Agent: The approved compatibility guide lists that system for one configuration and asks the sales team to confirm the others. I can collect your use case and schedule an available conversation rather than guess. Would you like to do that?

Visitor: Yes, tomorrow afternoon if possible.

Agent: I’ll check the connected scheduling calendar. Before booking, may I collect your name, work email, and the main requirement you want the team to review?

The assistant uses a bounded source for the answer, recognizes uncertainty, and moves into a connected scheduling flow. On a support page, the same channel could instead use the rules from support intake and triage.

How to configure it on ThunderPhone

First decide what the widget is for. A narrow FAQ-answering assistant needs different questions and tools from lead intake, scheduling, or support. Define the opening disclosure, allowed topics, required fields, escalation triggers, and what the assistant must say when approved material does not contain an answer. Include the page context in the workflow only when the site sends it through an explicitly configured path; do not assume the agent can infer everything the visitor sees.

Attach approved documents to the agent when the widget needs mid-conversation knowledge search. ThunderPhone’s organization document library accepts text, Markdown, CSV, PDF, and DOCX files, shows processing status, supports per-agent document scoping, and includes a built-in search tool. Select the relevant documents for the agent; uploads do not apply automatically.

Add only the integrations required by the chosen outcome. Cal.com or Google Calendar can support booking. HubSpot or Salesforce can receive an approved lead workflow. Google Sheets can hold a lightweight reviewed queue. A REST action or remote Zapier MCP server can expose a custom business function. Remote MCP servers are added by URL, synchronized for tool discovery, and attached to agents, with static HTTP headers supported. Keep each tool call narrow and validate failed writes before the assistant confirms an outcome.

Install the widget through the documented React or script-tag path. ThunderPhone supports agent-bound and webhook-routed modes, domain allowlists, origin-locked publishable keys, and enable or disable controls. Use an allowlist for the intended production domains and do not substitute a private server credential for the publishable browser key. Webhook-routed mode is useful when the business’s own endpoint must choose the call configuration; agent-bound mode ties the widget directly to the selected agent.

For call events, configure only the endpoints and subscriptions the downstream workflow needs. ThunderPhone supports multiple webhook endpoints with per-endpoint secrets, HMAC-SHA256 request signatures, and exponential-backoff retries for non-blocking delivery. The business remains responsible for its workflow, recording settings, data handling, and visitor notices.

Test with browser mic calls before publishing, then create reusable scenarios for supported questions, missing knowledge, failed scheduling, invalid fields, tool errors, and requests for a person. Browser-based calls are limited to cold transfer, so do not design a widget flow that depends on an attended warm handoff. The fallback can be a supported cold transfer or a clearly confirmed follow-up record.

What to measure

Measure the widget as a distinct entry point:

widget starts and completed conversations;
completion by intent, such as answer, intake, or booking;
knowledge searches that return no usable answer;
successful and failed integration actions;
qualified follow-up requests from lead qualification;
cold transfers and fallback completion; and
reviewed sessions containing unsupported claims or incorrect confirmations.

Compare results by page and intent. A pricing-page visitor and a support-page visitor should not be judged against the same desired outcome.

Honest limits

A voice widget depends on browser microphone permission, usable audio, and a visitor who is comfortable speaking. It should complement accessible text, forms, and human contact options, not replace them. The agent cannot see unprovided page state, guarantee who is speaking, or make a connected system succeed. Browser calls cannot use attended warm transfer. Sensitive decisions, account disputes, complex troubleshooting, and any request outside approved knowledge or tools still need a person.

For commerce-specific support patterns beyond the widget itself, see ecommerce support.

Create your ThunderPhone account to configure and test a website voice assistant.