Why do companies believe this is the future of customer interaction?

The Short Answer

When a customer service chatbot cannot answer, it should:

recognize that it has reached its limit;
explain that limit clearly;
offer a concrete next step;
transfer the customer and relevant context to a human when necessary.

If the bot instead repeats generic content, hides contact routes or ends the conversation without resolution, the automation increases customer effort rather than reducing it.

A few days before writing this article, I contacted a company chatbot with 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

Scope and Limitations

I tested five publicly accessible chatbot experiences used by large Swiss companies. Each received the same generic scenario during one observation period.

This was not a repeated experiment, a representative sample or a statistical comparison. The companies remain anonymous because the purpose is to examine recovery patterns, not to publish a ranking.

The findings show how the tested interactions behaved at that moment. They do not establish the performance of every chatbot session or the companies’ complete customer-service systems.

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.

Results at a Glance

The five chatbot experiences produced five different recovery patterns:

Company 1: strong security triage and a clear decision path;
Company 2: useful clarification, transparent limits and concrete alternatives;
Company 3: fast human handoff, but weak transfer of conversation context;
Company 4: honest fallback, but the customer had to search for the recovery route;
Company 5: duplicated menus, simulated progress and no completed handoff.

The strongest bots did not answer every question. They recognized the type of situation, disclosed their boundaries and preserved a path to resolution.

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.

A customer-service bot therefore becomes a useful test of a broader principle: the technology is not the hard part; the system change is.

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.

If your organization needs to decide whether an AI service investment should be tested, redesigned, scaled or stopped, my innovation strategy consulting provides an independent review of customer evidence, operational assumptions and expected value.

Thanks for reading INNOVATION& by Yetvart Artinyan! This post is public so feel free to share it.

What Happens When a Customer Service Chatbot…