Website chat widget setup: adding live support to your site

Tuesday, 3:40 p.m. Twenty-three visitors are on the pricing page of a company that sells accounting software. One of them wants to know when the invoice is issued on an annual plan, looks for somewhere to ask, and finds the contact form at the bottom: name, email, subject, message, plus a captcha. The form never gets filled in. The tab closes. The only trace the next morning is a session that spent one minute and twelve seconds on the pricing page. Nowhere does it say what the question was, only that nobody answered it.

This article covers how to set up a web chat widget so that question can be asked without leaving the page. In order: deciding what job the widget does, choosing which pages and which moment it appears on, installing the snippet and allowlisting your domains, writing the greeting and the pre-chat form, configuring after-hours behaviour, wiring up assignment and response-time targets, drawing the line between bot and human, attaching the conversation to a customer record, setting up measurement, and clearing the mistakes most teams make in the first thirty days.

What do you need to decide before the bubble goes live?

A chat widget is not a design element. It is a promise printed on the page: write to us and you will get an answer. When that promise is broken, having no bubble at all is better than having one, because a visitor who is ignored loses more than an answer. So the first installation step is a decision, not a line of code: what job is this widget doing? In practice there are three, and no widget does all three well at once. Removing pre-purchase friction, booking a meeting or demo, and handling support questions from existing customers.

Those three jobs live on different pages, are answered by different people, and tolerate very different response speeds. A question on the pricing page expects a reply in minutes; a question inside the docs can wait an hour. Skip this decision and the bubble opens with the same sentence everywhere, one person is nominally responsible for all of it, and by week three nobody opens the inbox. If you want the commercial reasoning behind that first job, the piece on how live chat turns browsing visitors into pipeline is a useful starting point.

Which pages should show the widget, and when?

Firing the bubble on every page the second someone arrives is the most common mistake. A visitor who does not yet know what they are looking for closes the popup and never opens it again. A good setup thinks about page, intent and timing together: what decision is this visitor about to make, and how would we know they are stuck on it? The table below is a sensible starting configuration for a B2B site. The numbers are illustrative and should be replaced with your own measurements.

Page	Widget's job	Trigger	What the first message asks
Pricing	Remove a buying blocker	30 seconds, or exit intent	Which plan fits their team
Product and feature pages	Book a demo	Second product page viewed	Whether they want to see it on their own data
Help centre and docs	Catch the unanswered question	Site search returns nothing	Whether they found what they came for
Checkout or signup form	Prevent abandonment	60 seconds idle in the form	Which field they are stuck on
Blog and content	Stay out of the way	None	Bubble stays closed

The last row is deliberately empty. Someone reading an article did not arrive to buy, and the bubble there is only a distraction. On pages built to book meetings, the chat becomes an invitation: the conversation ends with a calendar link. Before wiring that flow, it helps to settle what the demo itself promises, because the sentence that books the meeting depends on it. On mobile, loosen every trigger: a bubble that opens early on a small screen covers half the content.

Installation: from the snippet to the first real message

Technically, installation is usually one script tag. But a bubble appearing on screen does not mean the setup is finished. In Rocketly, the Web Chat Widget feature works through allowlisted domains: only visitors from the domains you have added reach your inbox, and a copied snippet running on another site opens nothing. That detail matters during testing, because teams who forget to add their staging domain conclude the widget is broken.

• Allowlist your domains: production, staging, and any campaign subdomain you use.
• Place the snippet on the templates where you decided to show chat, not on every template you own.
• Write the visibility rule and the trigger delay, with separate values for desktop and mobile.
• Choose which team the conversation lands with. Never leave an unowned queue.
• Put your privacy notice on the first screen of the bubble: what is collected, and for how long it is kept.
• Send a test message from two devices and confirm it appears in the inbox and raises a notification.

Have someone outside the project run that test. An insider finds the bubble because they know where it is; if an outsider cannot find it, you have a contrast, placement or mobile behaviour problem. Measure page speed before you ship, too: the widget script should load after the main content and must not delay first paint.

What should the greeting say, and what should the pre-chat form ask?

"How can I help you today?" is polite and useless, because it hands the thinking back to the visitor. A good greeting is page-specific and offers exactly one choice. On a pricing page, "tell me how many seats you need and I will point you at the right plan" gets far more replies than a generic hello. Write the greeting by looking at the decision the visitor is making on that page, not at your own feature list.

The pre-chat form is a balancing act. Collect nothing and you cannot follow up when a conversation drops halfway; ask for four fields up front and half of your visitors leave without typing. The practical answer is to spread the data collection across the conversation: let the first message be free text, and ask for contact details only once the chat has gone somewhere. There is more on staging that request in the guide to capturing leads with a website chatbot. Save your recurring answers as Quick Replies so an agent sends the same explanation in one click instead of retyping it ten times a day, and your wording stays consistent by default.

What happens to messages that arrive after hours?

Most visitors have no idea what your working hours are. If a message sent at midnight will be read at nine the next morning, the visitor needs to know that up front. Otherwise the reply they expected never lands, they go to a competitor, and there is no second chance. The Out-of-Hours Auto Reply feature works per channel, so web chat can carry different hours from WhatsApp. A message that arrives while you are closed is not lost: the visitor sees when you will be back, and the conversation lands open in the morning queue.

