Why customers hate chatbots (and what actually fixes it)

Ask a support lead what customers say about their chatbot and you rarely hear neutral feedback. You hear frustration, sometimes anger, and almost always the same five complaints, whether the company runs a homegrown script or a funded platform. Twig reviewed customer complaints about AI support tools and found the list is short and consistent: hallucinated answers, no escalation path, robotic tone, no context awareness, and poor integration.

That consistency is the interesting part. If chatbots failed in random, unpredictable ways, you could blame the technology and move on. Instead the same five failures show up across vendors and industries, which means they come from decisions, not accidents, and orgs reporting a negative consequence from generative AI climbed from 44% in 2024 to 51% in 2025 (CMSWire).

This guide takes each of the five complaints in turn, names the design decision that causes it, and lays out the fix. None of the fixes are exotic. If you are choosing between an AI chatbot and an AI agent for your own support queue, understanding why the five complaints happen will tell you more than a feature comparison ever will.

Why customers say they hate chatbots

Service orgs running AI agents grew from 39% in 2025 to 66% in 2026, and 91% of CX leaders report executive pressure to deploy AI, according to Salesforce data reported by DigitalApplied. Deployment has outrun design discipline, and customers are the ones who notice the gap first.

A chatbot that hallucinates once, refuses to hand off once, or repeats a question it was already asked once does not just lose that one exchange. It teaches the customer not to trust the channel at all, which is why the complaints in Twig's research show up as visceral, specific frustration rather than mild annoyance. The rest of this guide treats each complaint as a design bug with a design fix, in the same spirit as choosing between an AI chatbot and an AI agent for a real support queue.

There is a second, quieter reason the gap matters. A support team that can name exactly which decision produced which complaint has a far easier time getting budget and engineering time to fix it than one that reports a vague sense that customers are unhappy with the bot. Naming the decision turns a mood into a project with a scope, an owner, and a way to know when it is done.

Hallucinated answers: confident wrong information

Communicate.so

Hallucination is not a rare glitch. It is the default behavior of a language model that is asked a question it does not actually know the answer to. A model trained to always produce fluent text will produce a fluent, confident, wrong answer rather than admit uncertainty, unless something in the system stops it.

The incidents are not hypothetical. In February 2026, a cloud storage company's support chatbot cited a downgrade policy that did not exist, according to SocialIntents. A cofounder at Cursor publicly acknowledged an incorrect response from a front-line AI support bot, as reported by Fortune.

Neither company set out to lie to a customer. Both shipped a bot that answered from its training data instead of from a verified source.

The design decision behind this complaint is simple: someone decided the bot could answer from general knowledge instead of retrieving from your actual documentation. The fix is grounding, which means the agent pulls from your connected content before it answers and says it does not know when the content does not cover the question. This is the whole idea behind retrieval-augmented generation for support, and it is why training an AI agent on your help center matters more than which model you pick.

Communicate's AI agent retrieves from your connected content before every answer and is built to decline rather than guess when nothing in your knowledge base covers the question. That single behavior, refusing to invent, is the difference between an agent that occasionally says it does not know and one that occasionally becomes a headline, a distinction the guide to reducing AI hallucinations in support covers in more depth.

No escalation path: trapped in the loop

The second complaint is structural rather than linguistic. A customer asks a question the bot cannot answer, the bot rephrases the same non-answer twice, and there is no visible way to reach a person. The customer is not angry that the bot was wrong.

The customer is angry that they were trapped.

The design decision here is a bot built to resolve everything itself, with escalation treated as a failure state to hide rather than a normal part of the flow. That framing is backwards. A well-designed handoff is not an admission of defeat, it is the feature that keeps a hard question from turning into a lost customer.

The fix has two parts. First, the agent needs an explicit trigger for handoff, typically low confidence, an explicit request for a human, or a topic marked as sensitive by policy. Second, the handoff needs to carry the full conversation so the human does not make the customer repeat themselves, a workflow covered in detail in the guide to support escalation workflow design.

Communicate runs this through a shared inbox where the AI and a human sit on the same conversation, so escalation is a handoff, not a restart.

Robotic tone: talking to a wall

Communicate.so

