The operations team at a mid-size insurer often knows which processes should be automated. The conversation with the CFO or COO is the harder problem. This article is about how to structure that conversation so it leads to an approved budget rather than a "let's revisit this next quarter."
I have been in that room many times. The challenge is not that finance leaders do not understand automation; most of them do, at least at a surface level. The challenge is that they have seen automation projects fail to deliver the projected savings, or deliver them later than promised, and they are applying reasonable skepticism to the next proposal. The burden of proof is on the operations team making the case.
Start with What Finance Already Knows
The most effective business cases for back-office automation start not with the automation technology but with a cost problem that the CFO already recognizes. Operations headcount at insurers grows roughly in proportion to claim volume and policy count unless something structurally changes. Every finance leader knows this. The question is whether automation can be that structural change.
The framing mistake most operations teams make is presenting automation as a technology investment. The CFO is not interested in what the technology does; they are interested in what the operations line looks like in three years with it versus without it. Those are two different conversations, and the second one is the right one.
A useful way to frame the opening is: "Without any structural change to how we handle [claims intake / policy renewal / reconciliation], our operations cost grows by approximately X% per year as volume grows. We have identified a subset of that cost that can be addressed without system replacement or headcount reduction." That last point matters. Automation business cases that depend on significant headcount reduction face a different approval process than ones focused on cost curve management and capacity. At a mid-size insurer with a stable team, headcount reduction framing is often politically difficult and rarely necessary.
Quantifying the Baseline
The weakest element of most automation business cases is the baseline measurement. Teams present estimated hours per process per week, multiplied by an average fully-loaded cost per hour, and arrive at a number that sounds significant. The CFO asks who did the measurement, and the honest answer is usually "one of our senior people estimated it."
Estimates from senior staff are systematically biased. People who are good at their jobs tend to underestimate how long processes take because they have internalized efficiency gains that newer staff have not. The number they give is the time it takes them, not the time it takes the team on average. When an automation then takes slightly longer to process exceptions than the estimate suggested, the ROI case looks worse than it should.
Baseline measurements need to be observed rather than estimated. This means looking at actual system logs where available, or running a time-tracking exercise over two to four weeks before the business case is submitted. It takes more time upfront, but it produces a number that can be defended when questioned, and it often reveals that the actual time cost is higher than the estimate, which strengthens the case rather than weakening it.
A claims operations team at a regional property and casualty insurer we worked with recently estimated their daily status update process at about forty-five minutes per operator per day. Observed measurement over three weeks produced a figure of approximately one hour and twenty minutes, when accounting for context-switching, system slowdowns during peak periods, and the time spent on exception cases that the estimate had not included. The automation business case that went to the CFO used the observed figure, and it was approved on first submission.
The ROI Calculation: What to Include and What to Leave Out
The return calculation for back-office automation has two components that are almost always present and one that is sometimes present but often overstated.
The first component is direct time savings. Hours per week that operators currently spend on the automated process, multiplied by the number of operators doing it, multiplied by the fully-loaded cost per hour. This is the most straightforward calculation and the one most proposals lead with. It is also the most credible, because it is directly verifiable once the automation is running.
The second component is error correction cost. Manual process execution produces errors at a measurable rate. Each error has a correction cost in time and in some cases in downstream financial impact. Automation reduces the error rate significantly for well-defined processes. Including error correction cost in the baseline is legitimate and often represents a non-trivial fraction of the total.
The third component, which we recommend leaving out or heavily discounting, is future capacity value. Projections of what could be done with the time freed up by automation are speculative and easy to dismiss. Finance leaders have seen projections like "freeing up 300 hours per month will allow us to pursue growth opportunities" before, and they have watched those hours get absorbed by other work rather than generating the projected value. Do not build the business case on this component unless you have a specific, committed plan for redeployment with a named accountable owner.
The Cost Side: Getting the Investment Estimate Right
Business cases fail at the CFO level almost as often from underestimating implementation cost as from overstating benefits. The classic underestimate is the platform licensing cost without the implementation and ongoing maintenance cost. A standalone RPA tool license might be priced attractively, but if the implementation requires six months of consultant time and ongoing script maintenance costs are not accounted for, the actual cost over a three-year period looks very different from the initial proposal.
The cost components that need to be in the proposal are: platform or tooling cost, internal staff time during implementation (this is often treated as free but is not), any integration or infrastructure changes required, training time for the operations team, and the ongoing maintenance cost. For automation that interacts with systems that change periodically, maintenance is not zero and should be estimated conservatively.
Handling the Skepticism About Previous Projects
If there have been previous automation attempts at the institution that did not deliver, those attempts will come up in the review. The right approach is to name them proactively and explain specifically what was different about those projects and why this one is structured differently.
Common failure modes that finance leaders recognize: automation was built without documented process definitions; the scope grew during implementation and the original ROI case no longer applied; the system that the automation depended on changed and the scripts were not maintained. A business case that directly addresses why those failure modes will not recur here is more credible than one that ignores the history.
We are not saying every previous project failed for the same reasons. But for any institution where automation has been tried before, the honest accounting of what happened is both the right approach and the strategically effective one.
The Staged Proposal
One structure that tends to work at mid-size insurers is a staged approval: a smaller first commitment to prove the ROI on one or two specific processes, followed by a second commitment to extend across a broader set once the results are demonstrated. This reduces the upfront budget ask significantly and addresses the skepticism about whether automation will deliver what the proposal claims.
The key to making a staged proposal credible is choosing the first processes carefully. The processes selected for the first phase should be the ones where the ROI is clearest, the process is best documented, and the risk of scope change or system instability is lowest. The first phase exists to prove the business case on a small scale, not to tackle the most complex problem in the portfolio. Selecting the most visible or strategically interesting process rather than the most straightforward one is a common mistake that makes the first phase harder than it needs to be.