Most live chat buying decisions get made backwards. Someone adds a widget because competitors have one, nobody is rostered to watch it, and within a month the bubble is a slow-motion contact form that quietly annoys people who expected a human.
The decision that actually matters is not which chat tool to buy — it is whether you can answer the chats, and how fast. Everything else in this guide is downstream of that. Settle your coverage model first, and the category sorts itself into three obvious shapes, only one of which will fit you.
Gate one: should chat exist on your site at all?
Chat earns its keep in specific situations, not universally. Work through these before you look at a single product page.
Signals that chat will pay off:
- Pre-purchase hesitation on a high-consideration page. If people stall at checkout, on a pricing page, or on a booking form because of one unanswered question — sizing, compatibility, lead time, whether you serve their region — chat catches revenue that a contact form loses. This is the strongest case there is.
- A high volume of repetitive, low-judgement questions. Order status, opening hours, delivery windows, how to reset a password. Repetition is what automation can absorb.
- A support inbox where the delay itself is the complaint. If your email replies are good but slow, chat compresses the cycle.
Signals that chat is the wrong purchase:
- Nobody can be on it during business hours. An unstaffed chat widget performs worse than no widget, because it sets an expectation of immediacy and then breaks it.
- Your questions all require research. If answering means opening three systems and calling a supplier, chat's real-time promise works against you — email is a better container for that work.
- Your traffic is thin. A widget on a site with a handful of daily visitors produces a trickle of conversations and a monthly bill.
If you fail this gate, the useful purchase is usually a better help page, a clearer FAQ, or a shared inbox — not chat.
Gate two: synchronous or asynchronous?
This is the fork that has changed most in the category, and getting it right removes most of the staffing anxiety.
Synchronous chat means the visitor expects a reply now. The widget shows "we're online", and the value is speed. It requires an actual roster.
Asynchronous messaging means the visitor leaves a message, closes the tab, and is notified — by email or a persistent thread — when you answer. The conversation survives the session. Most modern tools support both, but they default differently, and the default is what your customers will experience.
A one-person team almost always wants async-first behaviour with clear stated response times, plus a genuinely synchronous window for the hours it can staff. That combination is honest and cheap. A tool that can only do "online / offline" and dumps offline visitors into a form is a worse fit than its feature list suggests.
The three shapes of product in this category
Once your coverage model is settled, the market resolves into three shapes. They overlap at the edges, and vendors blur the lines, but the underlying architecture is different and so is the cost of living with each.
Shape 1 — the chat widget
A chat bubble, a conversation list, canned replies, basic routing, a transcript. That is the whole product.
Best for: a small site where one or two people handle everything and email volume is low. Fastest to deploy, cheapest to run, least to learn.
The trade-off: chat lives in its own silo. A customer who chats today and emails tomorrow arrives as a stranger, and you have two inboxes with no shared history. That is tolerable at low volume and corrosive above it.
Shape 2 — the shared inbox or helpdesk with chat as one channel
A single queue where chat, email, and often social messages land together, with assignment, statuses, notes, and reporting across all of them.
Best for: teams already drowning in a shared support address, or anyone whose customers switch channels mid-problem. This is the most common right answer for growing small businesses, because it fixes the underlying queue problem rather than adding a channel on top of it.
The trade-off: more configuration, more concepts (tickets, statuses, assignment rules), and a bigger migration if you already have history elsewhere.
Shape 3 — the conversational platform
Chat plus bot flows, proactive triggers based on page or behaviour, visitor data, CRM sync, routing to sales as well as support, and campaign-style outbound messages.
Best for: teams where chat is a revenue channel, not just a support one, and where someone owns the tool as part of their job.
The trade-off: it needs an owner. Flows rot, triggers misfire on pages they were never designed for, and a bot built once and abandoned becomes the thing customers try to escape. Buy this shape only if a named person has time to maintain it.
The criteria that actually separate tools
Inside your chosen shape, these are the criteria worth scoring. As with any category, define them before you look at candidates — the general method is in our guide to choosing business software.
- Coverage behaviour. What exactly happens outside your staffed hours, and can you set expectations in the widget itself? Ask to see the offline experience, not the online one.
- Routing and queueing. Who gets a new conversation, what happens when they are already in three, and how does a conversation get handed to someone else without the customer repeating themselves.
- Automation you can maintain. Not "does it have a bot" but "can the person who will own this build and change a flow without help". Bots are good at deflecting known questions, collecting context before a human arrives, and routing. They are bad at judgement. The realistic split is covered in our piece on AI chatbots for customer support.
- Integrations that answer the actual questions. If most chats are "where is my order", the tool must reach your order system. A logo wall is not an integration; check what it reads, what it writes, and in which direction.
- Continuity. Does a chat become an email thread cleanly when it needs research? Can an agent see the customer's previous conversations regardless of channel? This is where shape 1 and shape 2 genuinely diverge.
- Agent mobile experience. For small teams this is often decisive, because the person answering is not always at a desk.
- Transcripts, export, and ownership of the data. You should be able to get conversation history out in a usable format. A channel you cannot leave is a channel that will price against you later.
- Consent and data handling. Chat collects personal data and often visitor tracking. Confirm what is stored, where, and for how long, and whether that matches your obligations and your customers' expectations.
- Pricing shape, not price. This category bills in several ways — per agent seat, per conversation or resolution, per contact reached, or by feature tier. Per-seat scales with headcount; per-conversation scales with success, which is fine until a marketing campaign lands. Check the vendor's current pricing page for the numbers, and evaluate the shape against how you expect to grow.
Trialling chat specifically
Chat is unusual among software categories in that a trial can be genuinely conclusive, because you can run real traffic through it inside two weeks. Structure it the way our software trial guide describes, with two additions:
- Trial it during your worst hour, not your quietest. The queue behaviour under pressure is the product.
- Have a real customer go off-script. Ask the bot something adjacent to what it was built for, then watch how it hands over. That handover is the moment most tools are judged by customers, and most buyers never test it.
Common mistakes
- Buying a platform when the problem is a queue. Adding bot flows to an unstaffed widget does not create coverage.
- Measuring chat by volume. Conversations are an activity number. Judge it by resolved questions, abandoned checkouts recovered, and whether email volume actually fell.
- Letting the widget promise what the roster can't deliver. "Typically replies in minutes" is a commitment.
- Never rewriting the bot. The questions people ask change. A flow written once and left alone is a slowly worsening customer experience.
FAQ
Do I need live chat if I already have a shared inbox? Often not immediately. If the complaint is speed rather than channel, tightening the inbox process is cheaper. Add chat when you can point to a specific page where hesitation is costing you conversions.
Is a chatbot enough on its own? Only for a narrow band of repetitive, well-documented questions — and only with an obvious, fast route to a human. A bot with no exit is the single most reliable way to turn a support interaction into a complaint.
Can one person realistically staff live chat? Yes, with async-first defaults, honest stated response times, and a bot or help-centre search absorbing the repetitive questions. What one person cannot do is guarantee instant replies all day, so do not buy a tool that advertises that on your behalf.
How do I know whether chat is working? Compare against the reason you bought it. If it was pre-sale hesitation, look at conversion on the pages where chats start. If it was inbox load, look at whether email volume dropped rather than at chat volume rising.
Next step
Write down two lines before you shortlist anything: the hours a human will genuinely be available, and the one question you most want chat to answer. Those two lines pick your shape — widget, shared inbox, or platform — and rule out most of the market for you. Then take the survivors into a two-week trial with real traffic.
When you are ready to compare candidates side by side, compare live chat software on Nexuswoot, where each tool is scored on chat experience, automation, integrations, and value. Nexuswoot earns affiliate commissions from some of the tools it compares; the rankings follow the published criteria, not the payouts, and the criteria above are the ones you should be applying either way.
