Curb Your Enthusiasm

Air Canada’s chatbot and the case for rigour

In February 2024, a man named Jake Moffatt asked Air Canada's website chatbot about bereavement fares after his grandmother died. The chatbot told him he could apply for a reduced fare within 90 days of booking, even if travel had already been completed. 

The thing is, that was wrong. 

Air Canada's actual policy, published elsewhere on the same site, required the bereavement application before travel, not after. Moffatt booked full-price tickets on the chatbot's advice, then submitted a refund claim. 

Air Canada refused. Moffatt took them to the British Columbia Civil Resolution Tribunal.

Air Canada's defence was that the chatbot was "a separate legal entity, responsible for its own actions." The tribunal member called this submission remarkable. A chatbot is part of a website, he found, in the same way a static page is. The airline owed its customer accurate information regardless of which part of the site delivered it, and it was ordered to pay.

As humans, air-travellers, website-navigators, and chatbot users, there’s a lot to scoff at in this story. However, as the people who work behind the scenes to develop software, tools, and other initiatives that engage users with businesses, we start to look deeper. For example, where Air Canada tried to argue for some sort of independence for their chatbot, we know the failure sits not with a sentient AI, but with the people and process involved well before it went live on the web. The genesis of an idea like this is usually seeded in someone’s enthusiasm: “Everyone has a chatbot. We need a chatbot.” The problem is, someone, somewhere in that project, should have asked what happens when a customer trusts an answer that turns out to be false, and what it costs the business when they do. 

Asking those questions early is like running a pre-mortem - imagining that you’ve failed before you’ve even begun. But a process like that takes time. Even without the process, questions like that get skipped simply because they delay the launch date. Discovery that tests for failure takes longer than discovery that confirms the happy path.

Air Canada simply launched the version that was quicker to build, and then put faith in the technology to overcome their haste.

Enthusiasm isn’t literacy

Most conversations about AI mistake enthusiasm for literacy. Think about the chats you’ve had in the office, the questions you ask.

Can you use the tools?
Have you tried the latest model?
Do you have a favourite prompt? 

None of these say much about whether someone understands what those tools can be trusted to do. There’s an enthusiasm, a bleeding-edge desire to try the next new thing and be able to say you have. 

Literacy just isn’t all that sexy, but it is necessary.

Real literacy is knowing where a model's competence runs out, and building for that boundary rather than around it. A generative model will answer almost any question put to it, with the same fluency whether the answer is right or invented. It doesn't flag its own uncertainty in a way you can rely on. The Air Canada chatbot didn't pause, qualify, or refer the question elsewhere. It answered with certainty, as if it were the single source of truth on the policy. In fact, the source of truth for the policy was, well, unsurprisingly, the policy.

The Air Canada chatbot’s confident response is also what enthusiasm sounds like. An enthusiastic advocate for a tool doesn't flag uncertainty either, because what excites them is the tool itself rather than what it's supposed to produce. Put an ungoverned model in front of a team that's excited about it and the room ends up with two confident voices instead of one, each reinforcing the other. Nobody asks what happens when the tool is wrong, because nobody in the exchange is built to raise the question. Confusing enthusiasm with literacy matters for exactly this reason: enthusiasm carries the same blind spot the model has, rather than covering for it. 

This is where the BA sits. 

Requirements and discovery work is exactly the point in a project where someone has to ask what a system needs to get right, what it's allowed to get wrong, and what happens when it gets it wrong. A language model raises that question as much as a database does. If anything it gets more urgent, because a broken database throws a visible error, while a confidently wrong chatbot gives an answer many people simply won't check.

Literacy isn’t rigour

To be fair, nobody on the Air Canada project needed deep AI literacy to catch the gap before launch. They needed someone whose job it was to keep asking what happens if this answer is wrong, past the point where the rest of the team wanted to move on. That's what a BA brings to a project before it's anything to do with systems or technology: the willingness to challenge an assumption everyone else has accepted, and to go looking for the edge case a delivery team under deadline pressure would rather not find.

Of course, none of this is free. Rigour costs up front, enthusiasm doesn't, and a launch date doesn't care much for more time and more money. The problem is, the real cost shows up later, when it becomes obvious all the enthusiasm in the world couldn’t navigate complexity and ambiguity without rigour to support it.

That's the real value of BA rigour against an enthusiasm-driven rollout. Enthusiasm wants to launch the thing that worked in the demo. Literacy, on its own, still assumes someone in the room understands enough about the model to know where it will fail. A BA doesn't need that understanding to be useful. They need the habit, built over years of ordinary requirements work, of treating every "usually" as an unfinished sentence, one that has to specify where it breaks and what it costs when nobody notices. Those questions work on a chatbot the same way they work on a manual process or a legacy system, because they aren't questions about the technology. They're questions about consequence, consequence doesn't change shape just because the technology behind it changed.

Rigour is how the gap between literacy and enthusiasm is bridged. Both sides have a role to play, but without the bridge, they collapse. A BA doesn't need to arrive at an AI project already fluent in the technology. They need to arrive willing to ask the question nobody else wants to slow down for, and to keep the project honest until the answer holds up.

Air Canada found out what happens when nobody asks that question, and it’s a lot worse when you find that out through a tribunal instead of a requirements workshop. 

‍

Jamie is Redvespa's Head of Experience. At a recent Redvespa session, a participant's observation stuck with him: AI implementation needs to listen to the people who oppose its use, bring them into the process, and use that opposition to build more sustainable, inclusive systems. That opposition is often grounded in a literacy that goes beyond the enthusiasts' own. The strength of the human in the loop, however, is the ability to apply rigour regardless of position.