Web chat
The chat widget your visitors open on your own site: what to configure, how to install it, and what a conversation becomes.
Web chat is the messenger a visitor opens on your website. It is configured at Channels, Web chat, and what a visitor sends arrives in your inbox as an ordinary ticket.
There is no provider to connect and no credential to hold. Web chat is a first-party surface, so the workspace has it from the start; connecting Aura AI is a layer on top rather than a prerequisite. A workspace with no AI still has a working widget, and a visitor who opens it reaches a person.
Editing the configuration needs admin. Everyone else sees the settings and no save control.
The five tabs
A live preview of the real widget sits beside the settings, so each change is visible as you make it rather than after a reload.
| Tab | What it decides |
|---|---|
| Content | Which modules appear and in what order, the agent name, greeting, introduction, languages, and when the launcher is visible. |
| Styling | Theme, primary and background colour, logo, avatar, header text, and the launcher's position and spacing. |
| Conversations | Conversation starters, the suggested prompts a visitor can click, and the reply tone. |
| General | The remaining widget-level settings. |
| Install | The embed code, and the agent that answers in the widget. |
Conversation starters repay the time they take. A visitor offered "Where is my order?" clicks it, and you get a well-formed question instead of "hi".
Installing it
The Install tab prints the snippet in three forms: a plain script tag, a React and Next.js snippet, and instructions for WordPress. There is no npm package. The widget ships as a hosted bundle, so every form loads the same script from the address your deployment serves it on.
Give the snippet to whoever manages your website. It belongs on every page the launcher should appear on, which for most sites means the shared template rather than individual pages.
The same tab carries the agent picker. A public embed cannot name a workspace, so the agent is the routing key: it is what the widget's branding fetch and its escalation to a person are resolved against. If your workspace has exactly one agent it is used without you choosing; otherwise pick one here.
Three addresses have to be right
The snippet names the widget bundle, the chat service that answers, and the runtime the widget calls for branding and for the handoff to a person. Those are deployment settings, not workspace settings, and the Install tab reports each one and who sets it. A snippet missing the runtime address produces a widget that answers but cannot pass anyone to a person.
What a conversation becomes
Both of the widget's doors open tickets with the channel Web chat.
- The contact-form embed creates a ticket directly.
- A live conversation that reaches a human, because the visitor asked or because an AI agent routed it there, creates a ticket with a live session attached.
The reason the conversation reached a person is recorded on the ticket separately, as its handoff reason. It is not a channel of its own: an earlier version of the product recorded live chats under a source called AI handoff, which meant web chat could not say a conversation had arrived over the widget at all. Both doors now report the channel honestly, and the reason sits beside it.
Replies work. A public reply on a ticket with an open live session is delivered to the visitor in the widget while they are still on the page. When the visitor has closed the conversation, or the ticket came from the contact-form embed, there is no open session to deliver into and the product says so rather than pretending the message went.