Chatbot vs live chat on a WordPress site

Most small sites that add a chat widget find out within a month what they actually needed. Either the same five questions come in every day, or every question is different and needs someone who knows the business. A chatbot is good at the first case and live chat is good at the second. Neither one works if nobody looks after it.

So the useful question is not which one is better. It is which requests software can answer safely, who answers the rest, and how fast that person can take over. Sometimes the honest answer is that visitors only need a reliable way to reach you. In that case a contact form in WordPress may do more than either kind of chat.

What actually separates a chatbot from live chat

With a chatbot, software writes the replies. With live chat, a person types back in real time, usually from a dashboard or a phone app. Most of the confusion comes from treating “chatbot” as one thing, because there are two very different kinds.

A scripted bot follows a decision tree: buttons, fixed questions and fixed answers. It cannot go off script, which makes it predictable and limited. An AI bot writes its own answers, ideally from a knowledge base made of your pages, posts, products and FAQs. It can handle questions nobody planned for. That is its strength and its risk, because it can also answer confidently when it has no idea.

Many WordPress chat plugins now sell both modes in one widget: a bot that answers first and a person behind it. That setup is called hybrid, and it is the pattern most practitioners recommend. There is also a third pattern that often gets counted as live chat. Contact-button launchers show floating icons that open WhatsApp, Messenger or a phone call. That is a shortcut to another channel, not a chat service.

Before you install anything, check where the conversations live. Many plugins sold as “WordPress chatbots” just place a widget for an external service. The conversations, training and settings sit on the vendor’s servers, not in your WordPress database.

WooCommerce stores have one more trap. WooCommerce’s documentation describes the AI Assistant as an admin tool that does not appear on the storefront. The customer-facing chatbot is the separate AI Support Assistant. You have to enable it and give it an AI provider, a knowledge base and product information.

Which questions belong to a bot and which to a person

Decide by request, not by product. Bots do well with routine, documented, low-stakes questions that come up again and again. People are needed when the answer takes judgment, depends on a specific account, involves money, or comes from someone who is upset.

Request	Better first responder	Why
Opening hours, shipping policy, returns window	Bot	The answer is already written on your site
Order status lookup	Bot, if it can read orders	One fact, a clear finish, no judgment
Inquiry outside business hours	Bot that collects name, contact and job details	Nobody is there to answer, but the lead is still worth keeping
“Will this work for my situation?”	Bot first, person on buying intent	Pricing and fit questions are where sales are won or lost
Refund, wrong charge, complaint	Person	Needs account access, a decision and a believable apology
Anything the bot answered wrong once already	Person	A second guess costs more than a short wait

Practitioners on Reddit and wordpress.org agree on one point: the setup most likely to disappoint is a bot that is supposed to replace people completely. It goes wrong as soon as a visitor has a real problem with an order or an account.

Bots handle more chats than they resolve

The Comm100 Live Chat Benchmark Report 2025 looked at accounts that use AI chatbots. In those accounts, bots handled 62.7% of chats in 2023 and 73.8% in 2024. The share the bots actually resolved stayed flat: 46.0%, then 45.8%.

That gap matters more than any other statistic in this debate. Vendors usually advertise “handled” or “deflection” figures. A bot can take part in three quarters of conversations and still finish fewer than half. The rest either reach a person or end without an answer. Keep the source in mind, though. Comm100 sells chat software, and its data comes from its own customers, who mostly run staffed support teams rather than one-person WordPress sites.

Why customer preference surveys seem to disagree

The surveys measure different things, so they are not really in conflict. Salesforce’s State of the AI Connected Customer research, a YouGov survey of 15,015 consumers in 2024, found that 30% would use an AI agent instead of a person to get faster service, and 35% would do so to avoid repeating themselves. Tidio’s 2025 study of 1,300 people, Helpful or Hopeless?, found that about 30% would still wait for a human even with a bot available right away, and more than 11% would pay extra to skip the bot.

Both are vendor studies, and Tidio recruited its respondents through Amazon Mechanical Turk and Hotjar, which is a weaker sample. The practical lesson is the same either way: preference depends on the task and the wait. Someone checking a delivery date wants speed. Someone who was charged twice wants a person.

Handoff only happens if someone configured it

Turning on AI in a chat tool does not mean a person will see the questions the bot could not answer. In hybrid tools, what happens after a failed answer is a setting. The usual options are to transfer the chat to an agent, keep it with the bot, or turn it into a ticket or email. Offline hours often have their own setting. Check both, because the defaults may not match what you assume.

A bot that runs overnight does not solve problems overnight. At best, it collects the details so someone can reply in the morning. Tell the visitor that plainly, and give a time they can expect a reply.

A good handoff has four parts:

• The bot says it does not know instead of guessing.
• The conversation carries over, so the visitor does not have to explain twice.
• The “talk to a person” option is visible from the start, not hidden behind three failed answers.
• Pricing questions and clear buying intent go to a person.

