Why Most Businesses Don't See ROI from AI

Nobody buys a piano and expects the living room to fill with music. Everyone understands the instrument is the cheap part. The lessons, the teacher on the bench next to you, the practice: that is the real purchase.

AI is the first instrument businesses bought expecting it to play itself. That is the shortest honest answer to why so few businesses see ROI from AI, and the numbers behind it are blunt.

I have spent my career on the adoption side of technology, the part that begins after the purchase order clears. The pattern I watch for is always the same: usage you can see, outcomes you cannot. Right now, AI has that pattern almost everywhere.

How big is the gap between AI spending and AI returns?

Budgets keep climbing while measured returns stay flat, and abandonment is accelerating. S&P Global Market Intelligence reported in March 2025 that 42 percent of enterprises had abandoned most of their AI initiatives, up from 17 percent the year before, with nearly half of all proofs of concept scrapped before production. Bain’s June 2026 survey of 951 companies found 90 percent raised their AI budgets again anyway, even though about 40 percent of the companies that measured their savings came in under 10 percent, short of their own targets.

Every one of those surveys is chasing the same missing thing: ROI from AI that a CFO can point to on the P&L. A technology that does not work would explain the gap. Purchases that were never wired to an outcome explain it better.

Is AI itself the problem?

No. The value shows up reliably, just not where companies are buying it. The most quoted number in this conversation comes from MIT’s Project NANDA: about 95 percent of organizations investing in custom enterprise AI tools saw no measurable P&L return. The less quoted half of the same research is the interesting half. Employees at more than 90 percent of companies were regularly using personal AI tools to get work done, while only about 40 percent of those companies had bought an official one.

The music was already in the building. It just was not coming from the piano the company bought.

The same split runs through smaller companies too. Goldman Sachs surveyed its 10,000 Small Businesses alumni in early 2026 and found 76 percent using AI, while only 14 percent had fully integrated it into core operations.

Why does the piano never play itself?

Because ROI from AI was never inside the tool. It lives in the practice around the tool, and the practice rarely gets budgeted.

Boston Consulting Group’s formula for succeeding with AI puts it plainly: 10 percent algorithms, 20 percent technology and data, and 70 percent people and process. Most companies fund the 30 and skip the 70.

MIT’s researchers watched the same failure from the inside. The stalled pilots shared one trait: the tools did not learn from or adapt to the workflow. Every output still needed the judgment the tool was supposed to replace, so the hours never came back.

Inside the company, the sequence is familiar enough to sting:

1. A mandate arrives from the top: we should be using AI.
2. Licenses roll out. Usage gets tracked. Outcomes do not.
3. A few people quietly find real value. Most tick the box.
4. Renewal comes, and nobody can name a number that moved.
5. The company concludes AI does not work here, and the subscriptions stay anyway.

No step in that sequence involves a bad model. Every step involves a missing practice: no owner, no number, no feedback loop, nobody teaching the system how the work actually flows.

What do businesses that get ROI from AI do differently?

They treat AI like the instrument, and they pay for the lessons. Aditya Challapally, lead author of the MIT report, told Fortune what the successful few do differently: they “pick one pain point, execute well, and partner smartly.” Watch those companies up close and the same four behaviors show up wherever ROI from AI is real.

1. They start with one measurable workflow, not a platform. Quote turnaround. Invoice matching. The Monday report someone assembles by hand. One process, one owner, one number.
2. They name the number before anything gets built. Hours returned each week, error rate, days to close. If nobody can name the number, the project is not ready to start.
3. They teach the system how the business actually runs. Every company runs on knowledge nobody wrote down: the judgment calls, the exceptions, the reason behind the workaround. Generic tools cannot see any of it, which is why they plateau at drafting emails. Teaching means sitting beside the people who do the job, writing their exceptions into the system, and connecting it to your real data. You own everything that comes out of it: the models, the data, the pipelines, the code.
4. They put someone experienced on the bench. Students with a teacher beside them practice differently: shorter loops, honest feedback, mistakes caught the week they form. Teams adopting AI work the same way, with a senior operator embedded until the new system is routine.

Our version of that discipline is a rule we apply before any engagement begins:

If we cannot measure the outcome, we do not propose the project.

Nobody continues with us out of vague optimism. That is the point. A number named up front, captured before and read after, is what separates an AI project from one more line on the subscription report.

Where should a business actually start?

Pick the workflow that hurts every week, name its number, and get experienced help beside your team within weeks. The fastest route to ROI from AI is narrower than the vendor decks make it look: one process, one owner, one number.

That is how we run an AI Operating Partner engagement. We start from the business goal and put working software in front of your team in the first weeks, not a findings deck, then stay on the bench while the new way of working becomes routine. The people who scope the work are the people who build it, a senior team that has shipped platforms to millions of users and created more than $1M from a single AI engagement. And when a packaged tool covers the job, we say so, the same way we tell people custom software makes sense only when the process is genuinely yours.

Book a short assessment. Bring the workflow that hurts and the number you want moved. If you cannot name either yet, that is normal. Naming them is the first half hour of the call, not homework you owe us. We will scope a project you can measure, or tell you straight that you do not need us yet.

Most businesses already own the piano. They have owned it for a couple of years now. No one upgrades an instrument into music. Someone sits down next to you, and you practice one piece until it is yours. Then the next one.

Frequently Asked Questions

How long does it take to see ROI from AI?

Weeks for a first measurable result, when the scope is one workflow with a number attached. Custom software now ships in weeks, so a tight first project can show a real before-and-after inside a quarter. Broad, platform-style rollouts take years to produce a number, which is exactly why we do not recommend starting there.

Why did our AI pilot fail even though the demo looked great?

Because the demo ran on generic examples and your business runs on specifics. Off-the-shelf tools do not learn your exceptions, your data, or your judgment calls, so their output stalls at almost-right. MIT’s enterprise research found the same trait across stalled pilots: tools that never learned the workflow. Almost-right still needs a person, and the time savings evaporate.

Should we buy AI tools or build something custom?

Buy when a packaged tool covers the job with only minor workarounds. Build a thin custom layer when the process is genuinely yours, when systems need to talk to each other, or when off-the-shelf keeps fighting how you work. We regularly tell prospects to just buy the tool, and the longer answer lives in our build-versus-buy post.

How do we measure ROI from AI?

Name one metric before the project starts: hours returned per week, error rate, quote turnaround, days to close. Capture the before value, ship the smallest version that can move it, and read the after value on a set date. A project that cannot name its number up front will not produce a return you can defend later.