Design a customer support chat widget

Requirements: a chat that lives on someone else's site

A support chat widget is a small chat window that a support company ships to its customers. A customer, say a shoe shop, pastes a script tag into its site. A round launcher button appears in the corner; clicking it opens a messenger panel with a greeting, a bot for common questions, and a way to reach a human agent. Intercom Messenger, Zendesk Messaging, Drift, Crisp, HubSpot chat, Freshchat and Tawk.to all look like this.

The host site is the customer's website. The visitor is a person browsing it. The agent answers from a dashboard on our own site. We design the part the visitor sees.

Questions to ask first

Functional requirements

• A launcher button on every page the customer chooses, with an unread badge.
• A messenger panel: start a conversation, see past conversations, send text and files.
• A bot answers first (FAQ search or an AI assistant), and the visitor can ask for a human.
• Hand-off to a human with queue position or expected wait; outside office hours, an offline form that collects an email.
• Anonymous visitors, and signed-in users of the host site identified in a way that can't be faked.
• The open conversation survives page navigation and is the same in every tab.
• Proactive messages ("Need help choosing a size?") based on rules the customer sets, with frequency caps.
• Notifications when an agent replies and the messenger is closed or the tab is hidden.

Non-functional requirements

• Do no harm to the host page: the launcher adds under about 15 KB of compressed JavaScript (our budget, not an industry number), causes no layout shift, and never blocks the main thread long enough to hurt INP (Interaction to Next Paint: how quickly the page responds to a tap; good is at most 200 ms).
• Open fast: the messenger is usable within about 1 second of clicking the launcher on a typical 4G phone, and within about 300 ms when restored after a page navigation.
• Safe identity: one visitor can never read another visitor's conversation by guessing or changing an id.
• Accessible: keyboard and screen reader users can open, use and close it; new messages are announced without flooding.
• Private: respects the host's consent banner, masks card numbers, and deletes transcripts after the customer's retention period.

Out of scope

• The agent dashboard, routing and SLAs (see the support dashboard guide).
• How the bot's answers are generated. We treat the bot as a server that replies with messages; streaming AI answers are covered in the LLM chat UI guide.
• Voice and video calls, co-browsing, and in-app chat in native mobile SDKs.

What makes a support widget hard

A support widget looks like a small chat app in a box. The box is the problem: four things make it different from a chat app on our own site.

• It's a guest. It runs on pages we don't own. The host's Core Web Vitals, consent banner, sticky footer and routing are rules we must live with, and if the widget makes the shop slower, the shop removes it.
• Almost nobody uses it, but everybody loads it. With 1 to 3 percent of page views opening the chat, the code that runs on every page must be tiny.
• It doesn't control its own lifetime. On a multi-page shop, every click destroys the widget and builds a new one, and three tabs hold three copies of it. The conversation must still feel like one continuous thing.
• It speaks for strangers. The host site knows who the visitor is; we don't. We must accept identity from the host without letting anyone pretend to be another customer, and forget it when they sign out.

On top of that, a support conversation has more states than a chat between friends: bot, queue, human, closed office, resolved, reopened. The widget must show the right one after any reload.

The wireframe shows the parts we will design. The launcher is a round button, about 60 pixels across, fixed to a corner with an unread badge; above it, a proactive message bubble appears when a rule fires. Clicking opens the messenger: a header with the team's status ("Usually replies in 5 minutes" or "We're away"), the conversation, and a composer. On a phone it fills the screen.

Which guide covers what

The launcher: load almost nothing until someone asks

The naive install is one script tag that loads the whole messenger on every page: the UI framework, the conversation list, the composer, emoji, file upload, the socket client and translations. A real messenger bundle is easily 150 to 250 KB of compressed JavaScript (an estimate for a full-featured widget). On a mid-range phone, parsing and running that much code takes hundreds of milliseconds of main-thread time, right when the shop's own page is trying to become interactive.

Multiply it out. A shop with 2 million page views a day and a 2 percent open rate loads the full messenger 2 million times so that 40,000 visitors can use it, and the host's Core Web Vitals pay. For years Lighthouse had a "Lazy load third-party resources with facades" audit that named live chat products such as Intercom and Drift. Lighthouse 13 removed it in 2025, but a facade (a light placeholder that looks like the real widget and loads it on interaction) is still the standard answer.

The budget, in KB and milliseconds