Tone is the complaint people struggle to articulate but recognize instantly. A bot that answers correctly but sounds like a form letter still leaves customers cold, because the interaction reads as an obstacle to get past rather than help being offered.

The decision behind robotic tone is almost always a generic system prompt copied from a template, with no examples of how the brand actually talks and no rubric for what a good answer sounds like. Nobody wrote down what warm and direct looks like for this specific company, so the model defaults to a flat, hedging, over-formal register that reads as corporate rather than human.

The fix is treating tone as a specification, not a personality toggle: real example exchanges, a short list of words the brand does and does not use, and a rule against burying the answer under three sentences of throat-clearing before it. Communicate's AI agent configuration accepts custom instructions and example conversations for exactly this reason, because tone quality comes from the prompt and the examples you supply, not from swapping the underlying model.

No context awareness: repeating yourself

The fourth complaint is the customer explaining their problem twice, or being asked for information they already gave. It happens when the bot cannot see order history, prior tickets, or even the last three messages in the same conversation.

The design decision is treating every message as a fresh session instead of a continuous conversation with memory and account context attached. A bot with no access to a customer's order or account record is guessing at facts it should simply be able to look up, which pushes the conversation back toward the hallucination problem covered earlier.

The fix is connecting the agent to the systems that hold the answer, through data sources for reference content and actions for account-specific lookups and changes, so the agent can check an order status instead of asking the customer to repeat it. Guardrails matter here too. An agent that can act on an account needs scoped permissions, a topic covered by AI agent guardrails, so it looks things up correctly without overstepping what it should be allowed to change.

Poor integration: the bot that cannot see your account

Communicate.so

Poor integration is the complaint underneath several of the others. A bot that cannot see billing status, cannot check a shipment, and cannot read a prior ticket is going to hallucinate more, escalate worse, and repeat questions more often, because it is operating with almost no real information.

This is the complaint least likely to fix itself with a better prompt, because the decision behind it is architectural. Someone shipped a chatbot as an isolated widget layered on top of existing systems instead of wiring it into the tools support agents already use every day.

The fix is integration depth, not conversational polish. That means connecting the agent to the same data support agents rely on, through data sources and actions, and putting the chat surface where customers already are with embeddable widgets rather than a separate app customers have to discover. Vendors that market themselves against the heavier end of the market, the Zendesk AI alternative and Intercom alternative comparisons cover this, often win by connecting more of a customer's real data with less setup, not by having a flashier chat window.

The common thread: design decisions, not AI limits

Lay the five complaints side by side and a pattern appears. None of them are caused by a model being too weak to do the job. All five are caused by a decision, usually made under deadline pressure, to skip grounding, skip escalation design, skip tone specification, skip context, or skip integration.

The table below maps each complaint to its cause and whether a configuration change, not a new model, fixes it.

Four of the five are prompt and policy fixes you can make this week. The fifth, integration, takes real engineering time, which is exactly why it is the complaint that separates a genuinely useful AI customer support deployment from a chat widget bolted onto a website for the sake of having one.

None of the five complaints require accepting a lower bar for what AI support can do. They require accepting that a chatbot is a product with real design decisions behind every behavior, the same way a checkout flow or an onboarding sequence is, rather than a black box you configure once and hope performs.

The order also matters when you plan the work. Fixing tone before fixing hallucination just produces a warmer bot that still lies confidently, and fixing escalation before grounding just gives customers a faster path to a human who is frustrated by the same bad handoff every time. Grounding comes first because it is the complaint most likely to turn into a public incident, then escalation, then tone, with integration running in parallel since it takes the longest.

Teams that try to fix all five at once in a single prompt rewrite usually make measurable progress on none of them, because each fix has a different owner in practice. Content and retrieval quality is usually an engineering or data problem, escalation logic is a support operations decision, and tone is closer to brand and copy work. Splitting ownership along those lines, rather than treating the whole list as one undifferentiated AI project, is what actually gets each complaint fixed instead of partially patched.

What good chatbot design looks like

Communicate.so

A well-designed agent is not defined by what it can say. It is defined by what it refuses to do. It refuses to guess when the answer is not in its content, refuses to loop a customer who has already asked for a human, and refuses to pretend it remembers something it was never told.

