When your support chatbot gets something wrong, you own the answer. That isn’t an opinion. A Canadian tribunal said so in February 2024, and every support team running a bot on its website should read the decision.
In Moffatt v. Air Canada, a passenger asked the airline’s chatbot about bereavement fares after his grandmother died in November 2022. The chatbot told him he could buy a regular ticket and apply for a partial refund within 90 days. Air Canada’s real policy didn’t allow that. The tribunal ordered the airline to pay him, as Manatt summarised, a partial refund of C$650.88 plus interest and fees.
The sum was small. The principle wasn’t.
What did Air Canada argue, and why did it fail?
The airline admitted the chatbot’s words were misleading. It still argued it wasn’t liable for information from its agents, servants or representatives, including a chatbot, and that the chatbot was effectively a separate legal entity responsible for its own statements.
The tribunal member rejected that. He asked why a customer should have to double-check one part of the website against another, and found the airline hadn’t taken reasonable care to make sure the chatbot was accurate. The legal label was negligent misrepresentation. The plain-English version is simpler: if it’s on your site, it’s your answer.
None of this is new to support. In Twitter Customer Service: Who Gets Listened To? I wrote that a public reply is a public promise. A chatbot makes that promise faster, in more places, and with nobody reading over its shoulder.
What does a wrong answer cost you?
The refund in this case was small, so it’s tempting to treat the risk as small. Work it out for your own volume instead. This is an illustration with made-up numbers, not data from any company.
Say your bot handles 10,000 chats a month. Suppose 2 percent of its answers are wrong in a way that matters, such as a policy, a price or a deadline. That’s 10,000 × 0.02 = 200 wrong answers a month. Suppose 5 percent of those turn into a refund claim or a complaint you have to honour, and the average one costs $400. That’s 200 × 0.05 = 10 claims, and 10 × $400 = $4,000 a month, or $48,000 a year.
That figure leaves out the cost of the agent who has to explain what the bot said, and the customers who quietly leave. It also depends entirely on numbers you don’t know until you measure. Which brings us to the first control.
How do you find out how often your bot is wrong?
Sample it. Each week, pull 50 conversations at random from the topics the bot covers, and have a person who knows the policies read them. Mark each one as correct, wrong in a harmless way, or wrong in a way that matters.
If 3 of 50 are wrong in a way that matters, that’s 3 ÷ 50 = 0.06, or 6 percent. Fifty is a small sample, so treat 6 percent as a rough estimate, not an exact rate. The point isn’t precision. It’s that you now have a number, and a trend if you do it every week.
Keep the sample honest. Choose the conversations by number, not by looking for good or bad ones. Include conversations the customer abandoned, since a customer who gave up halfway through often got a confusing answer.
Who should own what the bot says?
One named person per topic. Not a team, not “the AI project.” A person whose job includes reading the sample, fixing the source article, and saying yes or no when someone wants the bot to answer something new.
This is the same lesson as the shared Twitter accounts of 2009, where a public account was answered by dozens of people and the promise “I’ll find out” belonged to nobody. A bot is a shared account with a very large team. The fix is the same: a case owner, written rules and a log. I covered how the promise to the customer is only as good as the weakest team behind it in my piece on customer SLAs.
Write the rules down where the bot’s builders and your agents can both see them. Best Buy published a short set of tips for its employees on Twitter in 2009: say who you are, don’t ask for personal information, say you’ll find out and then follow up. A bot’s equivalent is a list of topics it must never answer on its own, such as refunds, legal terms and anything that changes a price.
What should the bot never do on its own?
I’d draw the line at anything where a wrong answer creates an obligation. Refund rules, contract terms, deadlines, eligibility, medical or safety information. On those topics the bot should quote the published policy word for word, link to it, and offer a human.
Everything else it can do, and do well: order status, password resets, finding the right article, collecting details before a hand-off. The skill is knowing which side of the line a question sits on, and your own agents already know. Ask them.
Then test the line. Ask the bot ten questions on the refund topic in ten different phrasings, including some in a customer’s clumsy wording. If any answer disagrees with the policy, you’ve found a problem before a customer did.
What should you do the day you find a wrong answer?
Treat it like an incident, because it is one. First, stop the bot giving that answer: take down or correct the source article, or add the topic to the list it must hand off. Second, find out how far it spread. Search the conversation logs for the same question and the same wrong wording.
Then size it. Suppose the bad answer went live 14 days ago and the bot gets about 330 chats a day on that topic. That’s 14 × 330 = 4,620 conversations that could have included it. If a search shows the wrong wording appeared in 380 of them, you now know who to contact, and you can decide what to tell them. Better to tell 380 customers yourself than to wait for the first one to post a screenshot.
Write the incident down with the same discipline you’d use for any outage: what was said, how long, how many customers, what you did. The airline in this case argued its way into a public decision. A short, honest note to affected customers costs far less.
Should you tell customers they’re talking to a bot?
Yes, and make the limits obvious. A line at the top of the chat saying it’s an automated assistant, that it can make mistakes, and that the published policy page is the authority works in your favour. It sets expectations, and it shows the customer where the real answer lives.
Show the source. If the bot answers a policy question, it should link to the exact policy page it drew the answer from. Then a customer who doubts it can check in one click, and your team can see which page was used when something goes wrong.
None of this removes your responsibility, as the tribunal made clear. It does make errors rarer, visible earlier and cheaper to fix.
Who else needs to be in the room?
Support can’t own this alone. The people who write your policies, the people who build or configure the bot and a representative from legal or compliance each hold part of the answer. Put them in a thirty-minute review once a month, with the weekly sample results on the table.
Bring three things: the share of sampled answers that were wrong in a way that matters, the list of topics the bot is allowed to answer alone, and any new policy changes the bot’s content hasn’t caught up with. The last one is where many errors start. A policy changes on a Tuesday, the article is updated on Friday, and the bot gives the old answer for three days.
Keep minutes. If a customer ever disputes what the bot said, a record showing that you tested it, sampled it and fixed it promptly is a far better position than having nothing.
What would I do this month?
List every topic the bot answers. Mark the ones where a wrong answer creates an obligation. Put a name beside each. Start the 50-conversation weekly sample on the riskiest one, and review the result with the person who owns the policy. The incident I described in When the Cloud Breaks Your Customer SLA was about a promise the team couldn’t keep. A bot can make that kind of promise on your behalf, without you noticing.
The tribunal’s finding was plain. The customer shouldn’t have to wonder which part of your system to believe.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.
