Live chat
Talking to visitors while they are still on the page.
What this shelf covers
Talking to visitors while they are still on your website: chat widgets, proactive messages, automated answers and the routing that decides who picks up.
The line with support software is blurred. Help desks own the ticket queue and the slow work. Live chat owns the fast window when somebody is on a page with a question that will otherwise become an abandoned session.
Ticket queues and shared inboxes sit in customer support. Community forums belong in community platforms.
Two different jobs sold as one
Sales chat and support chat need opposite settings.
Sales chat wants to be seen. It appears on pricing and product pages, greets after a delay, and asks a question that helps somebody decide. Speed matters more than depth, and the goal is to remove a blocker before the visitor leaves.
Support chat wants to be found. It sits where existing customers look, answers precisely, and prefers a correct reply in four minutes to a fast reply that is wrong.
Deciding which one you are buying is what makes the configuration obvious afterwards, and skipping that decision is why so many widgets end up serving neither audience well.
Routing, hours and expectations
The failure that costs the most is a visitor who writes into silence.
Set visible hours and mean them. Show a real response time rather than an implied instant one. Outside hours, collect an address and reply where the person can actually be reached. That turns an unanswered message into a conversation rather than a disappointment.
Routing matters once more than two people answer. Look for assignment by page, by language, by team or by customer value, and check what happens to a conversation when the assigned person goes offline mid-sentence.
Automation that does not annoy people
- Answer bots trained on your help centre, useful for repeat questions.
- Qualifying questions, collecting context before a human joins.
- Triggers based on page, time on site, cart value or return visit.
- Saved replies, which cut handling time more than any bot.
- Handover, immediate and obvious when automation fails.
That last point decides whether visitors tolerate the rest. A bot that loops, apologises, offers the same article twice and refuses to fetch a person leaves the worst impression any support tool can manage.
Proactive messages need restraint. One well-placed trigger on a page where people genuinely hesitate outperforms a greeting on every page, which trains visitors to close the widget on arrival.
Speed, privacy and the technical side
Chat widgets are heavy. Many pull a large script, web fonts, an iframe and a websocket before the visitor has done anything, and the cost lands on the pages you most want to be fast.
Check the weight, whether loading can be deferred until interaction, and how the widget behaves on a phone. Then measure your own pages with it enabled, because a clean test tells you nothing about what visitors experience.
Privacy questions follow quickly. Transcripts contain personal data, some products record sessions, and consent requirements depend on your market. Ask where conversations are stored, how long they are kept, and whether recording can be limited on pages carrying sensitive information.
What it costs to run
Per agent per month is the norm, with bots, triggers, analytics and integrations parked on higher tiers. A few products meter conversations instead, which suits low volume and punishes a good campaign.
The real cost is staffing. A widget promising quick replies needs somebody able to give them, and the software bill is smaller than the hour it consumes. Count both before deciding where to place it, and read what pricing pages hide for the meters that catch teams out elsewhere.
Placing the widget where it belongs
A chat widget on every page is a default, not a decision, and it usually performs worse than a considered placement.
Put it where questions genuinely block progress: pricing, a complicated product page, the step before checkout, and the support area. Leave it off pages people read rather than act on, where it interrupts without offering anything.
Then decide the behaviour per placement. A proactive greeting suits a page where hesitation is common and irritates on a page somebody is simply reading.
Measure the result rather than the activity. Conversations started is a vanity number. What matters is whether the pages carrying the widget convert better than they did without it, and whether the support queue got shorter.
Questions people ask
- Does live chat hurt page speed?
- It can. Chat widgets are among the heaviest scripts on a typical site. Load it after the page is usable, and measure with the widget enabled rather than in a clean test.
- Should we use a bot or a person?
- A bot for routing, hours and repeat questions, a person for anything else. The pattern that annoys visitors is a bot pretending to be human and refusing to hand over when it fails.
- How is live chat priced?
- Per agent seat, with bots, triggers and analytics on higher tiers. Some products meter conversations instead, which is worth modelling if your traffic is seasonal or unevenly distributed.
- What if nobody is available to reply?
- Set expectations honestly. Show the real response time, collect an email address, and reply where the visitor can actually receive it. A widget that promises immediacy and delivers silence is worse than no widget.
- Does chat increase conversions?
- On considered purchases, measurably. On low-value transactional pages it mostly adds distraction. Test on the pages where questions genuinely block a decision rather than deploying it everywhere by default.