What Minus 78% Is Made Of: Decomposing the Automation Effect

The figure "minus 78% of time" looks like a property of the product. It isn't one. It's the sum of three independent changes, each of which would have worked on its own, and none of which alone would have produced that result.

The difference between "we deployed a system and got 78%" and "here's what that 78% is made of" is practical, not academic. The first formulation transfers nowhere: in a different process it will produce a different number for reasons nobody can name. The second transfers completely, because it names mechanisms rather than an outcome.

The three components of a single number

The decomposition isn't done by system component but by the type of work that disappeared or changed. Each component has its own mechanism, its own beneficiary, and its own ceiling.

Rule-based assembly instead of manual work. Before, a manager opened a price list, ran a calculator, hunted for photos in a warehouse catalog, and laid out a document in a text editor. After, they selected line items and everything else was inserted automatically. This component delivers the most visible share of the time savings and works instantly: the effect shows up from the very first document. Its ceiling is the share of the work that can be formalized. Anything that can't be written as a rule stays manual.

Delivering the result into a system of record. The document left the deal record in one action and was filed there automatically. This component saves almost no time for the person doing the work — it saves time for everyone else: the manager who needs to see what was sent to a client, the accountant reconciling terms, the colleague picking up the deal. The effect is delayed and, for that reason, usually never makes it into the payback calculation.

An event that reports back into the loop. Whether a client opened the email or clicked the link — those facts triggered the next action. This component saves no time at all. It changes the outcome: it increases the share of deals that reach a conversation. In an "hours saved" calculation its contribution is zero; in revenue, it isn't.

Look at the second column. The components benefit different groups of people, and that explains a typical rollout conflict: the person doing the work sees only the first component, the manager is waiting for the third, and the company pays for all three at once.

Why the technology effect can't be separated from the organizational effect

The idea that a technology's contribution can be measured separately from the contribution of organizational change collides with the economic data — and has for a long time.

The caveat up front: this is correlational data from the late 1980s and 1990s, not an experiment, and the percentages shouldn't be carried over to today's rollouts as-is. What's valuable is the structure of the finding: technology and organizational change are complementary — their effects multiply rather than add. That's exactly why the final percentage can't be attributed to either one alone.

Why the average effect hides more than it shows

The second way to confirm that an aggregate number is useless without decomposition is to look at studies with a control group. There, the "average effect" turns out to be made up of very different numbers.

This is a working paper, not a final peer-reviewed publication as of this writing, and the data comes from a single company using a single tool. The specific percentages don't generalize. What generalizes is the mechanism: an average effect is made up of a large effect for one group and a near-zero effect for another, and the decision of whether to roll a tool out depends on your team's composition, not on the average.

The sign matters here. The same tool, at the same company, produces a gain on one class of tasks and a loss on another. Averaging those two numbers produces a figure that describes no real usage scenario.

How to decompose the effect in your own process

The method requires neither a control group nor statistics. It requires that changes be introduced one at a time rather than in a single release — and that's usually where the patience runs out.

The baseline measurement is the one part you can't do retroactively. Three numbers take half a day to collect: how long one result takes to produce, what share of results contain a defect, what share reach a reply from the client. Without them, every later comparison will be an argument about memories.

The pause between steps isn't for the sake of a tidy report — it's for control. If the effect after a single, bundled release turns out smaller than expected, you have no way to tell which of the three changes didn't work, and your next move becomes a guess.

Why a pilot doesn't reproduce at scale

The decomposition also explains the most common failure: a pilot shows an effect, and the company-wide rollout doesn't. In a pilot, the first component usually works, the second is present only partially, and the third isn't there at all.

This is an industry report, not a peer-reviewed study, and the sample isn't described as random — there's likely a skew toward companies willing to disclose their results publicly. But the mechanism it describes matches the decomposition: a pilot demonstrates the first component, while payback is created by the second and third, which pilots don't build because they require integration and a process owner. For more on where the effect actually originates, see the breakdown of where the effect comes from.

Four steps to make your effect number transferable

Questions people ask most often