AI·May 2024·9 min read

AI-Powered Chatbots: Revolutionizing Customer Service on Websites

The chatbot itself is the easy part. The website integration — where the widget renders, how it signals it is thinking, whether a screen reader user can operate it, and what happens to the transcript afterward — is where most launches lose weeks after the backend already works.

What this post covers, and what it doesn't

A separate post on this site already covers the backend architecture: tool-calling, retrieval grounding, evals, and the decision logic for when a bot should hand off to a human (LLMs for customer service automation). Read that one for the model layer.

This post is the surface: the widget itself, sitting on a marketing site or product page, that a real visitor has to see, operate, and trust. That surface has its own failure modes independent of how good the model behind it is.

Where the widget actually lives

Three architectures cover almost every implementation, and the choice affects performance, styling control, and how much you own versus rent.

Approach	What it is	Trade-off
Vendor snippet (iframe or injected script)	A single script tag from a support platform renders the whole widget	Fastest to ship; least control over accessibility and performance, since you're not the one writing the widget's markup
Custom web component	Your own element, e.g. `<support-chat>`, encapsulating markup and styles with the Shadow DOM	Full control over ARIA structure and focus management; you own the maintenance
Framework-native panel	A React/Vue component built directly into the app shell, not a bolted-on widget	Best performance and integration with existing app state (cart, account, order history); most engineering investment

For a marketing site with no logged-in state, a vendor snippet is often the right call. For a commerce app where the assistant needs to see the current cart or order, a framework-native panel earns its cost quickly, because it skips the round trip of re-authenticating context the app already has.

Latency is a UX problem before it's a technical one

Stream the response, don't wait for it

A model that generates a full answer before showing anything feels broken past about a second of silence. Streaming the response token-by-token as it's generated, over server-sent events or a WebSocket, keeps the interface visibly alive the entire time (MDN — Server-sent events, MDN — WebSocket API).

Most model providers expose this natively. OpenAI's Responses API, for example, emits typed streaming events over server-sent events so a client can render partial output as it arrives instead of polling for a finished message (OpenAI — Streaming API responses).

A minimal client-side handler is a few lines, and the append-don't-replace discipline matters from the first line of code:

const es = new EventSource("/api/chat/stream?id=" + conversationId);
es.addEventListener("token", (e) => {
  const chunk = JSON.parse(e.data).text;
  messageEl.append(chunk); // append, never re-render the full list
});
es.addEventListener("done", () => es.close());

Show a typing state, but make it honest

A typing indicator that runs indefinitely while a tool call is happening in the background reads as broken, not busy. If the backend is calling an order-lookup tool, retrieving documents, or waiting on a rate-limited API, surface a distinct state for that instead of a generic dot animation with no ceiling.

The widget script itself has a performance cost

A chat widget is third-party JavaScript by definition, even when you built it yourself and self-host it: it's a separate bundle competing for the main thread with everything else on the page. Load it deferred, not blocking, and treat its bundle size as a line item in your performance budget (web.dev — Efficiently load third-party JavaScript).

Interaction to Next Paint is the metric that actually catches a heavy widget: a large hydration cost on page load, or a chunky re-render on every streamed token, shows up directly as input lag on the rest of the page (web.dev — Interaction to Next Paint).

A chat widget that streams tokens correctly but re-renders the entire message list on every token is a self-inflicted INP problem. Append to the DOM; don't re-render it.

Accessibility of the chat surface

A chat widget is a live, constantly updating region of the page, which is exactly the case ARIA live regions exist for. Getting this wrong is the single most common accessibility failure in support widgets, because the visual design ships fine and the screen reader experience is never tested.

UI element	Pattern	Why
New message list	`role="log"` with `aria-live="polite"`	Announces new messages without interrupting whatever the screen reader is already reading (MDN — log role)
Error or connection-lost state	`role="alert"`	Interrupts immediately, appropriate only for something the visitor must act on right away (W3C APG — Alert pattern)
Widget launcher button	A real `<button>` with a visible, programmatic label	Not a clickable `<div>` — keyboard and screen reader users need a focusable, labeled control to open the widget at all
Open/close state changes	Move focus into the panel on open, return it to the launcher on close	Standard modal focus-management discipline; a chat panel that opens without moving focus strands keyboard users outside it

role="log" and role="alert" are not interchangeable. Using alert for every incoming message interrupts a screen reader user mid-sentence for routine conversation; save it for things that actually require immediate attention.

