A poorly designed customer service bot doesn't save money; it shifts it. It reduces one visible expense—the cost of the support team—and increases others that no one attributes to that decision: lost customers, escalated complaints, eroded reputation, and, increasingly, legal liability for what the system says.
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.
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.
The court deemed that argument remarkable—in the sense of surprising—and ordered Air Canada to compensate the customer. The amount was symbolic: 812.02 Canadian dollars. The precedent is not.
What's relevant for any direction is this: What your bot says is what your company says.. 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.
Departure | How is it measured? | Who sees her |
Savings on support | Automated queries x cost per query | Operations Management, every month |
Lost customers | Churn of those who had a bad interaction | Nobody attributes it to the bot. |
Late scaling | Cost of resolving an aggravated incident | Support, without tracing the origin |
Formal complaints | Legal time and compensation | Legal, months later |
Reputation | Reviews, social media, word of mouth | Marketing, without an identified cause |
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.
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. A bot that automates a lot and scales poorly produces excellent numbers and an angry customer.
It does not allow you to leave. 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.
He doesn't know who you are. A bot without access to customer context—orders, open issues, history—forces 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.
He confidently states what he does not know. 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.
It promises things that the company will not deliver. 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.
It doesn't learn from what it climbs. 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.
We have analyzed a specific case of this pattern and its consequences in How a chatbot ruined a company's reputation
The difference between the two results isn't in the model. It's in four design decisions made before writing any code:
Decide what NOT to do. Before the scope, consider what's out of scope. Claims, legal issues, cases involving clients in special circumstances—anything that involves a financial commitment. This list must be explicit and written by the business, not the technical team.
Connect it to the source of truth. The status of an order should not be generated: it should be queried. Language generation serves to explain, not to determine facts. This distinction—the model drafts, the system decides—eliminates most of the risk at once.
Design scaling as part of the product. 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.
Measure the satisfaction of the scaled customer, not just the automated one. It is the indicator that detects damage before it appears in the churn.
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.
There are contexts where the correct answer is not to automate the first line:
In these cases, automation makes more sense behind the scenes: preparing the response that a person then sends, summarizing the history before the call, classifying, and routing. The savings are real, and the risk to the customer is zero because there's a human involved.
It's not "how much we're going to save." It's: How much does it cost us to lose a disgruntled customer, and how many would have to leave to cancel out the savings?
In most B2B companies, that number is uncomfortably small. Doing the math beforehand is what separates cost-effective automation from savings that come at the expense of your customer base.
Yes. In the case of Moffatt v. Air Canada (2024), the British Columbia civil court rejected the argument that the chatbot was responsible for its own statements and ordered the airline to compensate the customer for the incorrect information the system had provided.
Due to a measurement asymmetry: the savings in support are calculated with monthly precision and attributed to the project, while the damage —lost customers, aggravated incidents, complaints and reputation— is spread across several departments and is not attributed to automation.
The resolution rate on the first interaction combined with the satisfaction of escalated cases. The automation rate in isolation is misleading: a bot that automates a lot and scales poorly produces a good number of resolutions but an unhappy customer.
State it explicitly and escalate to a person with the full context, without the client having to repeat information. The problem with a bad bot isn't making mistakes, but rather asserting the same level of certainty whether it's right or wrong.
Separating two functions: the system determines the facts by consulting the source of truth (order status, contracted terms, amounts), and the model only drafts the explanation. Any financial or deadline commitments must be excluded from the language generation process.
When volume is low and each client has a significant impact on revenue, when most inquiries are complaints, when the sector has a high emotional or regulatory burden, or when the company competes for their personal attention, automation performs best behind the scenes, preparing what a person then sends.
Are you going to automate customer service? We first design what the system shouldn't do, connect it to your source of truth, and build scalability into the product. We'll analyze your case in two hours, with no obligation. Let's talk → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
