Widget and Portal

The Widget and public Portal are Managani's customer-facing surfaces. Configure them per site under Settings > Website, Portal, Theme, and White-Label when available.

Widget

One script can deliver:

• Customer chat and lead capture
• Feedback, voting, comments, and customer history
• Roadmap and changelog
• Knowledge search and the Widget Assistant
• Surveys, tours, and highlights
• Web messages and product tracking

Install from Settings > Website > Experiences > Edit > Embed. Copy the code for the Experience you want to show; it contains the Experience ID. Anonymous chat and Web messages work without JWT or backend integration on any technology stack. Add signed identity only when needed.

Create separate deployments when products or environments need different allowed domains, visible tabs, launcher behavior, or wording. The public site key is safe in browser code.

Anonymous visitors can open public content, chat, and receive Web Messages. Feedback submission, voting and comments, customer history, personalized targeting, surveys, tours, highlights, and customer-linked tracking require a server-signed user token. Never expose the site secret in browser code.

The complete installation and signed-user examples are in Sites.

Public Portal

The portal publishes approved feedback, roadmap lists, and changelog releases. Visitors can add one browser-scoped emoji reaction per item without signing in. Signed customers can also vote and comment, while changelog email subscriptions remain open to everyone.

Customize navigation wording, empty states, forms, colors, typography, spacing, themes, logo, and favicon. Cloud plans with White-Label access can use a custom hostname for both the portal and script.

Knowledge

Public URLs, Roadmap, and Changelog can power widget search and the assistant. Private Streamient sources can ground admin AI and automation, while customer-tagged records remain limited to the matching customer. Review source visibility before enabling AI responses.

Live visitor drafts

Once a visitor has sent their first message, the team can see an Unsent draft preview in Web, Desktop, and mobile chat. The text updates while the visitor types and remains visible during pauses. Sending successfully, emptying the composer, or disconnecting clears that tab's draft. Separate visitor tabs keep independent drafts. Agent drafts are never shared.

Drafts are transient socket state, not conversation messages. They do not appear in transcripts, notifications, AI processing, or application logs.

The widget sends optional draft text through widget:typing, limited to 6,000 characters and throttled to one update per 200 ms. Authenticated team viewers receive chat:draft with conversationId, site, stream, version, and text. An empty text clears that stream. Clients ignore duplicate or older versions, including late snapshots. Opening a conversation through chat:viewing replays its current connected visitor drafts. Existing boolean-only typing clients remain compatible; visitor-facing typing events contain no draft text.

Minimize or end a chat

The chat window header provides Expand, Minimize, and Close, in that order. Minimize hides the window and keeps the conversation and draft. Close asks the visitor to confirm ending the chat and optionally email a transcript to the email address already saved on the chat. No email address is requested from visitors who do not want a transcript.

Ending a chat updates the team view immediately with Visitor ended chat. Agents must explicitly reopen it before replying. An ordinary connection loss instead shows Visitor offline; it does not end the conversation. Another connected visitor tab keeps the visitor online.

Reading or replying to a chat marks that conversation's bell notifications read for the current team member. Other conversations and teammates' unread notifications are unchanged. Clicking a chat notification marks the same chat's notifications read together.

Team availability and AI takeover

With Chat AI enabled and configured, a customer message shows checking for a team member to join... while Managani routes the conversation. The default human response window is 40 seconds. If nobody is connected, or every connected team member is on Do not disturb, AI starts without waiting. Connected Desktop sessions count even behind other windows or in the tray; multiple devices count as one team member.

Assignment does not block takeover by default. A sent human reply cancels the current wait; viewing, typing, and assignment do not. Additional customer messages keep the original deadline. Once AI is responding, it continues immediately until a human replies. The next customer message then starts a fresh availability check. Closing the chat always prevents AI replies.

The response window and immediate offline/DND takeover switches are in Automation → Chat AI, along with the switch allowing takeover in assigned chats. Existing AI activation requirements and disable switches still apply. Personal Do not disturb also suppresses the in-app chat popup.

For upgrades, preview the idempotent migration with node scripts/migrations/chat-ai-availability.mjs, then run it with --apply. It changes old 60-second settings to 40, preserves other custom waits and explicit switches, and adjusts pending deadlines using their original messages and job IDs. It also replaces only the old stock chat subheading with How can we help?.

Widget responses include routing; the chat:routing socket event carries the same safe status, reason, deadline, source message, and update timestamp. Status values are checking, ai_replying, waiting, idle, and failed. These are transient UI notices, not transcript messages.