One fact makes these budgets matter more. Browsers now partition the HTTP cache by top-level site, so our bundle cached on shop A is not reused on shop B. Every customer's site pays for its own first download.

Loading on intent

Intent means a signal that comes before the click. The embeddable widget guide covers the general recipe: preconnect to our origins on hover or focus, start the download on press, and paint feedback in the click handler before doing any work. A support widget has three extra signals that justify loading the messenger before any click.

• The panel was open on the last page. The loader's chat:open flag says so, and the visitor expects it back at once (the navigation chapter).
• A human is involved. If the boot call says the conversation is waiting for or talking to an agent, load at idle: a reply is coming.
• A proactive message fired. A visitor who sees "Need help with sizing?" is far more likely to open the chat than one who sees only the button.

Not hurting the host's Core Web Vitals

Customers judge us by their Core Web Vitals. A fixed launcher causes no layout shift (CLS), and an async loader that starts after the host's critical resources leaves the largest paint (LCP) alone; the embeddable widget guide shows both. INP is where a support widget is most at risk, because its boot code runs on every page view of every visitor.

So the launcher boots in small tasks at idle, never one 200 ms block, and a tap on "Add to cart" during boot waits for one small task at most. The messenger is not exempt just because it lives in an iframe. On many phones a cross-origin iframe runs on the host page's main thread, so its long tasks still delay the host's taps.

Who is the visitor?

Every conversation belongs to someone. For a first-time visitor we create an anonymous visitor: a random id stored in the browser and sent with every request, so tomorrow's visit brings back today's conversation. When a signed-in user of the host site opens the chat, we attach the conversation to their account, so the agent sees their name, plan and past tickets.

Both halves have a trap. The anonymous id has to live somewhere the browser will keep, and browsers now partition third-party storage. The signed-in identity comes from the host page, and anything the host page says can be changed by the person sitting at the keyboard.

Where the anonymous id lives

Chrome, Firefox and Safari all partition a third-party iframe's storage: it is keyed by our origin plus the top-level site of the page (scheme plus registrable domain, such as https://shoeshop.com). So www.shoeshop.com and help.shoeshop.com share one partition, but shoeshop.co.uk gets a different one. A visitor who crosses domains becomes a second anonymous contact until they sign in. Two customers' sites never share storage, which is fine: a visitor of two shops is two different contacts anyway.

Identifying a signed-in user without impersonation

The naive API is Chat('boot', { userId: '42' }). It's a security hole: anyone can open DevTools on the shop, boot with userId: '43', and read user 43's support history, with addresses and order numbers. The page is not a trusted source. Only the host's server knows who is really signed in.

So the host's server signs the identity with a secret it shares with us, and we verify the signature. Intercom's original identity verification sent a user_hash: an HMAC-SHA256 (a keyed hash) of the user id with the shared secret. Intercom now marks that method deprecated and recommends a signed JWT instead (a JSON Web Token: a small JSON payload plus a signature), passed in the Messenger settings as intercom_user_jwt.

Zendesk's messaging Web Widget, which replaces the older Web Widget Classic, works the same way through zE('messenger', 'loginUser', jwtCallback). It honours the JWT's exp (expiry) claim and calls the callback again for a fresh token whenever a request is rejected with a 401.

import { SignJWT } from "jose";

const secret = new TextEncoder().encode(process.env.CHAT_IDENTITY_SECRET);

export async function chatIdentityToken(user: { id: string; email: string; name: string }) {
  return new SignJWT({ email: user.email, name: user.name })
    .setProtectedHeader({ alg: "HS256" })
    .setSubject(user.id)
    .setIssuedAt()
    .setExpirationTime("10m")
    .sign(secret);
}

An HMAC of the user id never expires: if it leaks once, in a log or a shared HAR file, it works forever. A JWT with a short exp limits the damage, and its extra claims (email, plan) are signed too, so a visitor can't edit them. The cost: the host must hand us fresh tokens, so our API takes a callback rather than a fixed string.

Merging the anonymous conversation

A common story: a visitor asks a pre-sales question anonymously, then signs up and signs in. The agent should see one person with one history, so when an identified boot arrives with an anonymous id attached, the server moves that anonymous contact's conversations onto the user.

Three rules keep this safe. Merge only an anonymous contact that has never been merged into anyone. Never merge one identified user into another, and never merge the other way, from a user into an anonymous contact.

Logout on the host must clear the widget

