Chat widget UX: helpful, not annoying

You've met this widget. You land on a site you've never visited, and before the page finishes loading, a chat bubble bounces, plays a chime, and auto-opens with "Hi there! Anything I can help with today?" from "Jessica," who is not a person.

You close it. It reopens on the next page. You close it again. Somewhere, a dashboard records two "engagements."

Here's the mental model that fixes all of this: your chat widget is a guest on your own page. The page has a job (explain the product, sell the thing, help the visitor), and the widget is there to assist that job, not compete with it. Good guests are easy to find when you need them and invisible when you don't. Most widgets get this exactly backwards, because the settings that make a widget loud are the same settings that inflate its vanity metrics.

Let's walk through the etiquette, piece by piece, and end with a 30-minute audit you can run on your own widget today.

Placement and timing: knock, don't barge

The bottom corner convention exists for a reason: people know to look there. Fighting the convention with floating mid-page bubbles or slide-in panels doesn't make your widget more discoverable; it makes it more annoying. Pick a corner (bottom-right for most left-to-right sites), and make sure the launcher never covers anything that matters: cookie banners, sticky checkout bars, "Add to cart" buttons, form submit buttons.

Timing is where the real sins happen. Never auto-open with sound on a first pageview. The visitor has been on your site for four seconds. They haven't read your headline yet. An auto-opening widget at that moment is a stranger grabbing your sleeve as you walk in the door, and the sound makes it worse, especially for the person browsing at work or with a sleeping kid nearby.

Does that mean proactive messages are always wrong? No, and this is where judgment comes in. A proactive nudge is justified when the visitor's behavior signals a question forming:

• Someone has been on your pricing page for 45 seconds, scrolling up and down between tiers. "Not sure which plan fits? Ask me anything about pricing" is genuinely useful at that moment.
• Someone in checkout stops moving for a while at the shipping step. A quiet "Questions about shipping or returns?" can save the sale.
• Someone hits an error page or a dead end. Offering help there is just good manners.

Notice the pattern: proactive messages earn their place when they respond to demonstrated hesitation on a high-stakes page. A blanket "open after 5 seconds" rule responds to nothing. And when you do send a proactive message, send it once. If the visitor dismisses it, that answer holds for the rest of the session.

What should the opening message actually say?

When someone does click your widget, the first message sets the contract. Most opening messages fail by promising vaguely ("How can I help you today?") and delivering narrowly (a bot that only knows six FAQs).

A good opening message answers three questions in two or three lines: Is this a bot or a human? What can it actually do? What happens if it can't help?

Hi! I'm an automated assistant. I can track orders,
answer questions about shipping, returns, and sizing,
or connect you with our team (weekdays, 9-5 CET).

That's honest, specific, and it sets the handoff expectation before it's needed. Compare that with a widget that opens as "Jessica" and reveals itself as a bot on message three; by then the visitor feels tricked.

Honesty about capability is not modesty; it's conversion optimization. Visitors who know what the bot can do ask it those things, succeed, and leave happy. Visitors promised everything ask it anything, fail, and leave. I've written before about how fast responses mean nothing if the answer doesn't resolve the problem, and the opening message is where you steer people toward questions that will actually get resolved.

Suggested questions are menu design

Those little tappable question chips under the opening message are the most underrated part of the widget. They're not decoration; they're a menu, and menu design rules apply.

Offer three to five options, not eight. Every option should be a question your visitors actually ask, in the words they use, pulled from your real conversation logs. "Where's my order?" outperforms "Order status inquiries."

Chips do two jobs at once. They advertise capability (each one is a promise the bot can keep) and they route people onto paths you've built well, like an order lookup or a returns flow. If a chip leads to a great pre-approved answer while free-typing leads to a coin-flip, you want most people tapping chips.

And update them. If it's December, "When will my order arrive before the holidays?" belongs on the menu. Stale chips signal a widget nobody maintains, and visitors infer the answers are stale too.

Mobile: the widget lives under a thumb

Half or more of your visitors will meet your widget on a phone, where the physics change completely.

Thumb reach: the launcher sits in the bottom corner, which is prime thumb territory, and that cuts both ways. It's easy to open on purpose and easy to open by accident. Keep the launcher small on mobile, and never let it hover over your sticky "Add to cart" bar; a widget that intercepts purchase taps is a guest standing in front of the cash register.

Keyboard overlap: when the keyboard slides up, does the input field stay visible? Does the conversation scroll correctly? Test this on a real phone; desktop emulators lie about keyboard behavior.

Full-screen conversations: on a small screen, a widget trying to stay "windowed" gives you a chat area four lines tall. Let the conversation take over the screen on mobile, with an obvious, large close button that returns the visitor exactly where they were, scroll position included.

Accessibility is table stakes, not extra credit

A widget that keyboard users can't reach is broken, full stop. The basics:

