How do I install the Zumu chat widget on my site?

One script tag in your layout, loaded async, carrying your widget id. It creates its own container, mounts itself, and exposes a small window API for opening and closing the panel, identifying a signed-in user, and registering client tools of your own. There is no build step and no package to add.

Will the widget break my site styles?

No, because it renders inside a shadow root. Your stylesheet cannot reach into the widget and the widget cannot reach out into your page, so a global reset on your side and the widget’s own layout stay out of each other’s way. Theming happens through data attributes on the script tag: position, colours, font, avatar, corner radius, launcher style and whether the Zumu footer shows.

Can visitors talk to the agent instead of typing?

Yes. The widget runs three modes: chat, a real voice conversation in the browser, and a page overlay. Voice connects a live audio session from the browser to the same agent that takes your phone calls. It is off by default and enabled per agent, so a text-only widget stays text-only until you decide otherwise.

What can the agent do to my page, and who approves it?

There are eight page tools: read the page context, navigate, highlight an element, scroll to something, fill a form, click a control, run a spotlight guide, and annotate the screen. Each one passes through an allow or deny confirmation dialog in front of the visitor before it runs. The dialog names the tool and what it would touch, and a denial is handled as an ordinary outcome.

Does the widget answer the same way as the phone agent?

It is the same agent. One configuration carries the prompt, the tools, the MCP servers and the knowledge base across phone, widget and email, so the three cannot drift apart the way separate vendors do. Email works a little differently by design: the agent drafts the reply from the thread and one of your people sends it, skips it, or asks for another draft.

Chat widget, voice and email

Your chat widget has never heard one of your phone calls. One agent answers everywhere.

The Zumu AI chat widget is the agent that already answers your phone. One script tag puts it on your site, a shadow root keeps it out of your CSS, and it works from the same knowledge, the same tools and the same handoff to your people as the call it took an hour ago.

One script tag, no build step
Shadow DOM, so your CSS stays yours
Voice in the browser, not only typing
The same knowledge as your phone line

Book a demo Watch it ask permission

script tag puts the widget on every page of your siteLoaded async, and nothing about your build has to change: 1
page tools the agent can run on the visitor’s own screenEvery one of them asks the visitor for permission first: 8
widget modes: chat, voice in the browser, and a page overlayVoice is off by default and switched on per agent: 3
languages live today, English and SpanishThe speech stack underneath supports 10+, tuned one at a time: 2

These are properties of the product rather than projections of your results. Voice in the widget is opt in per agent, and a page tool does nothing at all until the visitor allows it.

The widget on somebody else’s page

It can act on the page, and it asks first

A visitor asks a question, the agent answers it, and then it offers to do the next part for them. What happens next is the whole point: a dialog naming the tool and the exact fields it would write, with a decline that is a real answer.

northgate-mobility.example/schedule-a-rideMock customer site

Northgate Mobility

Schedule a ride

Non emergency medical transport across the north metro.

Ride requestStep 1 of 2

Pickup address

4180 Federal Blvd

Destination

VA Medical Center, Federal Blvd

Appointment time

You still pick this one

Coverage area

Weekday service across the north metro, plus Saturday mornings to the hospital corridor.

Zumu is asking

Allow Zumu to fill this form?

Toolfill_form

Fields it would write

Pickup address
Destination

AllowDeny

The agent can touch only what is listed here, and only once you say so.

Your visitors do not read about the answer. They watch the agent get it. It can ask to fill a field, highlight a section, or walk somebody through a page it can see. Each of those requests stops here, in front of the visitor, with the tool named and the scope listed. A denied tool is a normal outcome rather than an error.

What channel sprawl costs you

Three vendors, three memories, one confused caller

Support fragments channel by channel, and the seams show up on the customer’s side rather than yours. They are the one who has to repeat themselves.

Stitched together

A phone bot from one vendor, a chat widget from another, and an inbox answered by hand.
The chat vendor has never heard a single one of your calls.
One policy change means editing three sets of canned replies and hoping they agree.
A visitor who gave up on chat calls you and tells the whole story again from the top.

One agent

One agent configuration answers the phone, the widget, and the inbox.
One knowledge base behind all three, so the answer is the same answer.
One escalation path: a person takes the thread over and keeps everything already said.
One place to read what happened, whichever door it came through.

Channels are where support quietly comes apart. Zumu treats them as one surface with three doors.

Installing it

One script tag, and it stays on its own side of the wall

No package to add, no build to change, and no chance that your reset and the widget’s layout end up fighting over the same button.

The embedindex.html · paste once into your layout

<script
  src="https://agents.zumu.ai/widget/widget.js"
  data-widget-id="wgt_8f2c41"
  data-base-url="https://agents.zumu.ai"
  async
></script>