The wording matters. "We are unavailable right now" is a closed door. "We will reply first thing at 9:00 tomorrow; if it is urgent, message us here instead" is a bridge, and it makes asking for an email address feel natural. You can compare the same logic on other channels, especially template and time-window choices, in the piece on setting up WhatsApp auto replies. Define a separate calendar for public holidays. Business-hours rules that keep working through a bank holiday are one of the more irritating failures.

Who answers the chat: assignment, SLAs and a rota

Most widget rollouts collapse for reasons of ownership, not technology. The bubble opens into a queue everyone can see and nobody owns. Week one it is a novelty; by week three the unread count is in triple digits. This is where the Assignment Rules and SLA feature earns its place: the conversation lands with a team or a person the moment it opens, a response-time target is attached, and breaching that target pushes it to the top. Messages with an owner close far faster than messages without one.

Build a rota into the calendar: two-hour blocks with one person on point and a named backup. When the person answering is out of their depth, they can ask the team through Internal Team Chat without taking the question to the customer, and the visitor sees nothing change. Some web chat requests will not close in one message and become tickets; the handover from chat to ticket is set out step by step in the guide to running a help desk and ticket queue.

Where does the bot stop and the human start?

The boundary between bot and human is the single decision that determines widget quality. Bots are good at questions whose answers are documented and uniform: opening hours, delivery times, integration lists, invoicing dates. Negotiation, objections, complaints and any sentence starting with "our situation is a bit different" belong to a person. Tie the handover to content rather than to a counter. A rule that says "escalate after three messages" is usually three messages too late.

How to build that handover, how to carry context across it and which signals should summon a human is a subject in its own right; the article on getting the bot-to-human handoff right draws that line with examples.

Rocketly adds an intermediate step: the AI Reply Suggestion feature reads the conversation and drafts a response, while the agent decides whether to send it. That pairing gives you the speed of automation with a person's judgement on top. Decide in advance how the assistant should sound and when it should stay silent by writing down its persona, tone and knowledge base.

Where does a chat conversation live in the CRM?

Chat arrives through a channel with no record attached, so it floats away easily: the visitor is anonymous, the conversation closes, and when the same person phones two weeks later nobody can find it. This step is about record discipline more than technology. A conversation gains a history the moment it is attached to a contact. The Contact Directory collects everyone who has written to your inbox into one list and merges the same person's conversations across channels, so a thread that started in web chat and continued over email does not read as two different customers.

Customer 360 History then shows notes, tags and open deals alongside the conversation, so an agent never has to ask a visitor what was discussed last time. On the sales side, a qualified chat has to become an opportunity, and defining at which stage and with which fields that happens is far cheaper than cleaning up data later. Compare where adding a channel sits in the wider sequence in the CRM implementation guide.

Which numbers should you actually watch?

Widget success is not measured in conversation volume; volume is just a function of traffic and trigger settings. Meaningful measurement answers four questions: how many visitors wrote, how fast they got a reply, whether the conversation reached an outcome, and whether the visitor was satisfied. The Inbox Statistics Dashboard puts open, pending and closed conversations, channel split and load per agent on one screen. Channel Analytics shows peak hours and the response-time trend, so you can rebuild the rota around real load instead of guesswork.

When a conversation closes, a single-use CSAT Survey invitation attaches the score to that specific conversation, and seeing which pages produce the low scores is the fastest route to rewriting a greeting. If you want demo requests and signups that start in chat to speak the same language as your ad reporting, plan your conversion tracking setup so widget events are included from the start. Instrument on day one: you cannot generate two months of history retroactively.

What goes wrong in the first thirty days?

The first failure is launching the bubble without assigning anyone to it. The second is reusing one greeting across every page. The third is quieter: the widget stops working and nobody notices. When a connection drops or a channel starts erroring, the Channel Health Panel raises an alert, attempts to reconnect and shows the webhook logs. Do not open that panel once during launch week and forget it. A silent channel costs more than a badly answered one.

The fourth failure is scaling before you measure the load. Saved View Alerts exist for exactly this: set a threshold such as "tell me when unanswered web chats go above five", and the alert runs against that view's own conditions so you hear about it before it becomes a backlog. The fifth is leaving the widget to work alone. The same question arriving ten times a day is a documentation gap, not a chat problem, and closing that loop with a self-service knowledge base lowers chat volume while raising the value of the conversations that remain.

If you want to test this on your own site, open a Rocketly account and put the widget live on a single page first.

FAQ

Does a web chat widget slow the site down?

Loaded asynchronously and after the main content, the script should not delay first paint. Take two measurements before you ship, with and without the widget. If the gap is visible, check the script's load order and the trigger delay.

If a visitor writes and then closes the tab, is the conversation lost?

No. It stays open in the inbox. If you captured contact details you can follow up by email or another channel; if you did not, the chat resumes where it left off when they return in the same browser.

How many pages should I launch the widget on?

Start with one. Pricing, or your most visited product page, is a good candidate. Measure response time and conversation quality for two weeks, and widen the scope only if the team can carry the load.

Can a bot and an agent answer the same chat?

Yes, in sequence. The bot handles the opening message and establishes intent, then hands over when a defined condition is met. Both writing in parallel confuses the visitor, so keep the handover one-directional.