On a shared computer, the next person must not see the last person's conversations. The host calls Chat('logout') in its sign-out flow, and the widget drops the session token, wipes cached messages and drafts, closes the socket, deletes its cookies and creates a fresh anonymous id. Intercom's docs warn that without shutdown, the last user's conversations stay in the Messenger for a week, and that a leftover anonymous cookie can merge the last user's history into the next person who signs in.

Hosts forget to call logout, so we add a second line of defence: identity is declared on every boot. If the stored session belongs to user 42 but this page boots with no user, or with user 57, the widget treats it as a logout before showing anything. And the merge rule above means a stale anonymous id that once belonged to user 42 can't be merged into user 57.

Surviving the host site's navigation

On a classic multi-page shop, every click on a product loads a new document. The old page, with our launcher, our iframe, our socket and our React state, is thrown away. The new page runs our snippet from scratch. If we do nothing, the visitor who had the chat open with a half-typed message finds it closed, empty and scrolled to the top on the next page, a problem the frontend alone has to solve.

The naive fix makes it worse in another way: restore by reconnecting. Every page boots the messenger, opens a WebSocket, authenticates and subscribes. A visitor who clicks through 10 product pages in a minute opens and closes 10 sockets, each with a TLS handshake and an auth check, and on the agent's screen the visitor flickers online, offline, online. At our scale that is a reconnect storm: millions of short-lived sockets an hour doing nothing useful.

What to restore, and from where

The restore order is what makes it feel instant. The loader reads chat:open from sessionStorage before anything else; if it's true, it skips the idle wait and loads the messenger iframe at once with high fetch priority. The iframe paints the cached messages, the draft and the scroll position from storage within a frame or two of its script running, before any network call.

