The IT Automation ROI Calculator: How to Build the Business Case

Most IT automation business cases die in the CFO's office because they are written like engineering proposals. The CFO does not care that n8n is faster than Power Automate. They care whether the project pays back inside the planning horizon and whether the saved time becomes a saved euro on the income statement.

This article is the calculator we use when we help clients build the case for an automation programme. Five components: the time-saved model, the error-cost model, the FTE-equivalence model, the indirect-value model, and the honest cost model. Together they produce a spreadsheet the CFO will sign and an engineering team that knows what they are committing to deliver.

Why most automation business cases fail

The pattern we see repeatedly:

1. Engineering team identifies an obvious automation candidate ("we manually provision 40 accounts per month").
2. They write a proposal that says "automation will save 8 hours/month of engineering time".
3. CFO does the maths in their head: 8 hours × €80/hour = €640/month = €7,680/year.
4. Project budget needs €25,000. Payback period is 3+ years. Decision: not now.
5. Engineering goes back to manual provisioning. Frustration grows.

The proposal was not wrong; it was incomplete. The CFO's maths missed four cost lines that the engineering team forgot to surface: the error cost of manual work, the opportunity cost of the engineers' time, the scalability ceiling that the manual process imposes, and the indirect productivity drag on the people waiting for provisioning.

A full business case captures all five lines. Done honestly, the ROI numbers transform — typically from 18-24 month payback to 4-9 months. The CFO signs not because the numbers are inflated but because they are complete.

Component 01: The time-saved model (boring but mandatory)

The foundation everyone gets right. For each automation candidate, measure:

• How many times per month / quarter / year does this task happen?
• How long does each instance take, end to end?
• Who does it, at what fully-loaded cost per hour?

The trap is using "fully-loaded cost per hour" as the only multiplier. The CFO will accept €60-€80/hour for a senior engineer including overhead. They will not accept €120/hour unless you can defend the figure with reference to total compensation, benefits, employer NIC, equipment, and overhead allocations. Use the conservative number; the case is stronger when defended with restraint.

This single table is the floor of the business case. Annualised, it gives you €58,920/year of recurring labour cost the automation will reduce. The CFO will multiply this by 0.4-0.8 depending on how much of the work is actually eliminated (vs shifted to oversight). That gives the realistic time-saved line.

Component 02: The error-cost model (where the case is actually won)

Manual processes produce errors. Errors cost money. Most business cases skip this line because errors are uncomfortable to quantify. The CFO finds it the most credible line when it is presented honestly.

Error categories that matter

1. Provisioning errors. Wrong group memberships, missed license assignments, devices shipped without correct MDM enrolment. Cost: rework time + delayed productivity for the affected employee.
2. Offboarding errors. Access not revoked on time. Cost: compliance exposure if discovered in audit; security incident if exploited.
3. Compliance evidence gaps. An auditor finds a missing log, a misconfigured policy, a stale exception register. Cost: remediation effort + potential regulatory fine + audit-cycle delay.
4. License waste. Unused licenses on stale accounts, over-provisioned SKUs, expired-but-renewed subscriptions. Cost: directly measurable monthly burn.
5. Service request SLA breaches. A request that took 5 days when SLA was 2. Cost: lost productivity for the affected team + escalation overhead.

The honest quantification

For each category, you need three numbers:

• Frequency. How often does this error happen? Pull from your ticketing system, helpdesk logs, audit reports, or do a 4-week measurement before the project starts.
• Direct cost per occurrence. Rework time + immediate consequences.
• Discount factor. Multiply by 0.6-0.8 to account for the fact that automation will not eliminate all errors, just most of them.

Component 03: The FTE-equivalence model

"Time saved" is hours, not money. CFOs convert hours back into money through the FTE-equivalence question: if we save this many engineering hours per month, what does that mean for headcount?

The answer is rarely "we will reduce headcount". It is usually one of:

• Hiring deferral. The growth plan needed +1 engineer in Q3. Automation pushes that to Q1 next year. Saved cost: 6 months × fully-loaded engineer cost = €40-60k.
• Reallocation to higher-value work. The engineer's time goes from "ticket grind" to "architectural improvements". The CFO needs to see what those improvements are worth.
• Capacity for growth. Same team can support a 2x larger employee base without hiring. The avoided hiring cost over the planning horizon is the saving.

The FTE-equivalence equation

For a project that saves 80 hours/month of engineering time:

Hours saved per month: 80
Effective hours per FTE per month (after meetings, admin, holiday): 130
FTE-equivalence: 80 / 130 = 0.62 FTE

Fully-loaded annual cost of one senior IT engineer (Malta, 2026): €78,000
Annual FTE-equivalent value: 0.62 × €78,000 = €48,360

