A Faster Task Doesn't Mean a Faster Business

Many AI business cases rest on a simple calculation. If a tool reduces the time needed for a task from 30 minutes to 5, the savings are estimated by multiplying the 25 minutes saved by the annual volume of that task. The calculation is easy to defend, and the time savings are usually real. The difficulty is that the task is only one step in a longer process, and customers and financial results depend on the performance of the whole process.

When a drafted response, a summarized file or a classified document moves to the next step, it typically enters a review queue, an approval, a compliance check or a handoff to another team. If one of those later steps is the real constraint, speeding up the earlier task does not shorten the overall cycle time, because the work simply waits longer at the next step. The principle is familiar from airport security, where a faster scanner does little to shorten the line if passengers are still waiting to unload and reload trays.

Three mechanisms explain why task-level gains so often fail to show up in business results.

The constraint moves elsewhere in the process

The first is the bottleneck effect that Eliyahu Goldratt described in The Goal in 1984. In any process, the slowest step sets the pace, and time saved at other steps does not increase output unless the bottleneck also improves.

AI tools frequently speed up steps that were not the bottleneck. In a 2022 controlled experiment by GitHub researchers, developers using the Copilot coding assistant completed a programming task 55 percent faster than those without it. That is a significant gain, but software still has to be reviewed, tested, secured and deployed. If review and testing were already at capacity, faster coding lengthens the queue in front of them rather than increasing the rate at which finished software reaches users. Similar patterns appear in financial services: fraud alerts generated faster but still worked by investigators in the same order, replies drafted instantly but held for the same approval, and cases routed more quickly to teams that lack the capacity or the authority to handle them differently.

Automation leaves people with the harder cases

The second mechanism concerns exceptions. Consider a typical document-intake operation, drawn as a composite from several programs I have worked on. A model classifies incoming documents with 94 percent accuracy in testing. In production, documents arrive by mail, fax, email and online portal, some are poorly scanned or incomplete, and some require judgment because the correct handling depends on context. The model handles the standard cases well, but the backlog falls only from about nine days to eight and a half, because most of the backlog consisted of exceptions.

Once the model takes over the standard cases, the people who remain spend nearly all of their time on the difficult ones, along with the checking and follow-up the model cannot do. The psychologist Lisanne Bainbridge described this effect in her 1983 paper "Ironies of Automation": automating the easier parts of a job leaves operators with the harder parts, while giving them less routine practice to maintain their skills. Aviation has long designed training and procedures around this problem. Many AI business cases still assume that removing the easy work will make the remaining work lighter, which is often not the case.

Saved time is absorbed unless someone redirects it

The third mechanism is the most common reason savings fail to reach the financial statements. Time saved by AI becomes value only when someone decides how it will be used: to handle growth without adding staff, to take on work that was previously neglected, or to reduce costs. Without that decision, it tends to be absorbed by other activity, much as C. Northcote Parkinson observed in The Economist in 1955 that work expands to fill the time available.

This helps explain one of the more striking results in McKinsey's 2026 State of AI survey. Eighty percent of respondents said AI had improved their individual productivity, but only 37 percent said it had contributed anything to their organization's earnings. Both findings can be accurate at once: the time was saved, but in most organizations no one was responsible for deciding where it went.

That responsibility usually sits with team leaders and operations managers rather than with the AI program. Their performance measures, schedules and routines are generally designed around the existing way of working. Unless they are given the time, authority and incentives to redeploy released capacity, the savings remain theoretical.

What to do instead

Leaders can avoid these problems by changing the order in which AI deployments are planned.

• Map the whole process first. Follow a piece of work from arrival to the point at which the customer receives an outcome, measure where it waits, and target the steps that limit overall throughput.

• Design for exceptions before scaling. Estimate what share of volume will still need human handling, who will handle it, and how they will keep the skills to do so.

• Decide in advance how released capacity will be used. Name the managers responsible for redeploying it and include their targets in the business case.

• Measure the process as well as the task. Track end-to-end cycle time, throughput, cost per case and rework alongside task-level time savings.

The value of AI in operations depends less on how much faster an individual task becomes than on whether the surrounding workflow is redesigned to make use of the time saved. Organizations that plan the end-to-end process, the handling of exceptions and the use of released capacity before they scale a tool are far more likely to see the gains in their results.