Motta Industries Blog

A customer asks your website a question, receives a confident answer, and spends money because of it. Later, an employee explains that the answer was wrong and points to a different page containing the actual policy. From the customer’s perspective, both answers came from your business. The technology behind the first one may matter less than you expect.

That is the practical reason to examine chatbot liability business website owners now face. The Air Canada dispute does not establish one universal rule for every country or every automated reply. It does show why a conversational interface deserves the same care as other consequential information your company publishes.

What happened, and what not to infer

In February 2024, a Canadian tribunal considered a dispute involving Air Canada’s bereavement fares. The customer had relied on chatbot information indicating a reduced fare could be requested after purchase. That conflicted with the airline’s policy. The tribunal ultimately required the airline to compensate the affected customer.

Contemporaneous reporting by the Guardian describes the airline’s attempt to distance itself from the chatbot and the tribunal’s rejection of that position. Correct information elsewhere on the website did not excuse the inaccurate conversational answer. Customers were not expected to resolve that contradiction themselves by deciding which part of the site was more trustworthy.

Keep the legal scope in view. This was a particular tribunal dispute, not a worldwide statute governing every business website. A U.S. seller should obtain qualified advice about its own duties, contracts, and jurisdiction. Nor should the case be used to assert an unverified technical story about the chatbot’s model, training, or architecture.

The operational lesson travels more easily than the legal holding: an answer can influence a decision regardless of whether it appears in a paragraph, a form message, or a chat bubble. Treat the public experience as one service rather than assuming an automated channel sits outside normal responsibility.

Identify answers that can change a customer’s position

Not all chatbot questions carry the same consequence. Opening hours and links to published information differ from promises about refunds, eligibility, delivery, warranties, or exceptions. An answer that invites someone to spend money or miss a deadline needs a stronger process than a casual suggestion about where to find a page.

Imagine a fictional equipment rental company. Its bot helps visitors locate product information and explains how to submit an enquiry. A customer then asks whether a late return will be free because the office is closed. That question crosses from navigation into a potentially consequential promise the business may not have authorized the bot to make.

Create a list of such boundaries before selecting features. Decide which questions can receive an approved response, which can point to relevant information, and which require a person. The list should reflect actual policies and operating responsibilities, not merely the categories a chatbot supplier happens to offer in a dashboard.

Discuss that scope through Motta Industries’ web development service before connecting a conversational interface to customer workflows. Custom behavior can enforce useful boundaries, but a developer still needs approved business rules. A technically successful integration is not evidence that every answer it produces is an authorized company commitment.

Give consequential information an accountable owner

Someone must approve the underlying policy, and someone must maintain its published expression. Those can be different roles. Record who can authorize an exception, who updates ordinary wording, and what happens when the bot’s source material conflicts with another part of the site. An unattended document library is not an operating policy process.

Keep relevant conditions attached to the answer. A refund rule may depend on timing, product condition, or a particular purchase route. Extracting one friendly sentence can turn a qualified policy into a promise the business never intended. A link to the full rule may help, but it does not automatically neutralize a contradictory answer above it.

Use copywriting support to make approved rules understandable without changing their meaning. Plain language should preserve important limitations, not hide them behind a cheerful summary. Where wording has legal or contractual significance, the appropriate business owner and adviser should approve it before publication.

Control changes across channels. When a policy changes, identify which pages, canned answers, documents, and conversational sources need review. Do not assume updating the visible policy page immediately changes every stored source or integration. Record the intended effective point and verify the actual customer-facing response through a supported test route.

Retrieval and disclaimers are not complete controls

Giving a chatbot approved documents can improve its basis for answering, but it does not prove every response will stay faithful to them. Relevant text may be missing, ambiguous, outdated, or combined incorrectly. The system may also answer a question that the available material does not resolve.

A general warning that the assistant may make mistakes can communicate a limitation. It should not become an excuse to leave known contradictions or invite reliance on unapproved promises. Whether particular wording affects legal responsibility depends on the circumstances and applicable law; this article does not supply a disclaimer that makes the risk disappear.

NIST’s January 2023 AI Risk Management Framework emphasizes context, evaluation, accountability, and ongoing risk management. It is a voluntary framework, not a certificate that a website assistant is accurate or legally safe. Apply its discipline proportionately to the consequences of the job the bot is being asked to perform.

