Why your automation ROI estimates keep missing the target
Most automation ROI models share a structural flaw that operations teams rarely notice until a CFO points it out: they start from an assumption about the process rather than from a measurement of it. The assumption is almost always wrong, and finance, which has seen more than a few optimistic projections, can usually tell.
This is the baseline problem. It is not primarily a financial modelling problem. It is a data problem, and it runs deeper than most teams realise when they build their first automation business case.
Where the baseline comes from
When an operations team puts together an automation ROI estimate, they typically start with one of three sources for the process baseline. They use the documented process (how the process is supposed to work), self-reported time data from process interviews, or industry benchmarks from analyst reports and vendor white papers.
All three have the same structural problem: they describe what people believe is happening, not what is actually happening. Documented processes are typically written during implementation or as part of a compliance exercise, and they are rarely updated as the process evolves. Interview-based time estimates are subject to well-documented cognitive biases: people underestimate time spent on routine work and overestimate time spent on things they consider valuable. Industry benchmarks describe averages across organisations that may bear little resemblance to your own workflow configuration, volume, or exception rate.
The gap between these assumed baselines and measured reality is consistently large. In the Fluency early-access data from January to June 2026, the median gap between documented cycle time and measured cycle time across onboarded workflows was 3.1x. That means the process was taking, on average, three times longer than teams believed it was taking. For a business case built on "we currently spend X time on this process," a 3x error in X is not a rounding error. It fundamentally changes what savings are achievable, what payback period looks like, and whether the automation is actually targeting the right problem.
How the error compounds
The baseline problem does not stop at cycle time. It compounds through the entire ROI model in at least three ways.
First, if cycle time is wrong, cost is wrong by the same factor. An automation business case that claims to save 40% of process cost based on a 2-day cycle time is actually claiming to save 40% of a process that costs three times more than you thought, or it is claiming to save 40% of the wrong base entirely if the actual improvement is measured against the real 6.2-day process.
Second, the exception rate is almost always undercounted in documented processes. Every process has exceptions: requests that do not fit the standard path, approvals that need to be escalated, data that arrives in the wrong format and has to be manually corrected. These exceptions represent a disproportionate share of total process cost because they require human attention, they interrupt other work, and they often trigger rework. When you build a baseline from the documented process, you build it on the happy path. The happy path might represent 60% of actual transaction volume. Automating only the happy path, based on a business case that did not account for exceptions, produces savings that are 40% lower than projected, and that is before the automation team discovers that the exceptions broke their implementation during testing.
Third, volume assumptions compound the error. Documented processes rarely track actual transaction volumes across different process variants. When you measure actual workflow data, you frequently discover that a process you assumed ran at a consistent cadence actually has significant volume variation: high peaks during quarter-end, lulls mid-month, exception spikes around specific trigger events. An ROI model that assumes flat volume will misestimate both the cost baseline and the savings potential.
What a measured baseline looks like
The alternative to assumption-based baselines is event log-derived baselines. Every modern business system records timestamped events: when a ticket was created, when it changed state, when it was assigned, when it was completed. When you connect a workflow analytics tool to these event logs, you can reconstruct the actual execution path of every process instance over the preceding months.
From that data, you get a baseline that reflects what actually happened: distribution of cycle times (not the average, but the full distribution including outliers), exception rate by process variant, volume by time period, rework frequency, and hand-off duration. These numbers describe your actual process, not a hypothetical version of it.
A business case built on this foundation is defensible in a way that benchmark-based estimates are not. When a CFO asks "how do you know it takes 8.3 days?" the answer is not "we timed a few representatives" or "industry data says so." The answer is "here is the distribution of 847 transactions over the last six months." That is a different kind of conversation.
The savings calculation problem
Even with a measured baseline, the savings calculation requires care. The most common error here is confusing cycle time with labour time. Automation reduces the labour time required per transaction. It does not automatically reduce the calendar-time cycle, unless the delay in the cycle is caused by labour time. In many approval workflows, the cycle time is long not because approvers are spending a lot of time on each request, but because requests are sitting in queues waiting for attention. Automating the approval step itself may reduce transaction processing time, but if queue wait time dominates, the cycle time improvement will be modest.
Similarly, FTE savings require careful translation from time savings. If a process improvement frees up 30 minutes per day across a team, that does not translate to a half-FTE reduction unless you can actually remove a role or redeploy the time to revenue-generating activity. Finance is right to be sceptical of "time savings" that do not connect to a measurable headcount or opportunity cost outcome.
We are not saying that time savings without direct headcount reduction have no value. They often represent real capacity that can be directed elsewhere. We are saying that the translation from "hours saved" to "dollars saved" needs to be explicit and defensible, and that this translation is where many business cases lose credibility.
Building the credible version
A credible automation ROI estimate has three components that distinguish it from a benchmark-based guess.
The first is a measured baseline. Event log data from your actual systems, covering at least three months and ideally six to twelve, describing the real cycle time distribution, exception rate, and volume profile for the process you are targeting.
The second is a conservative improvement estimate, with the conservatism clearly stated. "We expect to reduce average cycle time from 8.3 days to 3.1 days" should be accompanied by a clear statement of what assumption underlies that estimate: what the automation actually does, what portion of the cycle time is addressed by the automation, and what the basis is for the improvement estimate. Pilot data from a similar implementation is the strongest basis. A reasonable engineering estimate with stated assumptions is acceptable. A vendor promise without supporting data is not.
The third is a direct translation to financial outcome. Labour time saved, times loaded hourly cost, times annual volume, equals annual cost reduction. Exception reduction multiplied by cost-per-exception equals rework savings. These numbers need to be calculated from your actual process data, not from industry percentages applied to an assumed base.
The baseline problem is solvable. It requires measuring before estimating, which sounds obvious but is not how most automation business cases are built. When teams have the actual data, the business case changes. Sometimes it gets stronger, because the actual process cost is much higher than assumed. Sometimes it reveals that the targeted improvement is smaller than expected, which is also useful information: better to know before committing budget than after an implementation that delivers half the projected savings.
Finance is not the obstacle in most automation funding decisions. The quality of the evidence is the obstacle. Fix the baseline, and most of the other objections follow.