Realistic capture rate (not all saved time becomes equivalent value): 60-80%
Conservative annual value of the automation: 0.7 × €48,360 = €33,852

The capture rate is the honest part. If you assume 100% capture you are saying every saved minute becomes equivalent productive minute, which is wrong. The conservative 60-80% range is defensible.

Component 04: The indirect-value model

Three lines the engineering team usually forgets:

Indirect line 01: Productivity drag on waiting parties

If new-hire provisioning takes 3 days, the new hire is unproductive for 3 days. Their fully-loaded cost during that period is a real loss. Multiply across joiners per year and the number is meaningful.

A 200-person company with 25% annual turnover (typical for tech) sees ~50 joiners/year. If each loses 2.5 productive days on slow provisioning, that is 125 person-days of productivity drag. At €350/day fully-loaded cost: €43,750/year. Automation that compresses provisioning to 30 minutes recovers most of this.

Indirect line 02: Compliance posture

This is hard to quantify and uncomfortable to present, but real. Automated provisioning + automated evidence collection materially reduces the probability of an adverse audit finding. The expected cost of an adverse finding (in time, fines, reputational impact) is non-zero. Use a conservative expected-value calculation.

For a DORA-regulated FinTech: probability of a finding without automation maybe 25%/year; with automation maybe 5%. Cost of a finding (remediation + executive time + potential fine): €150,000 conservative. Annual risk-adjusted value: (25% - 5%) × €150,000 = €30,000.

Indirect line 03: Attraction and retention

Engineers do not stay at companies where they spend their day on provisioning tickets. Turnover cost (recruiting, ramping, lost institutional knowledge) is conservatively 1.5x annual salary for senior engineers. If automation reduces engineering turnover by even one person per year, the saving exceeds the project cost.

This line is the easiest one to over-claim. We typically include it qualitatively in the business case (as a footnote) and let the CFO weight it themselves.

Component 05: The honest cost model

Where most business cases lose credibility. The costs of an automation project are not just the engineering work. Five lines:

The line every business case forgets: ongoing operations. Workflows are not write-once. They break when integrated SaaS APIs change, when business processes shift, when new edge cases emerge. Budget for 0.1-0.2 FTE of ongoing operations per 20 workflows in the estate.

The full calculation, end-to-end

Putting it together for a hypothetical mid-market estate (200 employees, modest cloud footprint, Malta-based):

This is the table the CFO needs to see. Defensible numbers. Conservative capture rates. Explicit operations cost. Realistic payback. A 6-9 month payback with a 3-year NPV in the high six figures is a project that gets approved.

The build-or-buy line

The single most common CFO follow-up question: "Why are we building this instead of buying it?"

The honest answer depends on the scenario:

• Buy if there is a vertical product that solves your specific pain (e.g., an off-the-shelf IT-helpdesk AI agent). The vendor has done the engineering and the safety work. You pay per-seat in exchange for not having to operate.
• Build with a managed platform (Power Automate, Make, n8n Cloud) if the workflows are mostly integration-shaped and the vendor's primitives match your needs.
• Build self-hosted (n8n on your own infrastructure) if you have engineering capacity, the scenarios are high-volume or sovereignty-sensitive, and the operating discipline is in place.
• Buy operated (us, or another firm with an Operate tier) if you want the outcomes without the engineering or operations burden. The premium over self-hosted is paid in trade for an SLA on flow health and an operator who picks up the phone when things break.

What the calculator does not capture

Honest limitations:

• Organisational change. The CFO accepting the case is necessary but not sufficient. The team using the new flows is the other half. Budget for change management.
• Vendor lock-in risk. A "free" platform that becomes load-bearing for your operations creates lock-in. Factor in the exit cost as a risk-adjusted line.
• Capability ceiling. The automations you build first are the easy ones. The harder ones come later. The diminishing returns matter for long-range planning.

The brutally short version

An honest IT-automation business case includes five components, not one. Time saved is the floor, not the ceiling. Error cost is where the case is actually won. FTE equivalence is the CFO's mental model — meet them there. Indirect value (productivity drag, compliance posture) usually doubles the case. Operations cost is the line every engineering team forgets; budget for it explicitly. Done well, an automation programme pays back in 6-9 months and produces a 3-year NPV in the high six figures. Done badly, it ships and gets shelved.

If you want the calculator filled in for your specific operation — we run the diagnostic in a free discovery call, score your top 10 candidate workflows on the five components, and produce the CFO-ready spreadsheet. The conversation usually ends with two or three workflows that pay back in the first quarter. The full programme is the Intelligent Workflow Automation service.