You Bought a Tool When You Needed a Workflow Change
The version I've watched most often runs roughly like this. Someone senior gets excited about AI. A tool gets purchased, usually a good one. A pilot kicks off with real enthusiasm. A couple of months later, a handful of people are using it occasionally, nobody can say whether it's working, and by the next budget cycle it's quietly gone. The postmortem, if there is one, concludes that "the team wasn't ready" or "the tool wasn't quite right."
Neither is usually true. The tool was fine. The team was fine. What failed was the thing nobody owned: the workflow.
The fastest way I know to keep your organization out of that story is three questions, asked in writing, before you evaluate a single vendor. They take an afternoon and they'll save you a quarter. Here they are; the rest of this piece is why each one exists.
The three questions
1. What will we stop doing when it works? This is the question that kills a bad purchase in ten seconds, and it's the only one you can answer without any preparation. If the answer is "nothing, people will just have the tool available," stop here. You're about to buy shelfware. The honest answers sound like: we stop hand-building the Monday report, we stop routing every request through the one person who knows, we stop the Thursday sync because status is now visible. If nothing stops, nothing changed, and nothing changed is exactly what your last stalled initiative delivered.
2. Which specific workflow, and what does it cost us today? Not "customer service." The daily triage of vendor emails, the weekly status report assembly, the intake of new work orders. Pick something that happens frequently, follows a rough pattern, and annoys the people who do it. Then put a number on it: hours per week, or days of cycle time. That number is your baseline, and it's the only thing that will tell you later whether this worked.
3. Who owns the change, and can they retire the old way? One name. If that person can introduce the new step but can't remove the old one, they're set up to fail, because the pilot will run as a parallel option and parallel options lose. Give the owner both halves of the job.
Notice that none of these questions is about AI. That's the point, and it's why they work.
Why the first question exists: the tool-first mistake
The default way organizations approach AI is tool-first. We should be using AI, so which tool should we buy? It feels like progress because there's a decision to make, a vendor to evaluate, a line item to approve. Procurement is a familiar motion, so that's the motion teams run.
But AI doesn't create value at the moment of purchase. It creates value at the moment a specific piece of work happens differently: an intake that used to take twenty minutes takes two, a report that someone assembled by hand assembles itself, a question that used to require finding the one person who knows now gets answered from the documents you already have. That's a workflow change, and workflow changes are a different project than tool purchases. They have an owner, a before-and-after, a specific group of people whose Tuesday looks different. When you start tool-first, you skip all of that and hope it self-organizes. It almost never does.
I know this pattern from the inside because I watched the previous version of it for a decade. Companies bought SharePoint and Teams licenses for everyone, announced them, and then wondered why people were still emailing attachments two years later. I built a career, and wrote six books, inside that gap between license and adoption. The licenses were never the adoption. The adoption was somebody redesigning how a document actually moved through the company, and that part rarely had a name attached to it. The AI version of this story is the same story with a larger invoice, which is why the first question is about stopping something: it forces the workflow change into view before the purchase, instead of hoping it appears after.
Why the other two exist: how pilots actually stall
When an AI pilot dies, it usually dies of one of three deficiencies, and often all three at once. The questions are their antidotes.
No owner. Not a sponsor; sponsors approve budgets. An owner is the person whose job it is to make one workflow work differently, who has the authority to change the process and the obligation to report whether it's better. If you can't name this person, you don't have a pilot. You have a subscription. Question three exists to force the name.
No changed process. The tool gets introduced alongside the existing way of working instead of replacing a step in it. Using the AI is optional, the old path still exists, and under deadline pressure everyone takes the path they know. Optional new tools lose to mandatory old habits every single time. A real pilot retires something (a form, a manual step, a status meeting) so the new way is the way. Question one exists to write the retirement list before the money moves.
Wrong measurement. Teams measure novelty: logins, messages sent to the chatbot, "engagement." Those numbers always look decent in week two and mean nothing. The only measurements that matter are operational. Hours recovered, cycle time shortened, error rate reduced, backlog cleared. If the pilot wasn't set up to capture a before-number, no after-number can save it, and the renewal conversation becomes a vibes debate. Question two exists so the before-number is on paper while the old way still exists to count.
Start smaller than feels impressive
The instinct, especially with executive attention on AI, is to launch something visible: a big platform, a company-wide rollout, a transformation initiative with a deck. Resist it. The big ones are the ones I've watched fail, and they fail precisely because they multiply the three deficiencies across many workflows at once.
The alternative is almost embarrassingly modest: one workflow, one owner, one baseline number, thirty days, and a decision at the end. Expand it, fix it, or kill it. Shipped small things compound. A team that has genuinely automated its report assembly believes the next project is possible, and now you're building on trust instead of spending it.
That's not a less ambitious path to AI adoption. It's the only one I've seen actually arrive.
I help operations teams answer the three questions and make the change stick. First conversation is a working session, not a pitch. Get in touch.