• The launcher is a real button, reachable by keyboard, with a label a screen reader can announce ("Open support chat," not "widget-launcher-icon").
• Opening the widget moves focus into it; closing it returns focus to the launcher. No focus traps: Escape closes the widget.
• Text meets contrast requirements against your brand colors, including your on-brand accent color, which is where contrast usually fails.
• New messages are announced politely to screen readers rather than yanking focus.
• Respect reduced-motion preferences: no bouncing launcher for visitors who have asked their OS for less animation.

Most widget vendors handle the mechanics; your job is not to break them with custom styling, and to test once with a keyboard and a screen reader.

How do you measure a widget beyond open rate?

Here is the counterintuitive part: a quieter widget with a lower open rate is often performing better. Open rate is trivially easy to inflate; auto-open on every pageview and your "engagement" chart goes vertical while your visitors' opinion of you goes the other way. Opens measure interruptions, not help.

Measure outcomes instead:

• Resolution rate: of conversations started, how many ended with the visitor's question actually answered, without needing a follow-up through another channel?
• Handoff quality: when the bot escalated, did a human respond within the promised time, in the same conversation?
• Post-conversation satisfaction: a one-tap "Did this answer your question?" tells you more than a thousand opens.
• Downstream behavior: did visitors who used the widget complete checkout, sign up, or come back? The widget's real job is helping the page do its job, and I've argued before that deflected-ticket counts mislead teams while revenue-linked measures tell the truth. The same logic applies here: a thousand "deflected" widget chats mean nothing if the visitors left unsatisfied and bought elsewhere.

Read ten full transcripts a week. No metric substitutes for watching where real conversations go wrong.

The 30-minute widget audit

Block half an hour, grab your phone and your laptop, and run this on your live site.

1. Minutes 0 to 5: Visit your site in a private browser window, like a first-time visitor. Note everything the widget does uninvited: auto-opens, sounds, badges, repeated prompts across pages. Anything that interrupts within the first 30 seconds of a first visit goes on the fix list.
2. Minutes 5 to 10: Click the launcher and read the opening message cold. Does it say whether it's a bot? Does it list what it can do? Does it set handoff expectations? Rewrite it now if not; this is a two-minute fix with outsized impact.
3. Minutes 10 to 15: Tap every suggested question chip. Each one should lead to a genuinely good answer. Remove any chip that leads to a shrug, and replace it with a top question from your real logs.
4. Minutes 15 to 20: Repeat the whole flow on your actual phone. Check thumb reach, whether the launcher covers any CTA or sticky bar, keyboard overlap on the input field, and whether closing the chat returns you to where you were.
5. Minutes 20 to 25: Keyboard test on desktop. Tab to the launcher, open it, navigate, close with Escape, and confirm focus returns. If you have a screen reader available, listen to the launcher's label and one message announcement.
6. Minutes 25 to 30: Open your last ten transcripts. Count how many actually resolved, and note the single most common failure. That failure is next week's project.

You won't fix everything in 30 minutes, but you'll know exactly what your widget is doing to your guests.

One brief product note: if your current widget can't do honest openings, pre-approved answers for the chips, or in-conversation human handoff, that's the shape we built Fetchply around, and the free plan is enough to run this audit against a real setup.

• Treat the widget as a guest on the page: easy to find when needed, silent when not, never covering the content or CTAs it exists to support.
• Never auto-open with sound on a first pageview; reserve proactive messages for demonstrated hesitation on high-stakes pages, and send them once.
• The opening message should say whether it's a bot, what it can do, and what happens when it can't; honest scope beats vague promises.
• Design suggested questions like a menu: three to five real questions in customer language, each leading to a genuinely good answer.
• Judge the widget on resolution, satisfaction, and downstream behavior, not open rate; a quieter widget is often a better one.

Should the widget be on every page of my site?

Available on most pages, yes; attention-seeking on none. Some teams remove even the launcher from focused checkout flows to reduce distraction, which is reasonable if your checkout questions are rare. If they're common (shipping costs, delivery times), keep a quiet launcher there; that's exactly where a good answer saves a sale.

Is it dishonest to give the bot a name and avatar?

A name is fine; a fake human identity is not. A friendly robot avatar with a clear "automated assistant" label sets accurate expectations. A stock-photo headshot named Jessica that turns out to be a bot burns trust at the exact moment you need it.

My open rate dropped after I turned off auto-open. Is that bad?

Almost certainly not. Auto-open manufactures opens from people who never wanted to chat. Watch resolution rate, satisfaction, and complaint volume instead; if those held steady or improved while opens fell, you removed noise, not value.

How many suggested questions should I show?

Three to five. Fewer than three wastes the menu; more than five becomes a wall nobody reads. Pull them from real questions and refresh them when seasons, promotions, or your lineup change.