"This will save the team 10 hours a week" is usually the first sentence in an automation pitch, and it's usually where the analysis stops. Finance hears that sentence, asks what it costs to build and maintain, and the pitch stalls because nobody ran the other side of the math. A real ROI case needs both halves, and the costs side is where most proposals fall apart under scrutiny.
We build automation for a living, and the projects that get approved, funded, and actually maintained long-term are the ones where the ROI case was honest about setup cost, maintenance burden, and the specific savings, not the vague ones.
Start With What "Manual Process" Actually Costs Today
Before automation ROI means anything, you need an honest baseline. That's not "someone spends time on this," it's a specific number built from a few components:
Direct labor time. How many people, how many hours per week, at what loaded cost (salary plus benefits, not just base pay). This is the number most pitches get right because it's the easiest to estimate.
Error cost. Manual processes have an error rate, and errors have downstream cost, rework time, customer-facing mistakes, compliance exposure. This number gets skipped constantly because it's harder to pin down, but it's often larger than the labor savings alone.
Opportunity cost. What isn't happening because someone's stuck doing this manual task instead. Vague on its own, but concrete when you can point to a specific higher-value project that's been deprioritized because of bandwidth spent on the manual process.
Photo by Thirdman on Pexels
The Setup Cost Side Nobody Estimates Honestly
This is where most ROI pitches lose credibility with finance, because the build cost gets lowballed and the maintenance cost gets ignored entirely.
Build cost should include the actual engineering time (internal or contracted), any new tooling or API access required, and integration work with existing systems, which is almost always the part that runs longer than the initial estimate. A workflow that touches three different systems takes meaningfully longer to automate reliably than one that touches one.
Testing and validation time matters more for automation than for most software work, because an automated process that fails silently and produces wrong output is worse than the manual process it replaced. Budget real time for edge cases, not just the happy path.
Ongoing maintenance is the cost most proposals leave out entirely, and it's not optional. APIs change, data formats drift, upstream systems get upgraded without warning. A reasonable rule of thumb is budgeting 15 to 20 percent of the original build cost annually for maintenance on anything that depends on external systems you don't control.
Building the Actual ROI Calculation
Once you have honest numbers on both sides, the calculation itself is straightforward:
Annual savings = (labor hours saved x loaded hourly cost) + error cost reduction
Total cost year one = build cost + (maintenance cost x fraction of year remaining)
Payback period = build cost / (monthly savings - monthly maintenance cost)The payback period is the number that actually gets a proposal approved or rejected, more than the raw savings figure. A process that saves $50,000 a year but costs $80,000 to build and maintain has a much worse payback period than one that saves $20,000 a year and costs $15,000, even though the first number looks more impressive on a slide.
Photo by Pavel Danilyuk on Pexels
What Industry Research Actually Says About Payback Periods
It's worth grounding your own numbers against broader research rather than treating your first estimate as gospel. Gartner has published repeatedly on automation initiatives that stall after initial deployment, usually tracing back to underestimated maintenance burden rather than a flawed initial business case. McKinsey research on process automation consistently flags the gap between projected and realized savings as coming primarily from adoption friction, not technical failure, teams that don't actually change their workflow around the new automation don't realize the projected time savings even when the automation itself works correctly.
Harvard Business Review has covered the organizational side of this extensively: automation projects that involve the people whose work is being automated, early and honestly, see meaningfully better adoption than ones rolled out as a surprise. That's not a soft consideration, it directly affects whether your projected labor-hour savings actually materialize, since the savings only show up if people stop doing the manual version.
Photo by RDNE Stock project on Pexels
A Realistic Timeline for Seeing Returns
Most automation projects don't show positive ROI in month one, and treating month one as a verdict on the whole initiative is a common mistake. The Project Management Institute frames process-improvement initiatives in phases for a reason: build and parallel-run in the first phase, stabilization and exception-handling refinement in the second, and only in the third phase does the process run closer to the model you calculated ROI against in the first place.
Budgeting for a two-to-four-month runway before evaluating whether the ROI case held up gives the automation time to move through those phases honestly. Evaluating too early, based on a rocky first month still full of edge cases and manual fallback, tends to kill projects that would have paid off fine by month four.
Where Automation ROI Projections Usually Go Wrong
Assuming 100 percent of the time saved converts to value. If someone's freed-up hours don't get redirected to something that generates value, either revenue-producing work or genuine capacity for growth, the "savings" are theoretical. Time saved that just becomes slack in someone's calendar isn't zero value, but it's not the full labor-cost savings either.
Ignoring the ramp period. Automation rarely works perfectly on day one. Budget a few weeks to a few months of parallel running, manual and automated side by side, before you fully trust the automated output. That period has real cost (you're paying for both) and it needs to be in the model.
Underestimating exception handling. The 80 percent of cases that fit the standard pattern are easy to automate. The 20 percent that don't, and someone still has to handle those manually, plus handle the edge case where the automation gets it wrong. A realistic ROI case accounts for the fact that manual effort doesn't drop to zero, it drops to whatever the exception rate leaves behind.
"The proposals that survive a CFO's second look are the ones with a maintenance line item already in them. Leaving it out doesn't make the cost disappear, it just means it shows up as a surprise six months in, and that surprise is what kills trust in the next automation proposal." - Dennis Traina, founder of 137Foundry
Picking the Right Process to Automate First
Not every manual process is a good automation candidate, and picking the wrong first project can sink appetite for the next ten good ones. High-volume, well-defined, rule-based processes are the strongest early candidates, think data entry between systems, report generation, routine approvals with clear criteria. Processes that require judgment calls or handle a lot of genuine exceptions are harder to automate well and better candidates for a second or third phase, once you've built credibility with a cleaner win.
137Foundry's automation work tends to start exactly here, a well-scoped, high-volume process with a clear before-and-after, rather than trying to automate an entire department's workflow in one pass. The ROI case is easier to build and easier to defend when the scope is tight enough that every number in the calculation is grounded in something specific.
Tracking the Numbers After Launch
The ROI case shouldn't end once the proposal is approved. Set up actual tracking for the metrics you projected, hours saved, error rate, exception volume, before the automation goes live, not after someone asks how it's going three months in. Without a baseline captured cleanly and a dashboard tracking the same metrics post-launch, "did this actually pay off" becomes a matter of opinion instead of a number you can point to.
Photo by CDC on Pexels
This tracking does double duty: it validates the current project's ROI case, and it builds the track record that makes the next automation proposal easier to get approved, because you're no longer asking finance to trust a projection, you're showing them a project that actually delivered on one.
Presenting the Case to Finance
Lead with the payback period, not the raw savings number. Show the cost side first, build cost and ongoing maintenance, before you show the savings, so the audience sees you're not hiding anything. Include a sensitivity range, not a single number, since actual results rarely land exactly on the projection, and a range signals you've thought about what could go wrong.
If you're building this case for a real project and want a second set of eyes on the numbers before it goes in front of finance, 137Foundry's data and automation services work through exactly this kind of scoping regularly. A proposal that's honest about both sides of the ledger gets approved more often, and more importantly, gets funded for maintenance afterward instead of becoming the automation that nobody budgeted to keep working.
For more on how we approach these engagements, the about page covers our background, and the services overview has the full list of what we build.
None of this requires a finance background to do well, it requires being willing to write down the numbers that make the pitch less impressive on first read. A tighter, more honest case is the one that actually gets built, actually gets maintained, and actually shows up as a repeatable win the next time you need budget approved for the next process worth automating.
