Most insurance automation business cases I read are written as though the hard part were mechanical. Get the rules out of people's heads, get them into an engine, wire the engine to the workflow, and the efficiency follows. The risk register that comes with the case is a list of technical and delivery risks: integration, data quality, migration windows, testing capacity.
The best automation slide I have worked on did not read that way. It carried a value figure, a set of benefit drivers, and a column of practice rules. Most of them were warnings rather than encouragements, and one named a failure mode that no amount of integration testing will catch.
The engagement was a design proposal for an international health insurance group, covering automation across claims processing, underwriting and payment alongside a digital service redesign. The proposal produced findings, targets and a recommended approach. It is not a record of delivered savings, and I am not going to write it as one. What I want from it is the conditional structure of its own business case, because that structure is unusual and it is right.
A business case with a condition attached
Look at how the value figure is stated. GBP 22M, with two benefit drivers underneath it that a finance function can check: average cost per case down 5 percent, claims processed per full-time equivalent up 10 percent. That is a properly constructed number. It rests on two rates you can measure before and after.
Then, in the practice column beside it, the proposal makes a large share of that value explicitly contingent. Automation needs a pricing strategy underneath it that the underwriters have signed up to. Without that, they will work around the engine to get a lower rate or softer terms, and the underwriting result degrades along with the efficiency.
That contingency is the honest part of the document, and it is the part most automation cases leave out. The technology risks in a normal risk register are all risks of the engine not working. This is a risk of the engine working exactly as designed and being routed around anyway.
What routing around actually looks like
It is worth being concrete, because the phrase sounds softer than the behaviour.
An underwriter who does not agree with a price does not switch the engine off. That option is not available and would be visible if it were. What is available is everything the process still allows a person to decide. Which product or scheme a case is written under. How the risk is described in the fields that feed the rating. Which of several referral routes the case takes, and to whom. What is granted at renewal on terms rather than on price, so the rate stands and the cover moves instead.
Every one of those is a legitimate action performed by a person with the authority to perform it. Nothing is falsified. The engine is queried, the engine responds, and the answer it responds to is a slightly different question from the one the case actually poses. Over a book, a thin and consistent bias appears in the direction of the softer answer.
The engine did not have to be wrong for this to happen. It only had to be something the underwriter had not agreed to.
Why your monitoring will not see it
What should worry anyone standing up an automation programme, measurement layer and all, is this.
The metrics an automation programme reports are throughput metrics. Straight-through processing rate. Cases touched per head. Referral volume. Average handling time. Every one of those improves under the behaviour I just described, or at worst stays flat. The cases still flow. They flow faster, because a case shaped to fit the engine passes through cleanly. Your automation dashboard will look like a success story for several reporting cycles.
The damage lands somewhere else and later. It lands in loss ratio, in the mix of business written, in renewal terms, and it arrives blended with every other thing that moves a loss ratio: claims inflation, portfolio drift, one bad quarter in one region. By the time the underwriting result is bad enough to investigate, the automation programme has been declared delivered and the people who ran it have moved on.
This is a lineage problem as much as a governance one. To detect it you need to hold, per case, what the engine returned, what was finally applied, who changed it and on what authority. Most rating stacks I see keep the final state and overwrite the rest. Where the override history does survive, it usually survives in an audit table nobody has ever joined to the claims outcome. Mining the case history for the override pattern is entirely feasible, and it is close to the first thing I would stand up on the Platform, because it turns an argument about attitudes into a distribution you can put on one page.
The other rules are the same rule
Read the practice column together and it stops looking like a checklist.
Do not push automation too far into a front-end step such as first notification of loss, because the problems surface later in the process and the total cost goes up. That is a warning about a boundary: the automated step is optimised on its own metric while the cost lands on somebody downstream who was not consulted.
Capture all the required information at the point of entry. The proposal notes the common belief that a process should start on incomplete information, and states that experience proves the benefits of early entry outweigh the extra work. Again a boundary: the front of the process is made faster by pushing work, in the form of chasing and re-work, onto the people behind it. Beside those sits the instruction to manage performance with a dynamic model and comprehensive management information, so that process performance and customer behaviour both stay visible and the design keeps moving rather than settling at whichever local optimum the first team reached. And, in the same column, do not automate pricing without underwriter buy-in.
They are the same observation in different places. Automation moves work, judgement and cost across a boundary between people, and the boundary it crosses is where it fails. The engineering is not what fails. The engineering is usually fine.
There is a related note on the same page worth keeping: high levels of automation can escalate claims indemnity spend, so balance is required. More automation is not monotonically better. Somewhere past a point the cheap decision starts costing more than the expensive one, and only the indemnity line knows.
Per process, not per business
This is why the target-setting method on that page matters more than it looks.
Rather than declare one automation percentage for the organisation, the proposal commits to agreeing target levels per process against best practice. Some processes should be almost entirely automated. Some should not be, and saying so is a design decision rather than a failure to reach the target.
An organisation-wide automation number is a target nobody owns. A per-process target has a name attached to it, and that name usually belongs to the person whose judgement is being encoded. Which means the conversation about whether they agree happens at the moment the target is set, in the room, rather than eighteen cases into production when the workarounds have already found their groove.
That is the sequencing lesson, and it inverts how most programmes are planned. Pricing buy-in is not a change management activity that runs alongside the build and lands before go-live. It is a precondition of the build, because the pricing strategy is what the engine encodes. If the underwriters do not accept the price, you have not built a rating engine. You have built an expensive opinion that the people who write the risk are free to disagree with, one case at a time, and they will.
Where I would start
Get the pricing floor agreed first, in writing, per process, with the people who will be held to the result. That is a Consult problem before it is an engineering one. Then decide what the engine automates, and to what level, per process rather than in aggregate. Then instrument the override, because agreement decays and you want to see it decaying rather than infer it later from a loss ratio.
None of that is a modelling problem. Model deployment for pricing is not the constraint it was, and the pipelines are close to routine. That is precisely why the agreement layer deserves more attention now, not less: when the engine was slow and expensive to build, the argument about what it should encode happened by necessity, because nobody could afford to build the wrong one. The engine got cheap and the argument got skipped.
Figures are as stated in a design proposal for an international health insurance group covering automation and digital service across claims, underwriting and payment: its value-at-stake figure, its benefit drivers and its stated practices. That document produced findings, targets and a recommended approach, not delivered results. The reading of the pricing rule as the load-bearing condition of the business case is ours.
“The engine did not have to be wrong for this to happen. It only had to be something the underwriter had not agreed to. Agreement is not a communications workstream. It is the load-bearing element of the business case.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production: sovereign models, governed data, and agents you can audit. Start with a value-first assessment.