Widget placement, and when not to show a chat launcher

Almost every website assistant ships with the same default: bottom right corner, every page, always visible, sometimes with a proactive message after a few seconds. Most teams never change it, which means the configuration on their site is a vendor default rather than a decision.

It is worth deciding, because the default has real costs on some pages and real value on others.

Where a launcher earns its place

• Pricing pages, where hesitation is highest and the question is usually specific.
• Documentation and help pages, where the visitor has already failed to find something.
• Feature and comparison pages, where evaluation questions surface.
• Checkout or signup flows, where an unanswered question ends the session.

Where it usually does not

• The blog, where visitors are reading rather than evaluating and a launcher is an interruption.
• Legal pages, where the visitor wants to read a document.
• Landing pages built for a single conversion action, where any competing element costs something.
• The homepage above the fold on mobile, where screen space is scarce.

That last one deserves emphasis. On a 390 pixel viewport a floating launcher occupies a meaningful share of the visible area and frequently sits on top of a primary CTA. Check this specifically. It is the most common mobile problem with any widget and it is invisible on a desktop screenshot.

Proactive messages

A message that opens itself after a delay converts better in some contexts and annoys reliably in others. The distinguishing factor is whether it is relevant to the page.

A generic “Hi, how can I help” that fires everywhere reads as automated and gets dismissed. A page specific prompt on a pricing page that names the actual common question can genuinely help. If you cannot write a page specific prompt worth reading, do not enable a generic one.

The accessibility floor

Whatever placement you choose, three things are not optional:

• The launcher is reachable and operable by keyboard.
• Opening the dialog moves focus into it, and closing returns focus to the launcher.
• The dialog can be dismissed with the escape key.
• It does not obscure content in a way that makes any part of the page unreachable, at any viewport width.

The brand argument

There is a reason premium software sites tend to use restraint here. A widget that shouts, follows and interrupts communicates something about how the company treats attention. A widget that waits until it is wanted communicates the opposite.

That is not a measurable argument and I will not pretend it is. But if you are building a product whose entire pitch is that it listens, the way it behaves on your own site is the first demonstration a visitor gets.

Placement is a conversion decision

The launcher occupies the same corner as the sticky call to action on most sites, and on mobile it competes for the same thumb position. That is not a styling detail.

On a page with one intended action, the assistant is a competing action. On a page where the visitor is stuck, it is the recovery path. Which of those a page is determines whether the widget helps or costs you.

Nobody measures this because the widget is installed site wide by default and there is no obvious before and after. It is worth measuring precisely because it is invisible.

Where it should not appear

Checkout and payment steps. The counterfactual for chat here is not a lost answer, it is a completed purchase. Anything that pulls attention is a cost.

Login and account recovery. The visitor has a specific mechanical task and an assistant cannot help with account state.

Forms mid completion. Opening a chat window over a half filled form is a good way to lose the form.

Legal pages. Someone reading terms wants to read terms, and an assistant offering to summarise them is offering something you do not want to be on record having offered.

Where it earns its place

Pricing and comparison pages, where objections form and the answer is usually one page away.

Product and category pages, for the same reason.

Documentation, where the visitor is already looking for a specific answer and search has usually failed them.

The 404 page, which is the single most underused placement. Someone who hit a dead end has a clear intent and no path, and an assistant is a better recovery than a link to the homepage.

Mobile deserves a separate decision

Desktop placement is nearly free because the corner is empty. Mobile placement is expensive because the screen is small and the thumb zone is contested.

A launcher that covers a sticky add to basket button is a direct revenue cost and it is easy to ship without noticing, because it only overlaps at certain viewport heights.

Check it at 390 and at 320 with the sticky elements present, not on a desktop browser resized to look narrow. The two are not the same and the difference is exactly where this breaks.

Auditing placement on a site you inherited

Open every template at 390 with the sticky elements present and look at the bottom right corner. That is the entire audit and it takes ten minutes.

Note every page where the launcher overlaps a primary action, a cookie banner, a back to top control or a sticky price bar. Overlap with a cookie banner is the most common and the most embarrassing, because it is visible to every first time visitor.

Then check the pages where the launcher should not be at all, using the list above rather than judgement in the moment.

Fix by exclusion rule in configuration rather than by removing the script from templates, so the rule stays in one readable place and a new template inherits the correct default.

Delay the launcher rather than hiding it

On pages where the assistant is useful but not urgent, appearing immediately competes with the page being read.

A short delay, or an appearance triggered by scroll depth, keeps it available without interrupting. This is a middle option between always visible and excluded, and it is the right answer more often than either.

Measuring whether placement helped

Placement is one of the few assistant decisions that can be tested cleanly, because it is a page level change with a page level outcome.

Pick one template, remove the launcher, and compare the primary conversion on that template against the period before. Not against a different template, which differs in too many other ways.

The comparison worth making is not conversation rate. It is whether the page did the job it exists for. A product page that produced fewer conversations and more baskets is a page where removing the widget helped.

Give it long enough to mean something. Weekly traffic on a single template is usually too small to read in a few days, and the temptation to call it early is how teams end up with confident wrong beliefs about placement.

And test removal rather than addition. Adding a widget to a page changes several things at once. Removing it from a page where it already lives isolates the variable.