Only then does it ask the server for messages after the last sequence number it has, and append them. The visitor sees the same panel they left about 200 to 400 ms after the new page starts (our target, with the messenger's files in the HTTP cache).

Leaving the page cleanly

When the visitor leaves a page, we save state and close the socket in a pagehide listener, never unload. pagehide fires reliably on mobile, where unload often doesn't, and an unload listener can keep the whole host page out of the back/forward cache (bfcache), which makes the back button instant. Some browsers also refuse to cache a page with an open WebSocket, so closing ours keeps the shop eligible everywhere. On pageshow with event.persisted true, the page came back from the cache, so we reconnect and catch up.

Single-page host sites

In a single-page app the document never reloads, so the widget and its socket stay alive. The work flips: we must notice URL changes, because page rules (show the launcher only on /pricing) depend on them. The host calls Chat('update') from its router, and as a fallback we listen to popstate and, where supported, the Navigation API's navigate event. Rate-limit it: Intercom throttles update after 20 calls in 30 minutes.

One visitor, many tabs of the shop

Shoppers open products in new tabs to compare them. With three tabs, each with its own messenger iframe and socket, an agent's reply rings three times, reading it in one tab leaves a red badge in the other two, and logging out in one tab leaves the old conversation visible in the others.

Partitioning helps here. Our three iframes share an origin and a top-level site, so they share one partition, and BroadcastChannel, SharedWorker and Web Locks are partitioned the same way. The iframes can talk to each other, while the shop's scripts, and our own iframes on other customers' sites, can't listen in.

The chat app guide designs the rest: one leader tab holds a Web Lock, owns the socket and relays events to the others on a BroadcastChannel, and only the leader shows notifications. The multi-tab sync guide covers election and failover in depth. A SharedWorker that owns the socket is the cleaner option, but Chrome on Android only shipped it in version 148 (2026) and Samsung Internet still lacks it, so a fallback is needed either way.

Two things are different for a support widget. Sockets are already rare, because we connect only while someone waits for a human, so one socket per tab is an acceptable fallback. And the channel and lock names include the app and the visitor (chat:app_123:v_9f2c), so a logout event reaches every tab of this visitor and never leaks into the next visitor's session.

Unread counts that agree

The unread count belongs to the server: an agent's message is unread until the visitor sees it, in any tab or on any device. When the visitor reads a message in tab A, tab A tells the server (POST /read with the last seen sequence number) and broadcasts read on the channel, so tabs B and C clear their badges at once.

A tab that has only the stage-1 launcher, and so no iframe and no channel, refetches the count on visibilitychange instead. That sounds lazy, but it's exactly right: nobody can see the badge in a hidden tab, so it only has to be correct when the tab becomes visible.

The lab below puts this chapter and the last together. Pick a strategy and how many tabs the visitor has open, then click through pages. Watch the number of sockets opened, how long the panel takes to come back, and whether the badges agree after the visitor reads a reply in one tab.

Bot first, then a human

Most support questions repeat: where is my order, how do I reset my password. So the visitor first talks to an automated assistant, a help-centre search or an AI agent. When it can't help, a human takes over, unless it's 11 pm in the team's time zone. The widget must make each situation obvious and survive a reload in any of them.

The naive model is a boolean, isBot, plus a list of messages. It can't say whether the visitor is waiting for a human or still with the bot, whether a closed conversation should keep its composer, or whether a reply tomorrow reopens it. Each of these needs an explicit state, so we model the conversation as a state machine: a fixed set of states and the events that move between them.

The server owns the state. The widget never decides that a conversation is with_agent; it receives a conversation.state event and renders it. This matters for reloads (the boot call returns the current state, so any page restores the right screen) and for tabs (all tabs get the same event). The widget only adds local states on top, such as sending for the moment between pressing "Talk to a person" and the server's answer.

Queue position and expected wait

Once the visitor asks for a person, waiting is the whole experience. The server sends queue.update events with a position and an estimate, and two details make this calm instead of stressful. Show the estimate as a rounded range ("usually under 5 minutes") rather than a ticking countdown that will be wrong. And update the visible text at most every 30 seconds, because a number that jumps from 3 to 4 when a VIP is routed ahead feels worse than no number.

While waiting, the connection stays open even if the visitor closes the panel, so the badge and a notification can fire when the agent answers.

Office hours and the offline form

Office hours are a server decision. The boot call returns availability: { online: false, nextOpenAt: '2026-10-23T09:00:00+01:00' }, and the widget formats it in the visitor's own time zone with Intl.DateTimeFormat. Never compute "are we open?" from the visitor's clock: it can be wrong, and the team's holidays live on the server.

When offline, the composer turns into a short form. If the visitor is identified we already have their email; if anonymous, we ask for one, because the reply will arrive after they've left the site. The reply then shows up in two places: by email, and in the widget on their next visit.

type ServerState =
  | { kind: "bot" }
  | { kind: "waiting"; position: number; etaBucket: "under_2m" | "under_5m" | "under_15m" | "long" }
  | { kind: "with_agent"; agent: { name: string; avatarUrl: string } }
  | { kind: "offline"; nextOpenAt: string }
  | { kind: "awaiting_reply"; email: string }
  | { kind: "resolved"; rated: boolean };

type LocalOverlay = { requestingHuman: boolean; formError?: string };

function composerMode(s: ServerState): "chat" | "offline_form" {
  return s.kind === "offline" ? "offline_form" : "chat";
}

Getting attention without being annoying

An agent replies after four minutes. By then the visitor has closed the panel or switched tabs, and if they never see the reply, the team's work is wasted. But a widget that beeps, flashes the title and pops up "Can I help you?" on every page gets uninstalled. So we need rules: which signal, when, and how often.

The rule of thumb: the stronger the signal, the more the visitor must have asked for it. A badge is always fine, and a change to the tab title is fine while a human is actually answering. A system notification needs explicit permission and a reason, and sound needs the visitor to turn it on.

Browser notifications from an embedded widget

Two platform rules shape this. Browsers expect a permission request to follow a user gesture, such as a click, and Chrome and Firefox no longer let a cross-origin iframe request notification permission at all (MDN documents both). Our messenger lives in a cross-origin iframe, so it can't ask.

If a customer turns system notifications on, the loader asks on the host's behalf, so the permission belongs to the shop's origin. It asks only after the visitor taps a visible "Notify me when they reply" button, and only while the conversation is waiting or with_agent. Because the notification is shown from the host page, it says only "New reply from support": the text stays in our iframe. It fires only when the tab is hidden or the panel is closed.

With several tabs, only the leader tab's loader shows it, with the conversation id as its tag so a newer one replaces the older. The notifications center guide covers permission UX and service-worker push; a support widget rarely needs push, because email follows up once the visitor has left.

Proactive messages

Proactive messages are the customer's tool for starting a conversation: "Questions about sizing? We reply in minutes" after 30 seconds on a product page, or "Need help with your plan?" on /pricing. The rules come in the boot response and are evaluated by the stage-1 launcher, so we don't load the messenger just to check a timer. When a rule fires, the launcher shows a small bubble and starts loading the messenger, one of the early signals from the launcher chapter.

• Frequency caps (our defaults): at most one proactive message per session and three per week per visitor, stored with the visitor id. Customers can lower them, not raise them past a hard ceiling.
• Dismissal is a decision: if the visitor closes a proactive bubble, no proactive message for 7 days on that site. Ignoring it for 10 seconds hides it without counting as a dismissal.
• Never interrupt work: don't fire while a form field on the host page has focus, while the visitor is in a conversation, or on pages the customer marks as sensitive, such as the payment step.
• Mobile restraint: on small screens a bubble covers content, so show only a badge-sized nudge and never auto-open the sheet.

function mayShowProactive(rule: Rule, ctx: VisitorContext, now: number): boolean {
  if (ctx.conversationState !== "none" && ctx.conversationState !== "resolved") return false;
  if (ctx.messengerOpen || ctx.hostFieldFocused) return false;
  if (ctx.sensitivePage) return false;
  if (now - ctx.lastDismissedAt < 7 * DAY) return false;
  if (ctx.shownThisSession >= 1) return false;
  if (ctx.shownTimestamps.filter((t) => now - t < 7 * DAY).length >= 3) return false;
  return matchesUrl(rule.urlPattern, location.href) && ctx.secondsOnPage >= rule.afterSeconds;
}

The lab below follows one conversation from the bot through the queue to an agent, and the offline path when the office is closed. Open and minimise the panel, hide the tab, and watch which signals fire: badge, preview, title prefix, notification. Notice how the same agent reply produces different signals depending on where the visitor's attention is.

Phones, settings, privacy and accessibility

On a phone, a 380 by 600 pixel panel floating over the page doesn't fit. The messenger becomes a full-screen sheet: the iframe grows to cover the viewport, and the host page behind it stops scrolling. Four mobile problems follow, each with a specific fix.

• The on-screen keyboard. When the composer gets focus, the keyboard covers the bottom of the screen. Only the top-level page's visualViewport reports the visible area (inside an iframe it just mirrors the frame's own size), so the loader listens to its resize event and sets the iframe's height to visualViewport.height. Without this, iOS often hides the composer under the keyboard or scrolls the whole host page.
• The back button. On Android, people press back to close things. When the sheet opens, the loader pushes one history entry, and popstate closes the sheet instead of leaving the shop. Closing with the sheet's own button calls history.back() to remove that entry, and the entry carries a marker in history.state so a single-page host's router ignores it.
• Safe areas. On phones with a notch or a home indicator, the loader's wrapper around the iframe adds env(safe-area-inset-top) and env(safe-area-inset-bottom) padding. This works only if the host's viewport meta tag has viewport-fit=cover; otherwise the insets are zero and nothing breaks.
• The host's own sticky UI. Shops have sticky "Add to cart" bars at the bottom. The customer sets a vertical offset per page pattern in the dashboard (for example 72 px on /products/*), and the JavaScript API lets the host move or hide the launcher while its own bottom sheet is open.

