Motta Industries Blog

A chatbot can be polite, quick, and completely unhelpful. The customer explains a problem, receives an irrelevant answer, tries different words, and returns to the same menu. Nothing in the conversation tells them how to reach someone who can actually deal with the issue. The business may count an automated interaction while the customer experiences a locked door.

That is the problem behind a chatbot human handoff: not merely adding a button, but making sure automation stops being the only available route when it cannot help. Regulatory concerns and a recent Canadian tribunal case offer useful warnings, provided their different legal contexts are kept clear.

For a small business considering website chat, the sensible question is not whether the bot can answer a demonstration prompt. It is what happens when a real customer’s problem does not fit.

What the banking regulator actually warned about

The CFPB’s June 2023 issue spotlight on chatbots in consumer finance describes customers encountering repetitive, unhelpful responses without an offramp to a human representative. It calls these situations doom loops and explains that problems outside a chatbot’s limited capabilities can prevent a necessary conversation with the financial institution.

The report also discusses inaccurate information, difficulty recognizing a consumer’s situation, and barriers to timely human intervention. Those are significant concerns in financial services, where a question or dispute may involve particular rights and obligations. The report is not a general law requiring every retailer or workshop to operate a particular kind of chat service.

A complaint is not the same as a request for another product description. Decide how the business recognizes that distinction and directs it to the appropriate process. Where a matter may involve important deadlines or specific legal rights, obtain suitable advice about handling it. Do not let a generic satisfaction survey silently replace the route for raising the underlying concern.

The transferable lesson is narrower and more practical: a customer-service system should not treat the failure of its automated path as the end of the customer’s opportunity to seek help. Before introducing chat, identify which questions it can answer reliably and which situations require another route. A confident tone does not expand the system’s actual authority or competence.

Do not turn the banking context into a marketing claim that a generic chat widget is regulator-approved. Equally, do not dismiss the service problem simply because your business is not a bank. The distinction is between legal duties that require context-specific review and an observable design failure: a person has a legitimate question, the automation cannot answer it, and no workable alternative is offered.

A tribunal case shows why accurate pages elsewhere may not be enough

In February 2024, CBC reported on Air Canada’s chatbot case. A passenger relied on advice about applying for a bereavement fare after travel, while another part of the airline’s website described a conflicting restriction. The British Columbia Civil Resolution Tribunal found the airline responsible for the inaccurate information in that dispute.

CBC also described the airline’s attempt to characterize the chatbot as a separate legal entity responsible for its own actions. The tribunal member called that submission remarkable and treated the chatbot as part of the airline’s website. For an owner evaluating a tool, this is a reason to ask who approves its statements and handles errors, rather than treating automation as an independent speaker outside the business.

The important operational point is not the size of the award. It is the contradiction between the chatbot and the company’s other information. As the reported decision explained, the passenger should not have to know that one part of the website was trustworthy and another was not. A link to a correct policy did not make the conflicting answer harmless.

This was a specific Canadian small-claims tribunal decision, not a universal rule resolving liability for every chatbot in every jurisdiction. Businesses need appropriate advice about their own circumstances. They should nevertheless be cautious about assuming that a supplier, disclaimer, or separate policy page automatically removes responsibility for customer-facing statements made on their site.

Notice the customer’s task in that story: deciding what to buy based on information about a later request. An inaccurate answer can shape a decision before any complaint exists. An escape route therefore matters before purchase as well as afterward. Important conditions should be available at the point of decision, and uncertain eligibility should be referred for confirmation rather than presented as settled.

Do not assume the case proves anything about every modern language model either. The lesson concerns the information a business presents and the customer’s reliance, not a benchmark comparing chatbot technologies.

Identify the moment when continuing the conversation becomes obstruction

Consider a fictional appliance repair shop. A bot can explain how an initial service request works, but a customer asks about a disputed charge or an exception to an existing arrangement. Repeating the standard service description does not answer that question. The business needs a route to someone with the relevant authority.

Recognize explicit requests for a person, repeated failure to understand, contradictory policy information, and issues outside the approved scope. The customer should not have to discover a special phrase or deliberately provoke an error before another option appears. Treat these signals as reasons to change the service path, not as opportunities to restate the same answer more enthusiastically.

