A chatbot made up a refund policy. The company still had to pay

A chatbot gave a customer the wrong refund instructions. A tribunal held the company responsible for the answer.

If you have a bot on your website, that is the part to remember.

In November 2022, Jake Moffatt needed to travel after the death of their grandmother. While researching an Air Canada flight, they asked the airline's website chatbot about bereavement fares.

The chatbot said a customer could book the flight and apply for the reduced fare afterward, within 90 days of the ticket being issued. Moffatt followed those instructions and later requested the partial refund.

Air Canada refused. Its official bereavement policy said the discount could not be requested after travel was completed.

The chatbot had given one answer while another page on the same website gave the opposite answer.

The argument the tribunal rejected

Moffatt brought the dispute to the British Columbia Civil Resolution Tribunal.

Air Canada argued that it could not be held responsible for information provided by its chatbot. Tribunal member Christopher Rivers described the position as a remarkable submission. He wrote that the chatbot was part of Air Canada's website and that the airline was responsible for the information on that website.

The tribunal also rejected the idea that the customer should have known which page to trust. A business cannot publish two conflicting answers and place the burden of resolving them on the customer.

The tribunal found that Air Canada had not taken reasonable care to ensure the chatbot's information was accurate. It awarded Moffatt C$650.88 in damages, C$36.14 in interest, and C$125 in tribunal fees, for a total of C$812.02.

This was a Canadian civil tribunal decision, not a ruling from a higher court, and it is not automatically binding in other places. It is still a useful operating lesson for any business putting automated answers in front of customers.

Your bot is not an independent employee who carries its own responsibility. To the customer, it is your company speaking.

The real failure was not one bad sentence

The incorrect answer was the visible problem. The system around it had deeper weaknesses:

1. Two parts of the same website gave conflicting policy information.
2. The bot could state an eligibility rule without verifying the current policy.
3. The answer sounded actionable enough for a customer to spend money.
4. The customer was not moved to a person before making a high-impact decision.
5. The business did not catch the conflict before the customer relied on it.

Adding a disclaimer that "AI can make mistakes" would not solve those problems. A customer-facing bot needs limits, current sources, testing, and a recovery path.

Step 1: Decide what the bot is allowed to answer

Do not begin by uploading every document and telling the bot to answer everything.

Create three groups of customer questions.

Low-risk questions

These include opening hours, office locations, product descriptions, and basic navigation. The bot can usually answer directly from approved content.

Controlled policy questions

These include refunds, cancellations, eligibility, pricing exceptions, warranties, and service terms. The bot should answer only when it can retrieve a current, approved policy passage that directly supports the response.

Human-only decisions

These include complaints, unusual exceptions, disputed charges, legal threats, vulnerable customers, and decisions that require judgment. The bot should collect the minimum information and transfer the conversation to a trained person.

Write this boundary before selecting the model. It defines the product more clearly than a long system prompt.

Step 2: Create one approved source for each policy

The Air Canada case involved conflicting information on the same website. That is a content-governance failure before it is an AI failure.

For every policy the bot may discuss, store:

• The approved policy text
• The policy owner
• The effective date
• The version number
• The countries, products, or customers it applies to
• The approval record
• The date it must be reviewed

Do not let the bot treat old help articles, marketing copy, internal notes, and current policy as equally trustworthy.

When two approved sources conflict, the bot should stop. It should not choose the answer that sounds most likely.

Step 3: Make the bot retrieve before it answers

For policy questions, require a successful search against the approved knowledge base before the model can respond.

A safe response path looks like this:

1. Classify the customer's question.
2. Identify the relevant market, product, date, and customer type.
3. Retrieve the current approved policy passage.
4. Check that the passage directly answers the question.
5. Generate a short answer that stays within that passage.
6. Show the policy link and effective date.
7. Escalate when the evidence is missing or unclear.

If retrieval returns nothing, the bot should say it cannot confirm the answer and offer a human handoff. A missing answer is safer than an invented promise.

Step 4: Separate information from commitment

A chatbot answer can change what a customer does. The risk becomes higher when the bot discusses money, eligibility, deadlines, or irreversible choices.

Design two levels of output:

• Information explains the published policy and links to the source.
• Commitment approves a refund, changes a booking, grants an exception, or creates a binding outcome.

The model may help draft information. A rules engine or authorized person should control commitments.

For example, the bot may explain the standard cancellation window from an approved policy. It should not promise an exception unless the business system has confirmed that exception and recorded the approval.

Step 5: Build escalation into the conversation