Configuration from the dashboard

Customers change the widget without redeploying their site: colours, launcher position and offset, greeting, office hours, which pages show the launcher, and proactive rules. All of it arrives with the launcher's boot call, cached at our edge for about a minute per app id, so a change shows up within about a minute. Page rules run in the loader before anything is drawn, so a page without the launcher costs one small request and no launcher code.

Customers with a strict Content Security Policy must allow our script, frame, API and wss: socket origins, or the widget fails silently. The embeddable widget guide lists the directives and shows how the loader reports a blocked request, so support can tell the customer which line to add.

Privacy: consent, card numbers and retention

A support chat collects what frustrated people type: order numbers, addresses, sometimes a full card number. It also stores an identifier in the browser. Both make privacy part of the design.

• Consent first. Because the loader sets a visitor id cookie, many customers in the EU must not run it before consent. In consent: 'wait' mode the loader draws nothing, sets nothing and loads nothing until the host's consent banner calls Chat('consent', { functional: true }); the cookie consent guide covers the banner side.
• Mask card numbers before they leave the browser. The composer looks for runs of 13 to 19 digits (with spaces or dashes) that pass the Luhn checksum, replaces all but the last four, and tells the visitor why. The server runs the same redaction again, because a modified client can skip ours.
• Retention. Each customer sets how long transcripts are kept. The browser keeps only the last 50 messages of the open conversation, deletes the cache when a conversation has been resolved for 30 days, and wipes everything on logout.