The widget id is the only thing that changes between sites. Everything the agent knows comes from the configuration behind it rather than from the tag.

No build step on your side: The script creates its own container, mounts itself, and exposes a small window API for open, close, setUser and your own client tools.
Themed with data attributes: Position, colours, font, avatar, corner radius, launcher style and the powered-by footer are attributes on that same tag rather than a fork of the widget.
Routed before the first word: Routing rules match a visitor to the right agent by geography, page URL, business hours or a department menu, so the conversation starts in the right place.

Style isolationneither side reaches the other

Your stylesheet

button { border-radius: 0 }
* { font-family: Georgia, serif }
.card { box-shadow: none !important }

Widget shadow root

:host { all: initial }
.launcher { border-radius: 999px }
.panel { box-shadow: 0 24px 48px … }

Neither side wins the specificity argument, because neither side can see the other one. Your reset cannot flatten the widget, and the widget cannot restyle your page.

Page tools

Eight things it can do to a page, and eight permissions

Most chat widgets can only describe your interface back to you. This one can drive it, which is exactly why every single action stops in front of the visitor first.

read_page_context
Read what the visitor is actually looking at, so the answer matches the page rather than the average page.
Confirmation required
navigate_to
Open the right page instead of describing where to find it.
Confirmation required
highlight_element
Point at the exact field or section under discussion.
Confirmation required
scroll_to
Bring that thing into view rather than saying it is further down.
Confirmation required
fill_form
Put what the visitor already said into the form, so nobody types their address twice.
Confirmation required
click_element
Press the control somebody is stuck on, once they ask for that.
Confirmation required
show_guide
Run a spotlight tour through a flow that takes more than one screen.
Confirmation required
annotate_screen
Draw on the page to show what happens next.
Confirmation required

Every one of these acts on somebody else’s screen, so every one of them stops at a confirmation dialog first. The visitor reads the tool name and what it would touch before anything runs, and declining is a normal answer.

An agent that can show a visitor where the button is beats an agent that can only describe it.

One configuration, three doors

What carries across the channels, and what does not

Configure the agent once and it shows up on the phone, in the widget and in the inbox. A few rows below say no. A page tool or a live chart has no meaning on a phone call, and an email does not talk back.

Carries across	Phone	Widget	Email
One agent configuration	Yes on Phone	Yes on Widget	Yes on Email
The same knowledge base and citations	Yes on Phone	Yes on Widget	Yes on Email
MCP servers and your own tools	Yes on Phone	Yes on Widget	Yes on Email
Handoff to a personWarm on the phone, one click takeover in chat, a person sends the email	Yes on Phone	Yes on Widget	Yes on Email
Transcript, outcome and reporting	Yes on Phone	Yes on Widget	Yes on Email
Spoken conversationIn the widget that is a real voice call in the browser, opt in per agent	Yes on Phone	Yes on Widget	Not on Email
Page tools on the visitor’s screen	Not on Phone	Yes on Widget	Not on Email
Live UI in the conversationCharts, tables and approve-or-deny prompts render inline in the chat, not just text.	Not on Phone	Yes on Widget	Not on Email

On email the agent drafts the reply from the thread and your person sends it, skips it, or asks for a different draft. Gmail is the connected inbox today, and the drafts are held in a single ingester so a restart never sends the same reply twice.

Voice is the protagonist. Chat and email are companions, configured once alongside it.

Before you finish signing up

It reads your website before it answers anybody

Onboarding points a crawler at your own site and builds the first knowledge base out of it, so the widget you paste in has something true to say on day one. You correct it from there instead of starting at an empty box.

How the knowledge graph gets built

What the widget is allowed to do

page tools the agent can run on your visitor’s own screen, each one behind a confirmation dialog somebody has to accept.

3: widget modes: chat, voice in the browser, and a page overlay
1: script tag, loaded async, with nothing to change in your build
2: languages live today, English and Spanish
10+: languages the speech stack underneath already supports

Product properties, not projections of your results.

A customer at home in the evening typing into a chat widget on a company website

Half past nine, and somebody still wants an answer.

The widget is the surface. Two other pages cover what sits behind it.

Questions

What teams ask before they paste the tag in

Still have questions?

Send us the page you would put it on. We will show you what the agent can and cannot touch there.

Book a demo Talk to sales

It is a chat panel you add to your own website so visitors can get answers without calling or waiting on an inbox. The Zumu one is worth distinguishing from the category on two counts: it is driven by the same agent and the same knowledge base that answer your phone line, and it can act on the page the visitor is already looking at, with the visitor approving each action.

Book a demo

Put it on a staging page and try to break it

We will point the crawler at your own site, hand you the script tag, and you can watch the agent ask before it touches a single field. Bring your worst stylesheet while you are at it.

Book a demo Talk to sales

No credit card for the demo
Your own site is the first knowledge base