A visible alternative can exist before a failure happens. People may prefer another channel, need assistance using the interface, or know that their issue requires judgment. Motta Industries’ UI and UX design work can help place understandable help routes within the customer’s actual journey rather than hiding them behind the chat window’s smallest control.

Avoid making the alternative conditional on another irrelevant questionnaire. If identity verification is genuinely needed for a private matter, explain that requirement and use the approved process. Do not use it as a general barrier to asking a service question. A customer who cannot complete the automated classification should still understand how to request suitable assistance without repeatedly proving that the bot has misunderstood.

An escape hatch must lead somewhere real

A button labeled contact a person is misleading if it only starts another automated loop. Establish where the request goes, who receives it, and what the customer should expect. If the business offers a callback request rather than live assistance, say that clearly. Do not promise immediate staffing that does not exist.

Keep the alternative usable when the chat service is unavailable. A business-controlled contact page or approved telephone route can provide resilience, but only if the details are current and someone owns the receiving process. A phone number that no longer reaches the relevant team is not a meaningful escape hatch.

The fixed October 2023 WCAG 2.2 recommendation includes consistent help and keyboard-operation criteria. These provide useful reference points for reviewing access to assistance. A help control should not depend solely on precise mouse use, and repeating help mechanisms should remain predictably located where the relevant criterion applies. One improved button does not establish full accessibility conformance or legal compliance.

Consider people using smaller screens, enlarged text, or assistive technology. If the chat panel covers the only alternative contact information, the nominal escape route may not be practically available.

Keep policy answers within a named source of authority

The Air Canada example makes content ownership especially important. Identify which approved source governs each kind of answer and who can change it. A chatbot should not improvise refund, cancellation, eligibility, or service exceptions merely because a customer asks persuasively. Where a matter requires review, the answer should direct the customer to the actual process.

Ask a prospective supplier how a known incorrect answer can be contained while the underlying material is corrected. Who can restrict the topic, change the response source, or temporarily remove the automated route? What information does the business need to review the problem? Those are procurement and operating questions, not a request to accept a vague assurance that the model will learn from feedback.

When policies change, review the chatbot’s material alongside public pages and staff instructions. A corrected page does not necessarily update every answer source automatically. Record which material has been reviewed and which responses remain outside scope, instead of assuming that the tool always discovers the newest version.

Motta Industries’ copywriting work can help make policy language and escalation instructions understandable. Clear writing should reveal important conditions, not turn a conditional possibility into a promise. If two approved sources disagree, resolving that conflict is a business decision; the bot should not choose whichever wording produces the most fluent reply.

Preserve the useful question without creating another privacy problem

When a customer changes channels, avoid making them repeat information unnecessarily. Provide an appropriate way to carry the issue forward, subject to the business’s actual privacy and handling requirements. The receiving person needs the customer’s stated problem and relevant context, not an indiscriminate export of every conversation detail.

Explain what information is being requested and why. Do not encourage customers to enter passwords, payment details, or sensitive documents into a general chat box simply because that is convenient for the workflow. A human route also needs suitable handling; replacing a bot with an unprotected inbox does not resolve the underlying responsibility.

Let the customer correct a mistaken summary. The bot’s interpretation should not become an unquestionable account of what happened. If the conversation concerns a disagreement, the receiving team should be able to distinguish the customer’s statement, the automated answer, and information that has actually been verified.

Review failures as service evidence, not just abandoned sessions

Before launch, use approved fictional scenarios to examine questions the bot should not answer, requests for a person, conflicting instructions, and unavailable receiving staff. Check whether the customer can find a real alternative and whether the business understands the resulting request. A successful greeting and one correct FAQ answer are not a sufficient review.

Read the wording of failure responses too. Apologizing repeatedly while offering the same unusable menu can make a loop feel even more dismissive. The message should identify the practical limitation and the actual alternative. It should not blame the customer for asking incorrectly or imply that a human has joined when the conversation is still automated.

Afterward, investigate repeated loops and unresolved issues through an appropriate privacy-conscious process. Fewer human contacts do not necessarily mean better service: some customers may simply stop trying. Look for whether people reach suitable assistance and whether recurring misunderstandings are corrected. Do not claim a measured service improvement from interaction counts alone.

Motta Industries’ web development work can be scoped around these boundaries, receiving routes, and content responsibilities. The goal is not an endless conversation that appears productive. It is a service path that gives useful answers where possible, admits limits where necessary, and leaves customers a genuine way forward.