Label the text input explicitly — a placeholder alone is not an accessible name.
Make sure the send action is reachable and operable via keyboard alone, including Enter-to-send.
Respect prefers-reduced-motion for the typing indicator and any panel-open animation.
Run the whole flow with a screen reader at least once before launch — VoiceOver on macOS/iOS or NVDA on Windows, not just an automated audit.

Designing the escalation handoff

The backend post linked above covers when a model should hand off to a human. The interface problem is different: how do you make that handoff visible and trustworthy to the person in the conversation?

Announce the transition explicitly. "Connecting you to a team member" is a distinct, visible state, not a silent swap where the same message bubble suddenly has a different author.
Preserve the transcript across the handoff. A human agent picking up mid-conversation needs the full history; the visitor should never have to repeat themselves.
Set an honest wait-state expectation. If there's a queue, show it, rather than a typing indicator that runs for minutes with no explanation.
Never let the interface make it ambiguous who — or what — the visitor is talking to. That ambiguity is the single most common trust failure in support widgets, independent of model quality.

Privacy and consent for chat transcripts

A support chat routinely collects more sensitive data than a contact form: order numbers, email addresses, sometimes payment or account details typed directly into the box because it's the fastest way to explain the problem.

Decide retention before launch, not after a request to delete one. Transcripts are a data category like any other and need a documented retention period.
Redact before it leaves the support system. If transcripts feed analytics, a training pipeline, or a QA dashboard, strip PII before it lands there — not as a later cleanup pass.
Disclose that a conversation may be reviewed or used to improve the system, at or before the point where someone starts typing, not buried in a general privacy policy they never open.
Treat the widget's data handling as part of the same privacy program as everything else, not a bolt-on. NIST's privacy framework is a reasonable structure for mapping what a chat transcript actually is as a data asset, independent of chat-specific tooling (NIST — Privacy Framework).

Failure modes that show up after launch

The widget blocks the page it's supposed to help

A widget script loaded synchronously in the <head> can delay Largest Contentful Paint on the very page meant to convert a visitor. Defer it.

Mobile viewport fights the keyboard

On mobile, an open keyboard resizing the viewport is a common source of a chat panel that visually breaks — the input field scrolls out of view or the send button ends up hidden behind the keyboard. Test on real devices, not just a resized desktop browser.

Timezone and locale get hardcoded into the copy

A canned response written once — "our team responds within 24 hours" — quietly becomes wrong the moment support hours change, or reads oddly translated on a storefront serving a different locale. Treat widget copy as content that needs the same review cycle as any other customer-facing text, not a one-time engineering string.

The transcript disappears on refresh

A visitor who accidentally refreshes or navigates away mid-conversation and loses the entire thread will not start over. Persist conversation state to survive a reload, at minimum for the length of a session.

Launch checklist

Pick the widget architecture (vendor snippet, web component, or framework-native) based on how much app context the assistant actually needs.
Stream responses over SSE or WebSocket; never make a visitor wait on a blank state for a full response.
Wire role="log" for the message stream and reserve role="alert" for genuine interruptions.
Test the entire flow, including the escalation handoff, with a screen reader and keyboard-only navigation.
Document transcript retention and redaction before the first real conversation happens, not after.
Load the widget script deferred and measure its INP and LCP cost on the pages it appears on.

FAQ

Should the chat widget load on every page?

Only if it needs to. Loading it deferred and only where support intent is likely — product pages, checkout, help center — keeps its performance cost off pages where it adds nothing.

Is a vendor widget accessible by default?

Not necessarily. Test it the same way you'd test a component you built yourself; vendor claims of compliance vary widely and the actual behavior with a screen reader is what matters.

Do we need explicit consent before someone starts chatting?

At minimum, disclose what happens to the conversation before or at the point of first message, especially if transcripts are used for anything beyond resolving that one conversation.

What's the difference between SSE and WebSocket for this?

Server-sent events are simpler and sufficient for one-directional streaming (server to client), which covers most chat-response use cases. WebSocket is worth the added complexity only if the client also needs to push events back mid-stream.

How do we know if the widget is hurting page performance?

Measure Interaction to Next Paint and Largest Contentful Paint with and without the widget loaded, on the actual pages it appears on, not a synthetic test page.

Does streaming change how we should log conversations?

Log the final assembled message, not every intermediate token — storing every partial chunk multiplies storage for no analytical benefit and complicates the redaction step before transcripts reach analytics.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.