The Customer Service Bot Is Not the Future If It Cannot Admit Failure
I chatted with a company chatbot today because of a simple customer question.
Nothing complicated. I had received a generic message and wanted to understand what I was supposed to do next.
The answer was bad.
Not aggressively bad. Politely bad. The kind of bad that makes the system sound helpful while sending you in circles. It gave generic replies. It did not understand the situation. It repeated itself. It pushed me back toward website content I had already checked.
At some point I caught myself thinking what many customers probably think:
Why do companies believe this is the future of customer interaction?
That question annoyed me enough to run a small test.
So I did a short, non-academic field check of chatbots used by large Swiss companies. Not as a representative study. Not as a scientific benchmark. Just as a structured customer test on a Saturday afternoon.
The test was simple
I used the same generic prompt across companies:
I received a message from your company and do not understand exactly what I need to do. The information on the website does not help because my case does not quite fit.
Then I observed what happened.
Did the chatbot ask a useful clarification?
Did it identify the type of issue?
Did it explain its limits?
Did it offer a concrete next step?
Did it connect me to a person?
Did it get stuck in a loop?
Did it pretend to help while pushing the work back to me?
This was not a test of chatbot intelligence in the abstract.
It was a test of customer-resolution capability.
There is a difference.
A chatbot that can answer “What are your opening hours?” is not a customer service bot. It is a conversational FAQ wrapper.
A useful service bot must handle the moment when the customer says:
This does not answer my case.
That is the point where most systems show what they were really built for.
This is not only my irritation
The research direction is clear enough.
The Consumer Financial Protection Bureau’s report on chatbots in consumer finance warned that chatbots can help with basic questions, but may fail when customers need meaningful assistance with complex issues. The report also describes repetitive “doom loops” where customers cannot reach a human when the chatbot has reached its limits.
Research on chatbot service recovery makes a similar point. A study on chatbot messages after service failure found that recovery responses only help when they move the interaction forward. Solution-oriented recovery can increase perceived competence. Empathy-oriented recovery can increase perceived warmth. But neither helps much if the customer still has no path to resolution.
Recent work on gatekeeper aversion in customer service chatbots is also relevant. People may avoid chatbot channels not only because the bot performs poorly, but because they dislike being forced through an imperfect first stage before possibly reaching a human expert. The study suggests that transparency about chatbot limits, wait times, and faster access to live agents can improve adoption.
That matched what I saw.
The worst bots were not bad because they failed to answer everything.
They were bad because they failed to know when they had stopped helping.
Company 1: Strong triage
Company 1 performed well.
When I framed the situation as an unclear email that might require login, payment, or action, the bot immediately moved into security triage. It warned me not to click links, not to open attachments, not to disclose data, and explained how to treat suspicious emails.
That was useful.
It did not simply say: “Log in and check.”
It understood that an unclear email from a financial institution is not just an information problem. It may be a fraud problem.
When I asked whether to delete, report, or officially verify the message, the bot gave a clear decision path. If the message was suspicious, report it. If I wanted official verification, contact support. If I needed to log in, use the official website or app, not a link in the email.
This was not a perfect experience. Human support required authentication, which is understandable in financial services. But the bot did something important:
It reduced risk before pushing me into action.
That is a real service contribution.
Company 2: Clear boundary honesty
Company 2 also performed well, but in a different way.
The scenario involved a confusing insurance-related statement. The bot first asked useful diagnostic questions. Was it a bill, a benefits statement, or another type of message? Did it mention a payment, missing documents, or a deadline?
That is already better than dumping a link to a FAQ.
Then I made the case more specific. I said the statement mentioned cost participation, but I could not tell whether I had to pay something or whether the document was only informational.
The bot explained the relevant distinction in plain language. It described what the customer should check and when a statement is likely informational versus payment-relevant.
The best moment came when I asked directly:
Can you check my concrete case in this chat, or are you only giving general information?
The bot answered clearly that it had no access to personal data or specific cases. It could only provide general guidance. It then gave the next step: check the customer portal, call support, or use the contact form.
That answer matters.
A chatbot does not lose trust by admitting its limits.
It loses trust when it pretends those limits are not there.
Company 3: Fast human handoff
Company 3 did not try to be clever.
When I said my case did not fit the website information, the bot asked whether I wanted to be connected with a specialist.
I said yes.
It gave me a choice between identification and guest mode. I chose guest mode. A human agent joined.
That is not sophisticated AI.
But it is good service logic.
Research on chatbot-to-human handover shows that the handoff itself matters. Customers communicate differently with bots than with human agents, and the way repair and transfer happen affects whether the conversation keeps progressing or resets awkwardly.
Company 3 got the most important part right. It did not force me through five irrelevant answers before giving me access to a person.
The weakness was context transfer. When the human joined, the conversation more or less restarted.
That is still a cost for the customer.
But at least the door opened.
Company 4: Honest fallback, weak recovery
Company 4 was more limited.
The bot admitted it could not find a suitable answer. It said live chat would be available again on Monday morning.
Since this was Saturday afternoon, that limitation is fair.
Not every company needs 24/7 human support. That is not the issue.
The issue was what happened next.
When I asked what I could do now, the bot repeated the same fallback. Only after I explicitly asked for a person, phone number, or contact form did it offer a contact form.
That is a weaker design.
The escape route existed. But the customer had to fight to find it.
A better bot would have said immediately:
I cannot answer this specific case. Live chat is closed until Monday. You can either submit a contact form now or return during opening hours.
That would have been honest, clear, and useful.
Instead, the first recovery move was repetition.
That is how service friction hides inside polite wording.
Company 5: The menu loop
Company 5 was the weakest.
The bot gave me several contact entry points, but some were duplicated. One option appeared twice. Later, another consultation-related option appeared twice. The bot seemed to classify my request into overlapping menu categories without knowing how to move forward.
At one point, it said it was not sure whether it had understood me and offered that someone could contact me by email.
I selected yes.
Expected next step: ask for my email address, open a form, confirm a follow-up, or route me to a contact process.
Actual next step: the bot replied as if the matter was finished and asked for feedback.
No email process started.
No contact details were collected.
No handoff happened.
Then, when I pushed again, it returned to another menu. “Email/message.” “Feedback.” “Immediate consultation.” “Personal advice.” Some entries repeated. Selecting one led to another similar menu.
This is the worst version of chatbot design.
Not because the bot could not solve the case.
Because it created the impression of progress and then failed to execute it.
That is worse than a clear contact form.
A bad form is boring.
A broken chatbot is misleading.
No chatbot may be better than a weak chatbot
Some companies did not show an obvious public chatbot in the paths I tested.
That should not be treated as failure.
No chatbot is not automatically worse than a chatbot.
A clear phone number, customer portal, contact form, branch locator, or claim form may be less fashionable. But it can be better service.
A weak chatbot adds effort. It creates loops. It hides contact paths. It makes the customer repeat themselves. It shifts the problem from the company’s support design to the customer’s patience.
The question is not whether a company has a chatbot.
The question is whether the chatbot improves the path to resolution.
The real failure is not technical
Most corporate chatbots do not fail because language models are too weak.
They fail because companies have not made the service-design decision behind the bot.
What is the bot allowed to do?
Can it ask diagnostic questions?
Can it say, “I cannot check your individual case”?
Can it escalate early?
Can it hand over context?
Can it distinguish between a search task, a complaint, a security risk, and a case-specific request?
Research on task type and failure frequency in chatbot failure recovery suggests that the right recovery strategy depends on what the user is trying to accomplish and how often the bot has already failed. A bot may recover some search tasks itself, but repeated failure or complaint-like situations often require human intervention.
That sounds obvious.
But many companies still design bots as if all customer problems were search problems.
They are not.
Some are decision problems.
Some are trust problems.
Some are exception problems.
Some require access to customer data.
Some require a human because the customer needs accountability, not another paragraph.
The minimum standard
A useful customer service bot does not need to solve everything.
But it must know which of four situations it is in:
The answer is known and safe to give.
The customer needs help classifying the issue.
The customer needs a case-specific path.
The bot has stopped helping and must escalate.
Most weak bots confuse these situations.
They treat unresolved customer problems as content retrieval problems.
That is the root error.
The best bots in my small test did not necessarily sound more human. They behaved with clearer judgment.
One triaged risk.
One admitted its boundary.
One escalated quickly.
The worst one duplicated contact options, offered a follow-up, failed to start it, and pushed the user back into menu loops.
That is not automation.
That is customer effort with a chat bubble.
The expensive question
Companies should stop asking:
Should we have a chatbot?
That question is too shallow.
The better question is:
Which customer situations are we willing to let a bot handle, and where must it stop?
If the company cannot answer that, the chatbot becomes a public interface for internal indecision.
A useful bot does not need to be impressive.
It needs to be honest, diagnostic, and connected to the right support process.
If it cannot do that, the future of customer interaction may look a lot like the past, only with a friendlier loading animation.
