How to Build a Business Case for Workflow Automation

Why Most Automation Business Cases Get Rejected

The two failure modes look like this.

First, vague math. The proposal says "this will save the team significant time" or "we expect strong ROI within twelve months." Significant and strong are not numbers. Twelve months is a deadline, not a calculation. A CFO reading this is being asked to approve a number that does not exist.

Second, unaddressed risk. The proposal lists benefits and skips what happens if the automation fails, ships late, or only partially works. The CFO knows there is risk. Pretending it does not exist makes the proposal look amateur, not optimistic.

The fix on both is the same. Build the case on four concrete inputs, show your work, and explicitly model the risk-adjusted outcome alongside the optimistic one.

The Four Input Variables That Matter

Every workflow automation ROI calculation reduces to four numbers. Each is observable. Each can be challenged. Each must be specific.

Hours per week per operator. How long does the manual workflow currently take, measured per operator? Not an average. The actual time, observed for at least one week before the case is written. If the team cannot produce this number, that is the first work item before the proposal.

Headcount affected. How many operators do this workflow? Usually the easiest number to produce, but watch for the trap of including people who touch the workflow occasionally. Count only the people whose week looks materially different after automation.

Fully loaded cost per operator hour. Not salary divided by hours. Fully loaded means salary, benefits, taxes, allocated overhead, divided by productive hours per year (typically around 1,800 for a salaried operator). This number is usually 1.4 to 1.6 times the salary-only rate, depending on geography and benefits structure.

Automation reliability adjustment. No automation works at 100 percent. The first wave handles maybe 60 to 80 percent of cases cleanly. The remaining 20 to 40 percent need human review or fall through to the manual process. The reliability adjustment scales the optimistic savings down to a realistic floor.

The formula:

Annual savings = Hours per week per operator × Headcount × Cost per hour × 52 weeks × Reliability adjustment

That is the entire foundation. Four numbers, one multiplication, no magic.

A Worked Example: A 50 Person Mid Market Operation

Take a real case. A 50 person operations team at a mid market services company spends time every week processing inbound vendor invoices. Manual data entry, three way match against POs, exception handling.

Inputs:

• Hours per week per operator: 8 hours observed across two weeks of manual logs
• Headcount affected: 12 operators (the AP team plus two supervisors who review exceptions)
• Fully loaded cost per operator hour: $52 (salary average of $36 per hour times 1.45 loading factor)
• Automation reliability adjustment: 70 percent (conservative first wave estimate based on Thessia delivery experience with similar workflows)

Annual savings calculation:

8 × 12 × $52 × 52 × 0.70 = $181,709

That is the realistic floor for year one steady state. The optimistic case (assuming 90 percent reliability) is $233,626. The pessimistic case (assuming 50 percent reliability) is $129,792.

Three numbers, not one. The board sees the range and the assumption that drives each end.

The implementation cost for a workflow of this size is typically $40,000 to $80,000 for build, plus 10 to 15 percent of that per year for ongoing operations. Even at the pessimistic end combined with the high implementation cost, payback is under 12 months.

This is the level of specificity the case needs. Numbers that can be challenged, an explicit reliability assumption, a range instead of a point estimate, and a payback period the board can verify.

Phase the Business Case Across Pilot, Expansion, and Steady State

A common mistake is presenting the full annual savings as the year one number. Year one is always lower because the automation is being built and rolled out during that year. The honest case has three phases.

Pilot (months 1 to 3). Build the automation, deploy it for a single team or a single workflow variant, measure actual reliability and savings. The cost in this phase is the build cost. Savings in this phase are roughly zero, because most of the team is still doing the work manually while the pilot runs in parallel.

Expansion (months 4 to 9). The pilot is validated, savings are real for the pilot scope, and the automation expands to cover the full headcount or full workflow variants. Savings ramp from 20 percent of the full case to 80 percent. Cost in this phase is mostly the rollout effort, change management, and any reliability tuning that came out of the pilot.

Steady state (months 10 to 12 and beyond). Full coverage, full reliability. The annual savings number from the formula above is the floor for this phase and every subsequent year. Ongoing cost is the maintenance and operations footprint, typically 10 to 15 percent of the original build.

Year one total savings, given this phasing, are typically 40 to 60 percent of the steady state number, not the full amount. Year two onward delivers the full case.

A board case that presents the full annual number for year one will be challenged correctly. A board case that presents the phased number will land.

The One Slide That Actually Moves a Board

The full case might be ten pages. The version that goes in front of the board is one slide. That slide has five elements.

Top left: the workflow being automated. One sentence, plain English. "We are automating inbound vendor invoice processing for the AP team."

Top right: the four inputs. A small table. Hours per week, headcount, cost per hour, reliability adjustment. Each number cited.

Center: the three year financial picture. Year one (phased), Year two (steady state), Year three (steady state). For each year, show savings, costs, and net. Use the realistic case as the headline number and show the optimistic and pessimistic ranges as a smaller annotation.

Bottom left: payback period and IRR. The two numbers a finance person will calculate themselves if you do not provide them.

Bottom right: the three risks and how each is mitigated. Usually the risks are reliability lower than expected, change management slower than expected, and integration scope larger than expected. For each, name the mitigation.

That is the slide. Everything else is backup material.

What This Framework Actually Buys You

A business case built this way passes three audiences in the same meeting.

Finance approves it because the math is observable and the assumptions are explicit. Operations leadership approves it because the phasing matches how the team will actually experience the rollout. The executive sponsor approves it because the one slide tells the story without requiring anyone to read appendix B.

A business case that clears all three reaches a decision in the meeting where it is presented. A business case that misses one of the three goes to "let's circle back" purgatory and dies there.

Curious whether your organization is set up to deliver this kind of automation cleanly once the case is approved? The Thessia Labs Enterprise AI Readiness Assessment scores your readiness across the dimensions that determine whether the automation can actually be executed. Fifteen questions, five minutes, free.