For the rental company, a controlled answer might explain the published return process and route an exception question to staff. It should not invent permission, claim that a late return is approved, or imply that a submitted request has already been accepted. Keep information, requests, and authorized decisions distinguishable.

Build a genuine route to a person

A handoff is more than a button labeled contact support. Decide who receives the request, what context accompanies it, and how the customer knows what happens next. If the service is not staffed continuously, say so rather than presenting an automated acknowledgement as immediate human review.

The CFPB’s June 2023 spotlight on chatbots in consumer finance discusses inaccurate answers, repetitive loops, and difficulty reaching human help. Its financial-sector legal context does not automatically govern every small business. Its observations nevertheless highlight an important design problem: automation can make help harder to obtain when it cannot resolve the actual issue.

Test the route when the bot does not understand the question, when a customer challenges an answer, and when the topic requires authorization. Do not force the person to keep rephrasing indefinitely. Offer a clear alternative that the business can sustain, and avoid collecting more personal information than that next step needs.

Motta Industries’ UI and UX design service can help examine the interaction and handoff together. A polished chat window is not a successful support journey if the customer cannot escape it, understand the current state, or find the correct person for an unresolved question.

Test the awkward questions before launch

Use approved, invented scenarios rather than real customer records. Include missing facts, contradictory premises, expired conditions, and requests for exceptions. Ask the same consequential question in different ordinary ways. The purpose is to discover whether the experience stays within its approved role, not to produce a flattering demonstration of fluent language.

Define the expected behavior before reviewing the response. An appropriate result may be a bounded answer, a request for necessary clarification, or an honest handoff. Do not score every refusal or escalation as a failure simply because the business originally hoped to automate more conversations.

Check what the system does as well as what it says. If it can create a request, change a booking, or trigger another action, review authorization and confirmation separately. A sentence saying the task is complete must correspond to the actual system state, not merely the assistant’s confidence about what it attempted.

Keep results scoped to the conditions checked. Several correct answers do not establish universal accuracy. Changes to source material, software, configuration, or connected services can alter behavior, so decide which changes trigger another review and who can authorize release. Evaluation is part of operating the service, not just purchasing it.

Prepare for a wrong answer without rewriting history

Create an approved route for reporting and investigating consequential errors. Preserve relevant information appropriately, limit access to it, and involve qualified people when a dispute or sensitive issue arises. Do not erase a problematic conversation simply to make the dashboard look clean or circulate personal details in an unrestricted troubleshooting thread.

Separate correcting the service from deciding the customer’s remedy. Staff may need to pause an answer category, fix source material, contact affected people, or seek advice. Those decisions depend on evidence and authority. A developer should not improvise a refund policy or legal response because the error originated in website software.

When a change is made, check related surfaces rather than fixing only the example that prompted the complaint. Look for the same policy in other answers, pages, and handoffs. Record what was corrected and what remains uncertain without claiming that one repair proves the assistant can no longer make mistakes.

A practical release record can be short: the approved answer categories, the source versions reviewed, the person responsible for exceptions, the scenarios checked, and the escalation route. Make it usable by whoever will maintain the website after launch. An elaborate document that nobody consults is less useful than a clear record attached to the actual operating process.

Consider ownership during holidays and staff changes as well. If only one employee understands the policy library, a routine absence can leave outdated answers running without anyone recognizing the problem. Assign a backup and define when uncertain material should be withdrawn rather than left public while people search for its owner.

Budget for that maintenance when comparing a chatbot with simpler navigation or a structured enquiry form. The cheapest installation may create more review work than it saves. Conversely, a carefully limited assistant may reduce repetitive questions without entering areas where the company cannot reliably supervise its answers. Assess the complete service, including correction and handoff, rather than comparing the monthly software charge alone. Keep that assessment grounded in evidence.

Choose a useful role instead of maximum autonomy

A small business does not need a bot that answers everything to gain value from a conversational interface. Helping visitors locate relevant information, gather a bounded enquiry, or reach the right team may be a worthwhile role. The right scope depends on customer needs, approved policy, and the business’s ability to supervise the service.

The Air Canada story is a reason to connect automation with responsibility, not to assume every chatbot must be removed. Start with the promises your customers could act on. Give those promises an owner, make uncertainty visible, and ensure a person can handle the decisions your website is not authorized to make.