That discipline starts before launch, with a real onboarding process rather than a same-day flip to live traffic. The AI support onboarding checklist walks through connecting content, writing the tone rubric, and testing edge cases before a single real customer sees the agent. Teams that skip that step are the ones who end up shipping the five complaints by accident.

Security posture belongs in the same conversation, because a well-integrated agent is also touching more of your data. Communicate documents its security posture plainly, including what is and is not certified, so a team wiring an agent into account data can make that call with real information instead of marketing language.

How to audit your own chatbot for these five complaints

You do not need a formal review process to find out if your chatbot has these problems. Run this list against a handful of real transcripts, or against your own bot directly, and the gaps show up fast.

• Ask a question your help center does not cover and see whether the bot admits it does not know or invents an answer.
• Ask for a human directly and count how many exchanges it takes before you reach one.
• Read five transcripts aloud and note every sentence that sounds like a form letter rather than a person.
• Give the bot information in one message and see whether it uses that information two messages later.
• Ask about your own account or order and see whether the bot can actually look it up or just asks you to repeat details.

If your bot fails two or more of these checks, the fix is rarely a bigger model. Compare it against a real deployment guide, like the walkthrough on live chat versus an AI agent, and against your own pricing and setup, before assuming the technology itself is the ceiling.

Run this audit on a schedule, not just once before launch. A bot that passes every check at launch can fail two of them six months later if a content source goes stale, a prompt gets edited for an unrelated reason, or a new product feature creates questions the original testing never covered. Treat the five-point check the way you would treat any other recurring quality review, with a date on the calendar and someone accountable for running it.

The fastest way to lose the benefit of an audit is to run it once, find nothing alarming, and stop. Complaints tend to arrive in clusters after something upstream changes, which means the transcripts worth sampling are disproportionately the most recent ones, not a random slice from months ago. Pair the recurring audit with a quick weekly skim of any conversation a customer rated poorly or explicitly asked to escalate, since that smaller set of transcripts is where the five complaints tend to surface first.

Key takeaways

• The five most common chatbot complaints, hallucination, no escalation, robotic tone, no context, and poor integration, come from Twig's review of real customer feedback.
• Orgs reporting a negative GenAI consequence rose from 44% in 2024 to 51% in 2025, according to CMSWire, tracking closely with unfixed versions of these five complaints.
• Hallucination is fixed by grounding the agent in your actual content and letting it say it does not know.
• Escalation, tone, and context are configuration and policy fixes. Integration is the one that takes real engineering work.
• Audit your own bot against the five complaints before assuming the model, rather than the design, is the problem.

Frequently asked questions

Why do customers hate chatbots so much?

Customers describe hating chatbots for five specific, repeatable reasons: hallucinated answers, no escalation path, robotic tone, no context awareness, and poor integration, according to Twig. The frustration is sharp because each failure breaks a basic expectation, that the answer is true, that a human is reachable, that the bot remembers what was just said.

Is chatbot hallucination still a real problem in 2026?

Yes. A cloud storage company's chatbot cited a downgrade policy that did not exist in February 2026, and orgs reporting a negative generative AI consequence rose from 44% in 2024 to 51% in 2025. The failure mode has not gone away with newer models, because it comes from letting a bot answer without grounding, not from a model being too weak.

What is the difference between a chatbot and an AI agent?

A basic chatbot follows scripted rules or answers from general training data. An AI agent retrieves from your actual content, can take scoped actions like checking an order, and hands off to a human when it should. The AI chatbot vs AI agent comparison covers the distinction in full.

Why does my chatbot repeat the same wrong answer?

It is answering from general training patterns instead of your actual documentation, and it has no mechanism to check whether a rephrase is any more correct than the first attempt. The fix is grounding the agent in your connected content and giving it permission to say it does not know rather than try again with different words.

How do I stop my AI agent from making things up?

Ground it. Connect it to your real data sources and instruct it to answer only from retrieved content, then explicitly allow it to decline when nothing relevant is found. The guide to reducing AI hallucinations and the underlying retrieval-augmented generation approach both cover this in detail.

Why does my chatbot never let customers reach a human?

