AddThisFeature

Live Chat Widget

Let visitors ask a question from any page and get a real answer from your team.

involved Engagement

What it adds

A corner chat bubble that opens a persistent conversation between a visitor and staffed agents, with an agent-side inbox.

What your agent is told to do

5
  1. 1

    Build the visitor side first: a bubble, a transcript, a composer, and a clear statement of whether anyone is currently available. An agent inbox that reuses the app's existing list and detail patterns is enough for version one; do not build a full helpdesk with routing rules, tags, and SLAs before a single conversation has happened.

  2. 2

    Keep the conversation attached to the visitor, not the page. Store a conversation identifier that survives navigation, reload, and moving between pages, and reattach the transcript when the widget reopens.

  3. 3

    If the app already has Knowledge Base Chat or an AI Chat Assistant, put them in the same widget rather than adding a second bubble. Answer from the knowledge base first and hand off to a human when the visitor asks or the answer is not found.

  4. 4

    Reuse the app's existing Rate Limiting and Notification Center rather than inventing per-widget throttles and a parallel alert channel. Anonymous visitors need a stricter limit than signed-in users.

  5. 5

    Do not open the socket on every page load for every visitor. Load the bubble, and only connect when the visitor opens it, so an idle marketing page does not hold a live connection.

Edge cases it handles

8
  • The socket will drop on flaky mobile connections. Queue messages typed while it is down, show them as pending, and replay them in order once it reconnects rather than dropping them or reordering them.
  • Outside staffed hours the widget must say so honestly and set an expectation for a reply, plus collect an email address. A widget that looks live at 3am and never answers is worse than no widget.
  • A double-click on send, or an automatic retry after a timeout, must not post the message twice. Give each outgoing message a client-side identifier the server treats as idempotent.
  • The conversation must survive a page navigation and a full reload. A visitor who clicks a link mid-question and loses the transcript will not start again.
  • Anonymous visitors are the spam surface. Rate-limit by session and by address, cap message length and frequency, and make a flood cheap to shut off without taking the widget down for everyone.
  • A visitor who starts anonymously and then signs in must have the conversation merged onto their account, not left orphaned under a session identifier.
  • The widget must be reachable and dismissible by keyboard, and must not cover a page's primary action or a cookie banner on a small screen.
  • Transcripts contain whatever a visitor types, including card numbers and passwords. Decide retention, restrict who can read a transcript back, and support deleting one on request.

Definition of done

9
  • A visitor can open the widget, send a message, and see a reply without leaving the page they are on.
  • The conversation persists across navigation, reload, and a return visit in the same browser.
  • Messages sent while disconnected are queued and delivered in order once the connection returns.
  • Duplicate sends from double-clicks or retries are rejected server-side.
  • Away hours are stated explicitly and the widget collects an email address when nobody is available.
  • Anonymous visitors are rate-limited and a flood can be stopped without disabling the widget entirely.
  • The widget is fully operable by keyboard and never obscures the page's primary action.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.