Accessibility specific to a support chat

The embeddable widget guide explains why a floating chat panel is a non-modal dialog on desktop: the visitor may copy an order number from the page while chatting, so there is no focus trap, and Escape returns focus to the launcher. The phone sheet covers everything, so it is modal in practice. There the loader opens the sheet's wrapper as a dialog with showModal(), which makes the rest of the host page inert without touching the host's DOM.

• The launcher's name carries the count. It is a button with aria-expanded and an accessible name such as "Open support chat, 2 unread messages". The badge itself is aria-hidden, so the number isn't read twice.
• Restoring is silent. The message list is not a live region, because restoring 50 cached messages after every navigation would read them all aloud. A separate polite live region announces only messages that arrive after boot, batched as the chat app guide describes.
• Quiet status changes. Queue updates change the visible text but are announced only when the state changes ("An agent has joined: Sam"), not every time the position moves.

Architecture, data and API

Putting the chapters together gives three layers that live in different places for different reasons. The loader and launcher run in the host page, because they must be tiny, must exist on every page, and need the host's first-party cookie and URL. The messenger runs in our cross-origin iframe, because it handles private conversation data that the host's scripts must not read. Our servers own identity, conversation state, availability and rules, because nothing in the browser can be trusted with them.

The boundary between launcher and messenger is the postMessage bridge described in the embeddable widget guide. Only a handful of messages cross it: open, close, unread (a number), resize (for the sheet), notify (show the generic notification) and logout. Message text never crosses into the host page, which is why the reply preview bubble is drawn by a tiny second iframe of ours rather than by the launcher. That's a deliberate privacy line: the host page can know that there is an unread message, never what it says.

type Visitor = { visitorId: string; userId?: string; email?: string; identified: boolean };

type Conversation = {
  id: string;
  state: ServerState;          // from the hand-off chapter
  lastSeq: number;             // highest message sequence we have
  lastReadSeq: number;         // highest sequence the visitor has seen
  unread: number;              // derived on the server, cached here
};

type CachedMessage = { seq: number; author: "visitor" | "bot" | "agent" | "system"; text: string; at: string };

type TabUiState = { open: boolean; screen: "home" | "conversation" | "offline_form"; scrollTop?: number };
type Draft = { conversationId: string; text: string; updatedAt: number };

GET /v1/apps/app_123/launcher?v=v_9f2c...&url=/p/42      (launcher, every page)
200 OK  Cache-Control: private, max-age=10
{ "config": { "color": "#0B6", "position": "right", "offsetY": 72 },
  "availability": { "online": false, "nextOpenAt": "2026-10-23T09:00:00+01:00" },
  "conversation": { "state": "awaiting_reply", "unread": 1 },
  "rules": [{ "id": "r_size", "urlPattern": "/p/*", "afterSeconds": 30 }] }

POST /v1/apps/app_123/session                              (messenger iframe)
{ "visitorId": "v_9f2c...", "identity": "eyJhbGciOiJIUzI1NiJ9...", "sinceSeq": 118 }
200 OK
{ "token": "st_...", "expiresIn": 900,
  "conversation": { "id": "c_77", "state": { "kind": "awaiting_reply", "email": "ana@example.com" } },
  "messages": [{ "seq": 119, "author": "agent", "text": "Hi Ana, ...", "at": "2026-10-22T18:40:00Z" }] }

Errors follow the same shape. A 401 with reason: "identity_expired" makes the widget call the host's token callback once and retry; a second failure boots anonymously rather than showing an error to the visitor. A 403 with reason: "origin_not_allowed" means the snippet was copied onto a site the customer didn't list, and the widget stays hidden. Socket events reuse the chat app guide's envelope, with three support-specific types: conversation.state, queue.update and availability.changed.

Running it in the interview

This question is a trap for candidates who start drawing a chat app. Spend the first 5 minutes on what makes it a widget: whose page it runs on, how few visitors open it, single-page or multi-page hosts, signed-in users, office hours. Say early that message delivery works like any chat and that you'll focus on the embedding.

Then draw the three layers (host page, our iframe, our servers) and the two-stage load with a KB budget, about 10 minutes. Spend the next 15 on the two topics that separate strong answers: signed identity with logout, and restoring across navigations and tabs without a reconnect storm. Use the last 10 for the bot to human state machine and the attention rules, and leave 5 for questions.