Because escalation was designed as a failure state to avoid instead of a normal path through the conversation. Add explicit triggers, a direct request for a human, low confidence, and sensitive topics, and make sure the handoff carries full context. The support escalation workflow guide walks through building that trigger logic.

What makes an AI agent sound robotic?

A generic system prompt with no brand voice examples and no tone rubric. The model defaults to a flat, over-formal register when nobody tells it what the brand actually sounds like. Give it real example exchanges and a short list of words to use and avoid, and the tone shifts noticeably without changing the model.

Can I fix chatbot tone without changing the AI model?

Yes, and this is true for almost every tone complaint. Tone comes from the system prompt, the examples given to the agent, and an explicit rubric for what a good answer sounds like, not from which model is running underneath. Communicate's AI agent configuration accepts custom instructions and examples for exactly this reason.

Why does my bot ask customers for information they already gave?

Because it has no memory of the current conversation or no access to the account data that would answer the question directly. Connecting actions and account context lets the agent check the answer instead of asking again, which is the core fix for the no-context-awareness complaint.

Is poor integration harder to fix than the other complaints?

Yes. Hallucination, escalation, and tone are largely prompt and policy fixes you can make in a day. Poor integration requires connecting the agent to the actual systems that hold customer data, which is real engineering work, and it is the complaint most likely to still exist after everything else has been fixed.

Does a bigger or newer AI model fix these complaints?

Rarely on its own. Four of the five common complaints, hallucination, escalation, tone, and context, are caused by missing grounding, missing handoff rules, missing tone specification, and missing account data, not by a model being insufficiently capable. A better model with the same gaps will produce the same complaints, just phrased more fluently.

What percentage of companies are having AI go wrong in support?

Orgs reporting a negative consequence from generative AI rose from 44% in 2024 to 51% in 2025, according to CMSWire. That rise happened during the same period adoption accelerated, which points at rushed deployment rather than a technology ceiling.

How fast should a chatbot hand off to a human?

As soon as the trigger fires, whether that is a direct request, low confidence, or a policy-flagged topic, not after two or three failed rephrase attempts. The AI to human handoff guide covers designing that trigger so escalation feels immediate rather than earned through frustration.

What is the DPD chatbot incident and why does it matter?

In January 2024, DPD disabled part of its support chatbot after it swore at a customer and criticized the company itself, as reported by The Register. It is a public example of what happens when a chatbot has no scoped constraints on tone and behavior, which is why guardrails matter as much as accuracy.

Can a shared inbox reduce these chatbot complaints?

It helps with escalation and context specifically. A shared inbox keeps the AI and a human on the same conversation thread, so a handoff carries full history instead of restarting the customer from zero, which directly addresses two of the five complaints.

Do customers actually notice good chatbot design, or only bad?

Both, but the signal is asymmetric. A chatbot that quietly gets everything right rarely earns praise, while one that hallucinates, traps, or repeats itself generates immediate, specific complaints. Good design mostly shows up as the absence of a bad story, not as a compliment.

How do I test my chatbot before customers find the gaps?

Run the five-point audit from this guide against real transcripts or a live test: an unanswerable question, a direct request for a human, a read-aloud tone check, a memory check across two messages, and an account lookup. The onboarding checklist expands this into a full pre-launch process.

Is it better to under-promise what a chatbot can do?

Yes. A chatbot that is honest about its scope and hands off cleanly outside it earns more trust than one presented as able to handle anything. Overstating capability is exactly what produces hallucination and trapped-loop complaints when the bot meets a question outside what it was actually built to answer.

Does connecting more data sources always improve a chatbot?

Only if the content is accurate and current. Connecting a data source full of outdated policy pages will produce confident wrong answers just as easily as no grounding at all. Audit source content before connecting it, and revisit it on a schedule rather than treating the connection as a one-time setup step.

Where should I start if my chatbot has all five complaints?

Start with grounding, because hallucination is the most damaging complaint and the fastest to fix. Connect real content, allow the agent to decline unanswerable questions, then add explicit escalation triggers and a tone rubric before tackling the deeper integration work covered by data sources and actions. Fix the fast wins first, schedule the integration work with a real deadline, and re-run the five-point audit once every fix has shipped to confirm the complaints actually went away rather than assuming they did.