Glozr docs
/

Embed the widget

Widget features

The Glozr widget is more than a chat box. It persists conversations, accepts voice input, captures leads, surfaces citations, and supports a real-time human handoff — all from the same Shadow-DOM bundle.

Conversation persistence

On first contact, each visitor gets a unique anon_id stored in localStorage. When they return within 24 hours, the widget rehydrates the prior thread — the init response ships the last 30 messages so the chat reopens exactly where it stopped.

A Clear conversation control writes a timestamp without erasing history; the messages stay available for analytics and lead tracking, the visitor just sees a fresh thread.

Voice input

A microphone button lets visitors dictate messages using the browser's native SpeechRecognition API. While recording, an animated sonar ring signals the active state; clicking again ends the capture and inserts the transcript. Browsers without SpeechRecognition support — Firefox, older Safari — simply don't render the button.

Lead capture

The widget collects contact info through several triggers:

  • A behavior rule fires whose kind is lead_capture.
  • The visitor expresses contact intent ("call me", "email me a quote").
  • A custom CTA button configured with the lead_capture action is clicked.

Default fields are name and email; phone, company, and custom parameters can be added per agent. Captured leads POST to /v1/widget/leads and surface in the workspace inbox in real time.

Intent-based capture

The agent can also surface the lead form proactively when the conversation looks sales-shaped — pricing questions, demo requests, scoping questions — without waiting for a hard-coded keyword.

Human takeover

When a teammate claims the conversation from the inbox, the widget swaps the agent badge for a Human is here indicator. The AI pauses; visitor messages route to the operator, and operator replies stream back as part of the same thread.

Citations

Source references appear as numbered chips beneath agent replies. Visitors can click through to verify the answer against the underlying document — useful for trust and for spotting outdated sources you should refresh.

Streaming and retries

Replies stream token-by-token over Server-Sent Events. On transient failures the widget retries up to three times before surfacing an error, so brief network blips don't kill an in-flight message.

Branding and storage

The default footer reads Powered by Glozr; eligible plans can hide it via the remove_branding feature flag. Client-side storage is intentionally minimal — only anon_id and the conversation clear-state live in localStorage. No personally identifiable information is kept on the visitor's machine.

Stage-aware typing indicator

While a reply is being prepared the widget shows what's actually happening instead of a generic …. The stream carries a stage hint that drives the pending bubble through two labels: Searching your site… while retrieval runs, then Thinking… while the model composes. The moment the first token arrives the stage clears and the answer streams in token-by-token.

No configuration — the staging is automatic on every turn. If the stage hint is missing (older bundle, or a turn that skips retrieval) the bubble falls back to a plain thinking… placeholder.

Suggested follow-ups

Every answer can end with up to three tappable follow-up prompts, generated automatically from the visitor's last message and the answer itself — no setup, no curation. The model appends them in a fixed marker, <suggestions q1="…" q2="…" q3="…"/>, which the widget renders as pill-shaped chips. Tapping a chip re-sends its text as the visitor's next message.

Chips only render under the most recent assistant reply and disappear once the visitor sends their next message. The model omits q2/q3 when it only has one or two worthwhile follow-ups, and omits the whole block when the conversation is clearly closing (for example the visitor said goodbye). Suggestions over 120 characters are dropped client-side. The net effect: visitors who don't know what else to ask are handed a sensible next step instead of dropping off.

Unread badge & chime

If the agent (or a human operator) replies while the bar is minimised, the closed bar shows a red unread badge — 1, 2, up to 9+ beyond nine — and plays a soft one-time chime. The counter increments on any non-visitor message received while closed and resets to zero the instant the visitor reopens the bar.

The chime is a short synthetic two-tone ding built with the Web Audio API (no audio file is bundled, keeping the widget inside its size budget). It fires at most once per session, on the first unread message only; later unreads still bump the badge but stay silent so the visitor isn't nagged. It respects the OS reduce motion setting (prefers-reduced-motion: reduce suppresses the sound entirely) and silently no-ops on browsers without an AudioContext.

Lead-form trigger strategy

Each agent carries a lead_prompt_strategy setting that controls when the lead-capture form is offered. The decision runs server-side against the visitor's own message (not the assistant's reply) as a fast heuristic after the stream completes, and never re-prompts once a lead has been captured for that conversation. Four strategies are available:

  • Engagement (engagement, the default) — surfaces the form when the visitor's message carries a high-intent signal (pricing, demo, "talk to sales", "email me", and similar), or as a fallback once the visitor has sent at least three turns without giving their details. Prompts once, then waits out a cooldown of five further turns before it may ask again.
  • First message (first_turn) — shows the form on the very first visitor message, regardless of keyword or engagement. Suited to sales-led agents where every visitor is a lead.
  • Keyword only (keyword_only) — offers the form only when a high-intent keyword appears, with no engagement fallback. No surprise prompts after a few turns of ordinary chat.
  • Never (never) — never surfaces the form; visitors can chat without any lead capture.