AI adoption operational readiness is usually an afterthought, and it always has been. Every technology a species has ever adopted arrived the same way: a capability first, a readiness question second, and usually not asked until something had already gone wrong. Fire didn’t wait for anyone to work out how to contain it. The printing press didn’t pause for someone to decide which lies were worth stopping. What’s different now is the speed of the gap between the two. A business can add a capability to how it talks to customers this afternoon and not discover what it actually needed to be ready for it until the first customer who mattered hits the edge of what it knows.
Right now, a lot of service businesses are being told the same thing: get an AI system talking to your customers before your competitors do, or get left behind. The question almost nobody in that conversation is asking out loud is whether the business is actually ready to be represented by something that doesn’t know what it doesn’t know.
The knowledge a call needs
Start with what makes a phone call to a business valuable at all. It isn’t the fact that someone answers. It’s that the person answering has, over years, picked up the parts of the job that never made it into a manual: the customer who called at 6pm on a Friday needing an answer the standard script doesn’t cover, the edge case that used to get walked straight to a manager because nobody junior had seen it before. That knowledge is expensive to build and easy to underestimate, because most of it was never written down. It lived in the person who handled the call.
Handing a customer conversation to an AI system assumes that knowledge already exists somewhere accessible, usually a website or a folder of internal documents. It rarely does, not in the form that matters. A website describes what a business wants a customer to know before they call. A phone call is where a business finds out what the customer didn’t already know to ask, and needed a person’s judgment to answer. Pointing a model at the first thing and expecting it to handle the second is a category error, not a rounding error.
The cost of getting this wrong isn’t abstract. In February 2024, a grieving grandchild named Jake Moffatt asked Air Canada’s website chatbot whether he could apply for the airline’s bereavement fare after booking his flight rather than before. The chatbot told him yes. It was wrong: Air Canada’s actual policy required the discount to be requested before travel. When Moffatt tried to claim it afterward, the airline refused, and then argued in front of the British Columbia Civil Resolution Tribunal that its own chatbot was, in effect, a separate legal entity, not something the airline could be held responsible for. The tribunal member called that “a remarkable submission” and ruled against the airline anyway: the company owns what it said, no matter what answered the question on its own website.
That is what happens when an AI system runs out of real knowledge and nothing stops it. Faced with a question outside what they know, a person in the same position does something an AI system doesn’t reliably do on its own: they say so, they escalate, they come back with an answer instead of inventing one. Air Canada’s chatbot didn’t run out of things to say. It just kept talking, with the same confident tone whether it was right or wrong, because nothing in how it was built distinguished between the two.
What escalation requires
It’s tempting to treat that as solvable with one more feature: build an escalation path, have the AI flag anything it can’t handle and route it to a person by email. That sounds like the fix. It’s only half of one.
A person who hits the edge of what they know and reports it to someone senior gets something an email flag doesn’t reliably produce: a correction that sticks. They get coached, they carry the answer forward, and the next customer who asks the same question gets a better response because a specific person learned something specific. An email escalation can technically do the same job, but only if someone reads it, understands it, and acts on it before the moment has passed. Anyone running a business today already knows how that usually goes when there’s a backlog and a dozen other things demanding attention in the same hour. The flagged email sits in a queue with everything else competing for the same limited attention a busy operator already doesn’t have enough of. The customer waiting on the other end of it has, in practice, been quietly deprioritized rather than helped.
AI systems can certainly be built to escalate well. Escalating well, though, is itself a piece of real operational work, not a checkbox a vendor ships by default. A business that hasn’t worked out how its own people escalate an edge case they can’t handle has no functioning template to hand an AI system in the first place. The tool can only inherit whatever discipline already exists, or the absence of one.
The wrong question people are asking
Not long ago, a public exchange between a software developer and a customer of a SaaS product showed how widespread this mistake is. The customer’s argument ran roughly like this: now that AI lets companies build software faster and cheaper, shouldn’t the price of that software come down? The developer’s answer was sharper than the question expected. What makes software expensive to run, he said, was rarely the writing of the code. It was everything downstream of it: the support tickets, the onboarding, the edge cases. All of that depends on operational machinery that has to work correctly around the software for the software itself to be worth paying for. Faster code doesn’t shrink any of that.
That exchange is a small, specific version of a much bigger mistake, and it’s the same mistake most businesses make when they reach for an AI phone system, an AI chat widget, or an AI-run intake process. It’s a close cousin of a mistake this site has already named on the marketing side, where selling a channel isn’t the same as having a strategy: the tool changes, the missing step underneath it doesn’t. The assumption underneath the purchase is that the problem was technological: if only responses were faster, if only someone always picked up, the business would convert more of what comes through the door. A tool magnifies whatever it’s handed, not what its buyer hoped for. Applied to a business that already runs cleanly, automation makes the clean thing faster. An AI system bolted onto a business that has never worked out who should be handling which decision, or why a call goes unanswered in the first place, just runs the same unexamined process faster, and runs the failures inside that process faster too.
Frederick Brooks made a related argument about software itself in a 1986 essay still taught in computer science courses forty years later: “No Silver Bullet.” Brooks split the difficulty of building software into two kinds: essential difficulty, the complexity genuinely inherent to the problem being solved, and accidental difficulty, the friction a team adds on top of that through bad tools or bad process. He argued that a single technology can only clear away accidental difficulty, never the essential kind. A business’s operational mess is essential difficulty: the decision flow nobody has ever mapped, the person handling three roles because nobody separated them. An AI system is very good at clearing accidental friction, and fundamentally unable to think its way through a business that never worked out what its own process was supposed to be.
What happens with no guardrail at all
The Air Canada case is what happens when an AI system runs out of knowledge on a real customer’s actual question. A second failure mode is what happens when there’s no guardrail stopping it from being pushed somewhere it was never meant to go, and the two failure modes look similar from the outside and come from the same root cause: nobody defined what the system should do when it left the path it was built for.
In January 2024, a customer of the UK delivery firm DPD deliberately provoked its chatbot until it swore at him and wrote a poem calling its own employer “the worst delivery firm in the world.” A few weeks earlier, a customer talked a Chevrolet dealership’s chatbot into agreeing to sell an $81,000 Tahoe for one dollar, adding “that’s a legally binding offer, no takesies backsies” for good measure. Both were manipulated on purpose, not confused by an ordinary customer, and that distinction matters: it means the failure wasn’t bad luck. It was the absence of any boundary on what the system could be talked into saying. A business that hasn’t decided what its AI system is not allowed to do has, by default, decided that anything is on the table if someone pushes hard enough.
Why this matters more here than most places
This industry has less margin for this kind of mistake than most. Movaros has written before about how thin the trade coverage is for moving companies, and how much of what an operator learns about running the business comes from word of mouth rather than any serious shared body of knowledge. That isn’t a criticism of any individual operator. It’s a structural fact about an industry that has never had the kind of information infrastructure other trades built decades ago. It also means the businesses in this industry are, on average, less prepared than most to catch an AI system’s mistake before a customer feels it. The operational discipline that would catch it is exactly the kind of infrastructure this industry has historically had the least of: documented decision-making, a real escalation path, someone whose job is to notice when something’s gone wrong.
Adding a capability on top of an operation that was never built to catch its own failures compounds that gap, at the exact moment a real customer, moving their whole life, finds out the hard way.
AI adoption operational readiness is the question worth asking instead
Here is where Harari’s own observation about technology cuts the other way, and it’s worth sitting with rather than rushing past. Every one of the tools people have adopted throughout history that changed how work got done did so by removing a specific, well-understood bottleneck, not by being generally impressive. The printing press didn’t succeed because it was clever. It succeeded because it solved an exact, nameable problem: the cost of copying a book by hand. The businesses that get real value from AI right now are doing the same thing at a much smaller scale: they find the one specific place in their own operation where a machine can genuinely do something a person was doing badly or slowly, instead of reaching for the newest capability and hoping a use for it appears.
That’s the actual first-principles question, and it has to be asked at the level of the specific decision, not the department. Not “should we use AI in customer service,” which is really no question at all. Instead: walk the actual flow a customer goes through, step by step, from call to quote to booking to move day. At every single step, ask: does a person need to be making this decision, or is this a place where the decision is mechanical enough that a machine handling it frees up a person for the parts of the job a machine genuinely can’t do? Some of those steps will have a real answer. A machine reading a Business Profile correctly is a straightforwardly mechanical task worth automating, the reason the right business even gets found in the first place. A machine improvising an answer to a grieving customer’s specific, unusual question is not, and pretending otherwise is how a company ends up explaining itself to a tribunal.
Hamilton Helmer’s own habit is useful here: ask which part of the process actually compounds in value over time, and protect that part specifically, rather than optimizing everything evenly. The knowledge a good employee builds handling real edge cases compounds. It gets better the longer that person does the job. An AI system with no mechanism for learning from its own mistakes just repeats whatever it was given, faster, whether that’s a well-built process or an unexamined one, compounding nothing.
Most of what’s being sold as AI readiness right now is really just AI availability. The tool exists, so the assumption is that using it counts as being ready. That assumption is the mistake. Readiness is the unglamorous, unfinished list of internal questions that were true before any AI system existed and are still true now: who actually makes this decision today, does that person have what they need to make it well, and what happens the moment they hit the edge of what they know. Solve that first, at the level of the actual decision, and an AI system becomes a genuine multiplier on a business that already works. Skip it, and the tool just makes the gaps that were already there move faster than anyone in the business can catch them.
If you handed your worst edge-case call from last month, the one that needed real judgment, to whatever AI tool you’re considering, would it have solved it, escalated it well, or made something up? That single question is a working AI adoption operational readiness test, and most businesses currently adopting these tools have never actually run it.
Movaros routes work to operators with fundamentals already sorted.
Real escalation paths and clear decision ownership are exactly what a Movaros fulfilment partnership is built around.
