You approved the purchase eight months ago.
The demo was good. The vendor was responsive. The software does what it said it would do. The logins work, the data loads, the dashboard looks sharp. Two people on your team learned it well. Others kept the old spreadsheet open in another tab.
Then someone asks you at a board meeting whether it worked, and you hear yourself talking about adoption and change management, because you cannot answer the question.
I doubt the vendor caused the outcome, and I doubt your team did either. The failure was already in place before you sat through the demo, and it will repeat with the next tool.
The question that stopped the conversation
I was on a call recently with the COO of a services company I have worked with for years. Good operator. Hands in every part of the business.
We were deep in build versus buy on a performance management tool. His team does them, they have always done them, and the process hurt enough that he wanted software to fix it. Third-party platform against a custom build, per-seat costs, timelines, what each option would and wouldn’t cover.
Then he stopped and said to his CIO, roughly: imagine today we said we’re not doing performance reviews anymore. We’re done. We’re never doing them again. What would happen to the company?
He offered it as a thought experiment, almost an aside. Nobody on the call had a clean answer.
That question ended the software conversation. I have started calling it the stop question, because of what it exposes: if you cannot say what breaks when a process disappears, you do not yet know what the process is for. And a tool cannot improve a process whose purpose nobody has written down. It can only make it faster and better looking.
He is doing the internal work now, before we build anything.
Sixty, thirty, ten
The ratio I use for this belongs to Jake Van Clief - Clief Notes, who calls the broader discipline computational orchestration. His version is technical: in an AI implementation that works, about 60% is ordinary database queries, 30% is rule-based logic, and 10% is AI doing work only AI can do. In his words: “The 10% makes the whole thing feel intelligent. The 90% makes it actually work.”
The same ratio holds for an operator who does not build software, with different contents in each slot.
Sixty percent is what’s true, written down. True about your business, your data, your people, and what the thing you are automating exists to do. Where the numbers live and why they exist. A written answer to what is this for, and what breaks without it.
What goes in that slot changes with the system. If the system touches the market, whether messaging or campaigns or sales, the 60% is customer truth, and everything built on top of it inherits whatever you got wrong. Performance reviews are internal, and the customer has nothing to do with them. There the truth that has to be written down is about the business and the people inside it.
Thirty percent is process. Who does what, in what order, and what happens when it goes sideways. The decisions your people currently make in their heads, made explicit enough that two employees would make the same call on the same day.
Ten percent is the tool. The interchangeable layer. We spent a month weighing a platform against a custom build: three one-hour calls, multiple discovery documents. Both answers were the 10%.
The number you have seen quoted
You have likely run into the statistic that 95% of AI efforts fail.
It comes from a July 2025 report by Project NANDA, a research initiative at MIT, titled The GenAI Divide. Against $30 to $40 billion in enterprise investment, 95% of organizations were getting zero measurable return. That is a different claim, about organizations and return rather than efforts and failure. An effort can be running fine and still show nothing on the P&L, so zero return is a stricter test than failure.
A second measurement in the same report tracks how far efforts got before they stalled, and I find it more useful. Among organizations weighing custom or vendor-built AI tools, six in ten investigated a tool, two in ten ran a pilot, and one in twenty put one into production. This is a survival rate through a build rather than a count of who saw a return.
The paper is preliminary, and the authors state plainly that it represents their views rather than an institutional position. In their limitations section they also note their six-month observation window may be too short, and could understate how many efforts eventually succeed.
So the number is contested. I would not build an argument on it. My client could not say what his performance reviews accomplish. It is hard to say whether AI is working across the economy for the same reason. You cannot measure return against a purpose nobody wrote down.
The causes hold up better than any of the percentages, and two separate research groups describe the same failure without either one arriving at 60/30/10.
RAND studied AI project failure in 2024 across sixty-five interviews with data scientists and engineers who each had at least five years building these systems. Their headline result is that leadership and problem framing cause more AI failures than the limits of the technology do. They name five root causes: stakeholders misunderstand or miscommunicate the problem, organizations lack sufficient quality data, teams chase cutting-edge capability instead of the user’s actual problem, the infrastructure for managing data and deploying models isn’t there, and AI gets pointed at problems beyond what it can currently do.
Three of those five are 60% failures: the problem was never framed, the data was not good enough, the plumbing for that data was not in place. The other two describe buying the 10% first, or pointing it at a job it cannot do.
The NANDA researchers arrive at the same place from another direction. The failures they observed came from brittle workflows and misalignment with day-to-day operations, which is the 30%, and from systems that never learned the context they were dropped into, which is the 60%. They write that the divide is determined by approach, not model quality, and that the core barrier is not infrastructure, regulation, or talent. They are describing enterprise readiness in the broad sense. RAND’s infrastructure finding is narrower and points at data plumbing.
Four questions before the next purchase
The sixty percent question. This is the stop question. If we stopped doing this tomorrow, what would break? Answer out loud, with a specific consequence attached. If the room goes quiet, you have a problem to define before you have anything to automate.
The thirty percent question. If two of your people hit the same situation on the same day, would they make the same call? If not, the process lives in someone’s head, and it leaves when they do.
The ten percent question. Does the job you are handing this tool require understanding meaning, like reading a transcript, judging tone, or weighing a tradeoff? Or could a spreadsheet formula and a working integration do it? If it’s the second one, you are buying expensive automation and you will feel it at renewal.
The fourth question. The first two only work when a process is already running: one asks what would be missed if it stopped, the other how it is run today. A pilot for a capability you do not have has no such history, so ending it tomorrow costs you nothing you can point to. Ask the question forward instead: if this succeeds exactly as intended, name the specific thing the business can do next year that it cannot do today. If the room only has enthusiasm and no named capability, you don’t yet have grounds to fund it.
What survives the tool
The 10% is the only layer you can buy. It has a demo and a price, and writing the check feels like progress. I have never seen the 60% or the 30% arrive with a purchase order. Those get excavated out of your own business by people who already know it, and that work is slow.
Written down, the 60% and the 30% survive a change of vendor.
Ask the stop question about a process you are automating this quarter. If nobody in the room can answer it, start there.