{"id":32173,"date":"2026-08-27T20:45:00","date_gmt":"2026-08-27T20:45:00","guid":{"rendered":"https:\/\/thecloud.group\/?p=32173"},"modified":"2026-08-17T20:46:47","modified_gmt":"2026-08-17T20:46:47","slug":"bad-bot-customer-service-cost","status":"publish","type":"post","link":"https:\/\/thecloud.group\/en\/mal-bot-atencion-cliente-coste\/","title":{"rendered":"A bad customer service bot destroys more value than it saves"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
<\/div>\n\t\t\t\t\t\t
\n\t\t\t\n\t\n<\/svg>\t\t<\/div>\n\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"logo\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

A bad customer service bot destroys more value than it saves<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

August 27, 2026<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

A poorly designed customer service bot doesn't save money; it shifts it. It reduces one visible expense\u2014the cost of the support team\u2014and increases others that no one attributes to that decision: lost customers, escalated complaints, eroded reputation, and, increasingly, legal liability for what the system says.<\/p>

The balance sheet is almost always presented incompletely. The cost avoided per automated query, which is easy to calculate, is shown, but the cost of poorly resolved queries, which is difficult to calculate and considerably higher, is not shown.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

The precedent that changed the conversation<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In 2024, the British Columbia Civil Resolution Court decided the case of *Moffatt v. Air Canada*. A customer had consulted the airline's chatbot about bereavement fees, and the system provided incorrect information. When the customer complained, the company argued that the chatbot was, in essence, responsible for its own statements.<\/p>

The court deemed that argument remarkable\u2014in the sense of surprising\u2014and ordered Air Canada to compensate the customer. The amount was symbolic: 812.02 Canadian dollars. The precedent is not.<\/p>

What's relevant for any direction is this: What your bot says is what your company says.<\/strong>. There is no accountability architecture. If the system promises a refund, a condition, or a deadline, the organization is responsible for it just as if an employee had said it. And unlike an employee, the system can tell ten thousand people before anyone notices.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Departure<\/strong><\/p><\/td>

How is it measured?<\/strong><\/p><\/td>

Who sees her<\/strong><\/p><\/td><\/tr><\/thead>

Savings on support<\/strong><\/p><\/td>

Automated queries x cost per query<\/p><\/td>

Operations Management, every month<\/p><\/td><\/tr>

Lost customers<\/strong><\/p><\/td>

Churn of those who had a bad interaction<\/p><\/td>

Nobody attributes it to the bot.<\/p><\/td><\/tr>

Late scaling<\/strong><\/p><\/td>

Cost of resolving an aggravated incident<\/p><\/td>

Support, without tracing the origin<\/p><\/td><\/tr>

Formal complaints<\/strong><\/p><\/td>

Legal time and compensation<\/p><\/td>

Legal, months later<\/p><\/td><\/tr>

Reputation<\/strong><\/p><\/td>

Reviews, social media, word of mouth<\/p><\/td>

Marketing, without an identified cause<\/p><\/td><\/tr><\/tbody><\/table>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Where is the real cost?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The asymmetry is structural: savings are measured with monthly precision and attributed directly to the project; losses are spread across five departments and never attributed to anyone. This is why support automation projects are almost always presented as successes, even though the customer receives worse service.<\/p>

The way to correct that asymmetry is to measure the full balance from the beginning, not afterward. And the metric that best captures this is not the automation rate, but the resolution rate in the first interaction combined with the satisfaction of escalated cases<\/strong>. A bot that automates a lot and scales poorly produces excellent numbers and an angry customer.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

The five sins of a bad bot<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

It does not allow you to leave.<\/strong> The symptom that destroys value the fastest. A customer who can't find a way to communicate with someone doesn't stay: they leave or write publicly. The escalation option should be visible from the first message, not hidden behind five failed attempts.<\/p>

He doesn't know who you are.<\/strong> A bot without access to customer context\u2014orders, open issues, history\u2014forces the repetition of information the company already has. This is the clearest sign of a system installed on top of the process rather than integrated into it.<\/p>

He confidently states what he does not know.<\/strong> The problem isn't that it makes mistakes, it's that it makes mistakes with the same tone it uses when it's right. A well-designed system has explicit conditions for saying "I can't confirm that" and passing it on to a person.<\/p>

It promises things that the company will not deliver.<\/strong> Herein lies the legal risk. Any commitment regarding amounts, deadlines, refunds, or conditions should come from a reliable source within the system, not from the model generation.<\/p>

It doesn't learn from what it climbs.<\/strong> Each scaled case provides data on what's missing. If no one regularly reviews the scaled cases to correct the design, the bot doesn't improve: it just gets outdated.<\/p>

We have analyzed a specific case of this pattern and its consequences in How a chatbot ruined a company's reputation<\/a><\/u><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

How to design a bot that actually adds value<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The difference between the two results isn't in the model. It's in four design decisions made before writing any code:<\/p>

Decide what NOT to do.<\/strong> Before the scope, consider what's out of scope. Claims, legal issues, cases involving clients in special circumstances\u2014anything that involves a financial commitment. This list must be explicit and written by the business, not the technical team.<\/p>

Connect it to the source of truth.<\/strong> The status of an order should not be generated: it should be queried. Language generation serves to explain, not to determine facts. This distinction\u2014the model drafts, the system decides\u2014eliminates most of the risk at once.<\/p>

Design scaling as part of the product.<\/strong> With complete context, without the client repeating anything, and with a committed timeframe. A good scale is a positive experience; a bad one is worse than not having had a bot at all.<\/p>

Measure the satisfaction of the scaled customer, not just the automated one.<\/strong> It is the indicator that detects damage before it appears in the churn.<\/p>

An organization that makes these four decisions can confidently deploy automation. One that doesn't is gambling its customer relationship on the behavior of a probabilistic component.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

When a bot is simply the wrong decision<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

There are contexts where the correct answer is not to automate the first line:<\/p>