A fallback line can be as simple as: “I can’t sort out a billing problem here. I’ve saved your question and order number, and someone will reply by email by 10 a.m. tomorrow.”

What chat costs is mostly staff time

Chat tools charge in several different ways, so comparing price tags directly tells you little:

• Per agent seat each month. The bill grows with your team.
• Bundles of conversations. The bill grows with your traffic, including spikes you did not plan for.
• Free core with a paid AI add-on.
• A plugin licence plus your own AI API key. The model provider bills you separately for usage.

The bigger cost is people. Live chat needs someone covering the hours the widget promises. A bot needs someone to write, check and update the content it answers from, and to read the conversations where it went wrong. None of the research behind this article compares the total cost of the two. “Bots are cheaper” is an assumption, not a finding.

Where chat goes wrong after it is installed

Live chat that nobody answers

Practitioners say this is worse than having no chat. It tells visitors nobody is there, and you lose the lead. If you cannot cover normal business hours, even shared between a few people, hide the widget when you are offline or switch to a form.

A bot that guesses or loops

The common complaints are bots that guess, send the wrong help article, or keep asking “Did that solve it?” Train the bot only on content you control, set clear limits on what it answers, and judge it by conversations resolved, not conversations handled. A commenter in r/woocommerce warned that a bot that cannot find the right answer in your content is more frustrating than a slow reply.

Too few chats to matter

Small-business threads on Reddit argue both ways. Some site owners report almost no chats after months. Others say a simple capture flow brought in evening and weekend inquiries they would have missed. The deciding factors are traffic, how often the same question comes back, and whether a short flow is enough. Long flows lose people.

More leads, worse leads

Agencies report that bots can bring in more leads than forms, but more of them are unqualified and take time to sort through. One or two qualifying questions based on what your business actually does will filter better than an open text box.

Widgets that get in the way

Google’s guidance on interstitials and dialogs recommends banners over large dialogs, so do not auto-open a full-screen chat. Google renders JavaScript and indexes the rendered HTML. An answer that exists only inside a chat conversation is not page content, so keep the important answers on the page as well. For accessibility, WCAG 2.2’s Focus Not Obscured criterion says an open chat window must not completely hide the control that has keyboard focus. W3C’s suggested fixes are to let content reflow, place the window in unused space, or let Escape close it.

Why the widget shows for you but not for visitors

Usually the cause is caching or JavaScript optimization. Logged-in admins normally skip the page cache, so you see the widget while visitors get an older copy of the page, or a script that loads in the wrong order. An MxChat thread on wordpress.org started exactly like this: the bot appeared for the admin but not for normal visitors. Work through these checks in order:

1. Connection. Confirm the plugin is active and the account or site ID is saved. Use one install method only, either the plugin or pasted code, never both.
2. Display rules. Check desktop and mobile settings, page exclusions, and any option that hides the widget when no agent is online.
3. A clean test. Open a new private window, not one that was already open, and load the page logged out.
4. Each cache layer. Purge the caching plugin, then the host’s server cache, then the CDN. On some hosts, the server purge does not clear the CDN. Why a page is not updating walks through each layer.
5. Script optimization. Turn off delay and defer JavaScript for a moment. If the widget comes back, turn the options on again one at a time, exclude the chat script from the one that breaks it, and update the chat plugin. Do not leave all optimization off for good.
6. The theme. The theme must call wp_footer() before </body>. That is how WordPress prints footer scripts, and many widgets rely on it. A console error like e(...).live is not a function means outdated jQuery code. Updating the theme fixes that. Reinstalling the chat plugin does not.
7. Conflicts. The Health Check plugin’s Troubleshooting Mode turns off plugins and switches the theme only for your logged-in session, so visitors to a live store are not affected.
8. Content Security Policy. If the site sends a CSP header, add the chat vendor’s domains to script-src and frame-src. Do not remove the policy.
9. Works on staging, missing on live. Compare the page source on both, then ask the host about differences in PHP settings.

If none of that finds it, the broader guide to WordPress plugins that are not working covers debug logs and conflict testing. If you would rather hand the problem off, SiteSelf’s WordPress bug-fix work traces it on your live site and reports what it changed. Plugin settings work through the connector plugin. Theme and script fixes need hosting access.

How to decide for your own site

Start with last month’s questions, from your inbox, phone notes and form entries. Sort them into routine and judgment calls. Then name who can answer, and during which hours.

If you are unsure, have a person handle chat for a few hours a day before building a bot. You will learn what visitors actually ask, and that becomes the bot’s first knowledge base. Automate only the questions that keep coming back and already have written answers. Set up handoff for both staffed and offline hours. Then, for the first few weeks, read the conversations the bot did not resolve. Those tell you what to add to your content, and which questions should go straight to a person.