People search "live chat vs chatbot" expecting a verdict, and I understand why: it sounds like a purchasing decision. It is not. Every good support setup I have seen runs both. The real decision is the seam: which conversations software should take first, which a person should own, and how one hands to the other without dropping the visitor. Get the seam right and the versus question dissolves. Get it wrong and it does not matter which side you picked, because the customer experiences the gap.
I run demos and set up bots for customers most days, so I spend a lot of time exactly on that seam. Here is where each side genuinely wins, and how the handoff between them should work.
What the bot does better
The bot answers at 2am, on a Sunday, during your product launch, while your one support person is at a wedding. Availability is the obvious win, but it is not the interesting one.
The interesting one is repetition tolerance. Real visitors ask the same question forty different ways: "wheres my package", "order still not here", "did my stuff ship", "tracking?". A bot fields all of them identically well, on the thousandth occurrence, without the slow erosion of patience that makes a human's fortieth answer of the day shorter than their first. Add instant recall of exact policy wording, and answering in whatever language the visitor writes in, and you have a machine built for the repetitive majority of support traffic. The language part alone changes the shape of a small team's inbox: questions you used to lose to the language barrier start arriving, and getting answered, with nobody hired.
There is also consistency of record. The bot quotes the policy as written, every time, which surfaces a problem humans quietly paper over: if the written policy is wrong or unclear, the bot exposes it immediately. Teams sometimes read this as the bot failing. It is the documentation failing in public, and fixing the page fixes every future answer at once.
One caveat that decides everything: all of this holds only when the bot is grounded in your real content. A bot without your content is a liability with a text box. The setup rules that make the difference are in chatbot best practices, and the broader picture of what these systems can and cannot do is in our plain-English guide to AI customer support.
What a human does better
Exceptions. The policy says 30 days and this customer is on day 34 with a decent story; software should never decide that, in either direction.
Ambiguity. "It doesn't work" can mean nine different things, and a person hears which one in two follow-up questions, half by tone.
Emotion. An apology from software is worth nothing, and everyone knows it. When someone is angry, the repair is a person taking responsibility, not a well-phrased paragraph.
Stakes. The customer with a large order hovering over the cancel button, the prospect evaluating you for their whole company, the quiet "just checking my options" from an annual-contract customer that is anything but small. These conversations have judgment in them, and judgment is the job. Bots do not have it, and a vendor who tells you otherwise is selling something.
Notice what that list has in common: none of it is answering documented questions. When a person's day is spent reciting the returns policy, they are being used as a search engine with feelings, which is expensive for you and demoralizing for them. The point of drawing the seam well is that each side gets the work it is actually good at.
Handoff is the actual craft
Everything above is easy to agree with. The craft is in the transfer, and it has three parts.
Triggers. The explicit request is sacred: when someone types "talk to a human", that is the end of the negotiation, not the start of one. Beyond that, route when the bot fails twice on the same question, when frustration shows in the text, when the visitor is on a high-stakes page like pricing or enterprise, and for any customer on a list you care about. Write these rules down before launch; a trigger invented mid-incident is always too late.
Two of those deserve a word. Page context matters because the same words carry different weight in different places: "do you offer discounts" on the pricing page is a buying signal, and in the help center it is a policy question. And the second-failure rule exists because the first failure is information (maybe a content gap you can fix tonight) while the second is a visitor being held hostage by your knowledge base.
Context. Whoever picks up must see the whole thread: what the visitor asked, what the bot answered, what it looked up. The visitor should never repeat themselves, and nothing says "we don't talk to each other here" like being asked for the order number twice. In Hey Support the conversation lands in a shared inbox with the full history attached, and can ping your team in Slack, so the human starts warm. However you build it, treat "visitor never repeats themselves" as the acceptance test.
Expectations. When nobody is online, say so. Collect an email, give an honest reply window, and continue the thread there, with the transcript attached so your reply can open with the answer instead of with questions. A truthful "we'll reply tomorrow morning" keeps more goodwill than a fake "connecting you..." ever bought anyone.
The small-team reality
If support is you and maybe one other person, you are not choosing between live chat and a chatbot. You are the escalation team, and the choice is what reaches you.
Async handoff beats pretending to be 24/7. The bot takes the repetitive layer (the piece on reducing ticket volume covers what belongs in it), and everything it cannot resolve gets collected with context and an honest reply-time promise. Say you get 300 chats a month: across the setups I have watched, the pattern is that most resolve on the spot, and the remainder arrives as a triaged morning queue instead of an all-day interrupt stream. The math of your specific mix will differ, but the shape rarely does.
A workable pattern: live during your real working hours, async everywhere else, and let the widget tell the truth about which mode it is in. Visitors handle "replies within a day" fine. What they do not handle is discovering the promise was decorative.
The one thing to resist is fake presence. Do not show "we're online" at 3am because it converts better. It converts into people waiting.
Three ways the seam fails
Handoff purgatory. "Connecting you to an agent..." and nobody comes. This is worse than having no chat at all, because it is an explicit promise being broken in real time, with a spinner. If nobody can realistically pick up within a few minutes, do not offer "live" at all; offer a reply time you can keep.
The blocked exit. The visitor types "human please" and the bot replies "I can help with that! What is your question?" Every round of this converts a mild question into a complaint.
The amnesiac human. The transfer works, a person arrives, and opens with "How can I help you today?" while the entire conversation sits right there above the cursor. The visitor retypes everything, now annoyed, and the team wonders why handoff CSAT is low.
All three are fixable with settings and honesty, which is what makes them embarrassing to ship.
Decision rules to steal
Defaults I set up for most teams, adjusted later with transcript evidence:
- Always route to a person: an explicit request, legal or complaint language, refunds above your comfort threshold, cancellation of a large account, any order that has already gone wrong twice.
- Always let the bot take it first: order status, shipping and returns policy questions, hours and logistics, docs and how-to questions, pre-sale product questions.
- Route on signal: a second failed answer, visible frustration, an enterprise-sized question on the pricing page, a returning visitor with an open issue.
The seam moves over time. Reading transcripts weekly tells you when: bot answers that should have escalated sooner, escalations the bot could now handle. Move the dial, do not rebuild the wall.
Run both, mind the seam
The versus framing sells software. The seam framing runs support. Bots take volume, humans take judgment, and the handoff carries context so the visitor never pays for your org chart. Start the bot narrow, watch the handoffs, and widen its scope as the transcripts earn it.
If you want both halves in one tool, the widget, the shared inbox, and the handoff wiring are all part of what Hey Support ships, and the free plan is enough to test the seam on your own traffic before you spend anything.