"Contact support" is not a handoff if the customer must start again.

When the bot reaches its limit, pass the agent:

• The customer's question
• The relevant account or booking reference
• The policy passages retrieved
• The answer the bot considered
• The reason it stopped
• The conversation history needed to continue

Tell the customer what will happen next and how long the normal response takes, if your business has an approved service target.

Do not invent a response time just to make the handoff sound better.

Step 6: Test the questions that can cost you money

A demo usually tests easy questions with clean wording. Customers do not speak like a demo.

Build a test set from real support history with personal information removed. Include:

• Normal questions
• Misspellings and short messages
• Questions that mix two policies
• Old policy language
• Requests made just before and after a deadline
• Customers in different markets
• Requests for exceptions
• Questions where the correct answer is "I cannot confirm that"
• Two source documents that contradict each other

For every test, record the approved answer, required source, risk level, and whether a human handoff is required.

Do not score only whether the response sounds helpful. Measure whether it is supported, current, correctly scoped, and safe to act on.

Step 7: Test every policy change before publishing it

When a policy changes, the chatbot changes too, even if nobody edits the prompt.

Use a controlled release process:

1. The policy owner approves the new version.
2. The old version receives an end date.
3. The knowledge index updates.
4. Automated tests run against the changed policy.
5. A person reviews high-risk answers.
6. The new version goes live.
7. The team confirms that the chatbot cites the new source.

Keep the previous version and release record. If complaints arrive, you need to reconstruct what the bot knew and said at that time.

Step 8: Log enough to investigate a complaint

For customer-facing policy answers, record:

• The customer's question
• The policy version retrieved
• The source passage used
• The final answer
• The model and workflow version
• Any tool calls or rule checks
• The confidence or support status
• Whether the customer clicked the source
• Whether the conversation reached a person

Protect these logs under your privacy and retention rules. Do not collect more personal information than the investigation requires.

The purpose is simple. If a customer says, "Your bot promised me this," your team should be able to verify the conversation without guessing.

Step 9: Monitor the bot after launch

Track problems that reveal risk, not only conversation volume.

Useful measures include:

Measure

What it reveals

Unsupported-answer rate

How often the bot answers without an approved source

Escalation rate

How often questions need a person

Policy-conflict rate

How often retrieved sources disagree

Correction rate

How often staff change the bot's answer

Complaint rate

How often customers dispute chatbot information

Repeat-contact rate

Whether the first answer solved the problem

High-risk accuracy

Performance on refunds, eligibility, deadlines, and pricing

Review examples, not only percentages. A low error rate can still hide one expensive promise.

Create a kill switch for a policy topic. If refund answers begin failing, the business should be able to disable that topic and send customers to a person without removing the whole chatbot.

Step 10: Give one person clear ownership

A chatbot sits between product, customer service, legal, compliance, and technology. Shared involvement is useful. Shared ownership is not.

Assign one accountable owner for:

• Approved topics
• Policy freshness
• Evaluation results
• Incident response
• Complaint review
• Release approval
• Human escalation performance

That owner does not write every policy or fix every technical problem. The owner makes sure someone does.

The production checklist

Before putting a chatbot on your website, confirm:

• Every answerable policy has an owner and review date.
• The bot searches only approved customer-facing sources.
• Old policy versions cannot appear as current rules.
• Conflicting sources cause a stop or escalation.
• Refunds, eligibility, pricing, and deadlines receive stricter handling.
• The bot shows the supporting policy link.
• Missing evidence produces uncertainty, not invention.
• Financial commitments require deterministic checks or human approval.
• The handoff includes context so the customer does not repeat everything.
• Real support questions are included in testing.
• Policy changes trigger regression tests.
• Conversations can be reconstructed from protected logs.
• High-risk accuracy and correction rates are monitored.
• Individual topics can be disabled quickly.
• One named person owns the system.

The rule to remember

The tribunal did not accept the idea that one part of a company's website could give false information while another part quietly held the correct answer.

Your customers should not have to investigate which version of your business is telling the truth.

If your bot speaks on your website, treat its words like your words. Give it approved sources, narrow authority, visible evidence, and a human path when the answer matters.

Want help building a safer customer chatbot?

If you want a service, contact me directly, and I'll help you with that.

Sources

• Moffatt v. Air Canada, 2024 BCCRT 149, CanLII
• American Bar Association summary of the tribunal decision
• McCarthy Tetrault analysis of Moffatt v. Air Canada

This article discusses an operational lesson from a Canadian tribunal decision. It is not legal advice.