Live chat vs chatbot: which one does your team actually need?

Almost every comparison of live chat and chatbots is written as though you have to pick one, and the framing usually comes from whoever is selling. It is the wrong question. They are not competing products. They are two layers of the same conversation, and the widget in the corner of your website can run both — which is exactly what most teams end up doing, whether they planned it that way or not.

The question worth answering is narrower: which part of your volume should a machine answer, which part needs a person, and how does a customer cross from one to the other without explaining themselves twice. That is a design decision rather than a purchase decision, and it matters more than the vendor bake-off you were about to run.

Live chat, defined

Live chat is a real-time text conversation between a customer on your site and a person on your team, held in a widget rather than an email thread. That is the whole definition, and everything interesting about it follows from the word person.

A person handles anything: the question phrased badly, the complaint underneath the question, the exception to the policy, the customer who was already angry before they typed. They can read a tone and decide to break a rule. No automation sold today does that reliably, and pretending otherwise is how teams end up with a widget nobody trusts.

The constraint is equally simple: a person is available when they are working, and can hold a few conversations at once before quality drops. Live chat therefore has a shape — excellent inside opening hours with enough staff, a queue or a closed sign outside them. Most of the frustration customers report with live chat is not about the chatting; it is about waiting for a chat that was advertised as instant.

Chatbot, defined — and the two very different things the word covers

A chatbot is software that replies in the chat window without a person involved. The word is close to useless on its own, though, because it covers two technologies with almost nothing in common beyond the interface. Half the arguments about chatbots are two people describing different products.

Rule-based chatbots: a decision tree in a chat window

A rule-based chatbot follows a flow you drew yourself: if the customer picks this option or matches this keyword, reply with that, then ask the next question. It is deterministic, which is its real strength — you can read the flow, test it, and know exactly what a customer will be told.

That makes it excellent at structured jobs: collecting an order number before a handover, a returns intake, routing by topic, qualifying a lead. It is poor at everything else, because it can only answer what somebody anticipated. Ask a question the tree does not contain and you get the menu again — the most recognisable failure in support automation, and the reason the word chatbot carries a reputation problem it did not entirely earn.

AI agents: retrieval over your own knowledge

An AI agent answers in its own words, using your help-centre articles, policies and product documentation as the source. Nobody scripts the individual answers; you maintain the knowledge, and phrasing stops mattering — the same question asked five ways gets the same answer, in the language it was asked in.

Its ceiling is therefore your documentation. An AI agent cannot tell a customer something your company never wrote down, and the dangerous version of this product answers anyway, from general knowledge, confidently, with a citation attached — which is worse than silence, because the citation makes it convincing. When you evaluate one, the question to ask is not how accurate it is. It is what specifically happens when retrieval comes back with nothing useful.

When each one wins

Read the table as three jobs rather than three products, because in a hybrid setup you will use all three within a single conversation.

• Live chat wins on judgement and stakes: complaints, refunds outside policy, an account someone is about to cancel, anything where a wrong answer is expensive or the customer is already upset. It also wins on very low volume — below a handful of conversations a day, automation is a project you do not need yet.
• Rule-based flows win on structured steps with a known shape: collecting the order number and email before a handover, a returns intake, routing by topic, a pre-chat form. Deterministic is a feature here, and an AI answering in its own words is the wrong tool for a compliance-shaped step.
• An AI agent wins on the long tail of documented questions — where is my order, what is your returns window, how do I change my plan. That is usually most of the volume by count and a minority of it by difficulty, which is exactly why automating it frees a small team rather than replacing it.

None of them wins by being better. They win by matching a type of question, which is why the decision that actually matters is how a conversation moves between them.

The hybrid model: AI first, human handover, and the seam in between

The setup most support teams converge on looks like this. The widget greets the customer and the AI answers from documented knowledge. Structured steps run as flows. The moment the conversation stops being routine, it goes to a person, with everything that was said already attached. The customer experiences one conversation; internally it crossed two or three systems.

Whether that feels seamless or infuriating comes down entirely to the handover, and it is worth being specific about the triggers rather than trusting a vendor phrase like hands off when unsure. Four are worth wiring: the customer explicitly asks for a person, the topic is sensitive — money, complaints, legal threats, chargebacks — the customer has restated the same question because the first answer missed, or the system cannot ground an answer in anything you have written. The full version, including what has to travel with the conversation and how to tell a good handover from a bad one, is in our handoff playbook.

Two rules do most of the work. Keep the route to a person permanently visible rather than hidden behind a failed answer, and never promise a response you cannot deliver — if nobody is working, take the question and say when it will be answered, instead of showing a queue position that nothing is calculating.

One more seam teams forget to staff: anything that moves money should be prepared by the AI with full context and approved by a person before it executes, which only stays fast if that queue has a named owner. The human side of all this is on our live chat page.

What this means for a small team

If you are two to five people doing support alongside other jobs, the honest read is that you cannot staff live chat properly and you should automate the boring half — in that order, because the sequence matters more than the tooling.

1. Turn on chat with hours you can genuinely cover, and say what happens outside them. An honest closed sign beats a widget promising instant help at 22:00.
2. Spend an afternoon in your own inbox listing the questions you answer most. That list, not a content calendar, is your first ten help-centre articles.
3. Write those ten as answers to real questions rather than marketing pages, and let the AI answer from them. This step sets the ceiling for everything after it.
4. Add flows only where a step has a fixed shape — the order number, the returns intake, the routing question. Do not rebuild support in a decision tree.
5. Read the handover reasons every week. The most common one is the article you write that afternoon, chosen by customer demand instead of guesswork.

The cost question also resolves differently than teams expect. Live chat priced per agent gets more expensive as you hire, which is backwards from what automation is supposed to do for you; automation priced per resolution tracks the work it actually took off your desk. The trade-offs in both directions are in our comparison of per-agent and per-resolution pricing, and our own plans are on the pricing page.

The one thing not to do is buy an automation layer to avoid hiring and then hide the human route to protect the deflection number. It improves the metric, damages the service, and every team that has tried it can tell you which of those two the customers noticed.

If you would rather see the shape than read about it, the live chat side shows what your team works in and pricing shows what the automated half costs when it is billed by what it resolved. Start with the ten articles either way — every version of this decision gets better once your knowledge is written down.