If you save a thousand employees five minutes a day, you didn't actually save them anything. You gave them five minutes of waiting for the next meeting.
That's the line I want to print on a poster and hang in every boardroom where someone is still presenting AI ROI as a multiplication problem. Five minutes per user, times a thousand users, times 250 workdays, equals 1.25 million minutes per year. The number sounds enormous. The math is fishy. Nobody actually got those minutes back.
Paul Lewis, CTO of Pythian, made the same point cleanly when we talked on Business Disruptions in Tech recently. Saving five minutes for a thousand people works out to about two full-time-equivalent weeks of recovered effort. On paper, that's a win. In practice, it's invisible. Nobody walked out of work two weeks early. Nobody finished a project two weeks earlier. The five minutes evaporated into Slack scrolls and inbox triage and "I'll just wait for the next meeting to start." There's no business outcome attached to that recovered time, because the time wasn't recovered to a place where outcomes happen.
If you can't measure blinks, you can't justify the program around them. And right now, most enterprise AI ROI decks are exactly this. They're justified in blinks.
The Other Trap, Which Is Just as Bad
The opposite instinct is also wrong, and it's wrong in a way that's harder to spot because it sounds ambitious instead of small.
This is the team that walks in with the agentic moonshot. Fifty connectors. Eighteen data sources. A self-governing agentic workflow that orchestrates five LLMs to handle the company's most complex process end to end. The pitch sounds visionary. The deck has architecture diagrams. Somebody's going to ask for a budget that has commas in it.
That project is going to disappoint everyone involved.
You're asking five non-deterministic systems, orchestrated by a sixth non-deterministic system, to produce rational ROI on a problem nobody in your organization has solved manually with any consistency. Even if you ship it, you don't have the maturity yet to tell whether it's working well or working badly. The output looks plausible. The team can't tell whether plausible is the same as right. So they declare victory or quietly walk away. Either outcome is bad.
The blink-counters are doing too little. The moonshot teams are doing too much. Both are doing the wrong thing.
The Question That Replaces Both
The right question isn't how many people will use this, and it isn't how impressive the architecture will look. The right question is which use cases will actually produce measurable value, even if only a handful of people are involved.
The unit of measurement should be hours of senior-person effort recovered, not minutes of any-person effort recovered. If you can take a two-week project off one analyst's plate, you can measure that. The analyst can prove it. The manager can verify it. The CFO can budget against it. That's an ROI conversation that survives contact with a finance review.
Twenty percent of your users can deliver one hundred percent of the value. That's not a hypothetical. That's what the pattern looks like when an organization actually commits to high-value targeting instead of broad enablement. You don't need every employee trained on every tool. You need the right small set of employees enabled on the right small set of high-leverage use cases. The training budget shrinks. The change-management problem shrinks. The result gets bigger.
How to Find the Use Cases You Can Measure
Here's where the workshop methodology has changed in the last fourteen months, and most enterprises haven't caught up yet.
The old approach was open-ended. "Tell us about your business. Tell us about your problems. Fill out this discovery template." You got back four hundred interesting ideas, almost none of them prioritized, almost none of them sized, almost none of them genuinely AI use cases. Most of them were data quality problems or analytics gaps wearing AI costumes. The workshop produced a backlog and called it a strategy.
The new approach inverts the question. Instead of asking the customer to surface their problems, you describe the patterns you've already seen succeed across other organizations and ask whether the customer recognizes them. Document digitization is one. A handwritten or scanned document gets ingested, computer vision pulls out five or six fields, the system figures out whether this is a customer record or a transaction record, the right system of record gets updated, somebody downstream gets notified. That pattern repeats across industries with minor variation.
You walk through fifteen patterns. For each one, you ask the customer where in their business this pattern shows up. Then you ask which of those instances has an accuracy problem, a speed problem, a volume problem, or requires too many people. The answers are concrete because the question was concrete. Out of every fifteen patterns, you'll surface five or six high-quality candidates. Multiply that across the patterns and you've got around a hundred genuinely viable use cases instead of four hundred noisy ones.
That's a different conversation. It produces a different roadmap. It survives the next budget cycle.
The Piano Lesson
There's a related mistake that compounds the blink-counting trap, and it's worth naming. A lot of organizations responded to the "AI for everyone" pitch by trying to teach every end user how to build their own no-code AI workflows. The intention was good. The result was bad.
Giving an end user a blank no-code AI builder is the same as giving them a blank Word document and saying "prose." Most people don't know what to do with that. They poke at it for a while, get frustrated when their first attempt produces something useless, and quietly stop using the tool. The training budget gets spent. The adoption metrics look terrible. The CFO asks why.
The better model is closer to the piano lesson. You can teach a room of people to play a simple piece on the piano in an hour. You cannot teach them to compose music in that hour, and you shouldn't try. So don't. Build the agents centrally, where the people who actually understand the patterns can build them well. Then train end users to use the agents you've built, not to build their own. They'll be happier. The agents will work better. The adoption metrics will improve.
A small number of people in your organization will want to learn to compose. Enable them. They're your future power users. But don't make composition the entry point for everyone. That's how you guarantee nobody gets past the first lesson.
Three Moves Before Your Next Use Case
Three things to do before the next AI use case lands on your prioritization grid.
Replace blink-counting with hour-counting. If the ROI math depends on multiplying small per-user time savings across a large user population, throw out the math. Find the use cases where one person gets two weeks back. Those are the use cases that will pay for themselves in a way you can defend.
Stop letting customers self-discover their AI roadmap. Walk in with the patterns you've already seen work. Ask which ones map to their business. The conversation gets sharper, the candidates get better, and the roadmap stops being a wish list.
Build agents centrally. Train users to use them, not build them. End-user no-code enablement is a strategy that sounds democratic and lands as expensive failure. The people who should be building agents are the people who understand the patterns. Everyone else should be using the agents the experts built.
Stop Spreading Thin
The blink-counting era of enterprise AI ROI is ending, and good riddance. It produced too many decks with impressive numbers and no measurable outcomes. The next phase is going to reward concentration. Fewer users. Bigger problems. Centralized expertise. Distributed value.
If your AI strategy is still being justified in minutes saved per user, you're going to get caught when somebody finally asks where those minutes went. The honest answer is that they went into the next meeting. Build the strategy that doesn't have to lie about that.