Workflow automation ROI: what actually moves the number
Most ROI cases for automation overstate the savings. Here is the simple model that holds up under scrutiny.
ROI cases for workflow automation are almost universally optimistic. Multiply hours saved by hourly cost, divide by build cost, and the return looks heroic. In practice, the saved hours often do not materialise because the work was never billable, and the build cost lasts longer than the spreadsheet suggested.
A more honest ROI model
We use a simple model when scoping engagements. Build cost is straightforward. Operating cost is the easy line item people forget: SaaS subscriptions, model inference, monitoring, and the slice of someone's time that keeps the system healthy.
Saved hours need to be discounted by two factors. The first is whether the saved time is actually deployable; an engineer who saves four hours a week and spends them on Reddit has not saved the company anything. The second is the proportion of the saved hours that goes back into higher-value work versus into administrative drift.
Where automation actually moves the number
Real ROI tends to come from three places. Capacity unlock, where the automation lets you do something at a scale you previously could not staff for (high-volume lead enrichment, content production, customer onboarding). Risk reduction, where automation removes a manual step that occasionally fails expensively (compliance reporting, billing reconciliation, support escalations). And response time, where automation collapses a multi-day handoff into seconds (lead qualification, ticket routing).
What rarely moves the number
Cost-takeout cases that depend on letting people go almost never play out as advertised. The political cost of the action erodes the savings, and the residual organisational complexity often grows. We have stopped pitching automation projects on cost-takeout grounds; the build is more durable when the business case is capacity, risk, or response time.
A useful test
Before committing to a workflow automation build, ask: if this saves the time it claims to save, where does the time go? If you can answer that with a specific higher-value activity that is currently capacity-constrained, the ROI case is real. If the answer is hand-waving, the ROI case probably is not.