Posted on 18 May 2026 by
The last decade of insurance technology has overwhelmingly funded the parts of the process customers can see – quote, bind, FNOL, customer comms – and the parts that produce reports for the board. The middle, which produces neither, has been left largely as it was.
This article is about why that gap has persisted, the specific places it shows up inside a claims function, and what’s changed about the cost and complexity of closing it.
Estimated read time: 7 minutes
18 May 2026
The shape of the problem
A useful way to think about a claims function is as three connected pieces:
The front door is everything from first notification to a claim being formally opened: FNOL channels, customer authentication, initial data capture, triage logic. This has had a lot of technology investment over the last decade, most of it visible to the customer.
The back door is final settlement, communication of the outcome, and the data that flows back into reporting and analytics. Also well invested, partly because it’s where MI dashboards live and boards pay attention.
The operational middle is everything in between: validation, investigation, document handling, reserving, supplier instruction, payment authorisation, fraud checks, internal handoffs, and the dozens of smaller decisions that move a claim from one stage to the next.
It’s the part of the process that doesn’t show up on a customer journey map and doesn’t generate a board-friendly metric on its own, but it consumes the majority of operational headcount and time.
If you wanted to find the highest-leverage place to put technology in a claims function, you would start in the middle. The industry, broadly, has not.
Why the middle has stayed manual
The honest answer isn’t that operations leaders haven’t noticed. They have. Most claims directors can name, in some detail, the bottlenecks in their own middle – the documents that sit unread, the handoffs that stall, the manual reconciliations that absorb half a senior handler’s week.
What’s kept those bottlenecks in place is an inherited assumption about what fixing them costs. The assumption runs roughly like this: meaningful change in the operational middle requires a new core system, a multi-year integration programme, dedicated IT resource that operations doesn’t control, and a level of disruption that’s hard to justify against any single business case.
For most organisations, that assumption has functioned as a reason not to start. Not a stated decision – those rarely get made. Just a slow drift in which the case for change is always obvious, but the path to it never quite is.
The consequences are easy to underestimate because they’re cumulative. The combined ratio stays a few points tighter than it should. Experienced adjusters retire and the institutional knowledge isn’t replaced at the same rate. Customer expectations keep rising, set by industries that have none of insurance’s legacy constraints.
Cycle times that looked acceptable in 2018 look slow in 2026. None of these are crisis-level on their own. Together, they describe an operation that’s quietly losing ground every year.
The assumption was always partly wrong. In the current technology landscape, it’s mostly wrong.
Three places the middle breaks
To be concrete, here’s where the operational middle most consistently leaks time and money in the operations we work with.
Unstructured information arriving in volume
Loss adjuster reports, medical records, repair quotes, witness statements, supplier invoices, broker emails – claims operations receive a continuous stream of unstructured information in varying formats from varying sources.
In most operations, that information either waits for a human to read and re-key it, or it creates a backlog that holds up everything downstream of it. The cost isn’t just the handling time. It’s the cycle time impact of a claim that can’t progress because the information needed to progress it is sitting in a queue.
Handoffs that don’t move themselves
A claim typically passes through several stages, often several teams, between being logged and being settled. Each of those transitions is a handoff. In a manual operation, the handoff happens when someone notices the previous stage is complete and pushes the work forward. In a well-designed operation, the handoff happens automatically the moment the previous stage’s outputs satisfy the conditions for the next stage to begin.
The difference between those two models, multiplied across thousands of claims, is significant. It’s also one of the largest sources of unexplained cycle time variance in most operations.
Supplier and payment coordination
A single claim can involve multiple third parties: repairers, medical providers, legal panels, recovery agents, fraud investigators. Each has its own system, its own SLAs, its own update cadence. Coordinating that activity, tracking spend against reserves in real time, and authorising payments correctly is still substantially manual in most operations.
The cost of getting it wrong – in leakage, in duplicate payment, in late notification – is well documented. The cost of doing it manually right is also significant: it absorbs a meaningful proportion of senior handler time on activity that, in principle, the system should manage.
None of these are exotic. None require ripping out a policy administration system to address. But cumulatively they describe an operational middle that’s running at perhaps 60-70% of the efficiency it could be – not because the people are slow, but because they’re doing work the technology around them is capable of doing.
What’s actually changed in the last few years
Three things, in combination, have changed the cost and feasibility of fixing the middle.
Orchestration without replacement. The previous generation of claims technology tended to assume that meaningful workflow change required owning the workflow end-to-end – i.e., a new core.
The current generation of orchestration platforms is built to sit across existing systems, reading from them and writing to them, without replacing them. The integration model is fundamentally different: shorter, less invasive, and configurable by operations teams rather than dependent on a long IT programme.
Document understanding that actually works. Intelligent document processing has moved past the threshold where it’s a research project.
Modern IDP can reliably extract structured data from the kind of messy, varied claims documents that have historically defied automation – and feed that data into a workflow the moment it arrives. The implication for cycle time is significant: a document arriving overnight can trigger the next stage of a claim before anyone has come into the office.
AI applied selectively. The interesting question with AI in claims isn’t whether to use it. It’s where.
The operations getting value from AI are the ones treating it as one tool in a workflow, not the whole workflow. Specifically: at the steps where the right next action depends on a combination of factors no fixed rule could anticipate, AI can support a handler’s decision rather than replace it. At the steps that are pure administration, AI is overkill and conventional automation is the right answer. At the steps requiring genuine expertise and judgement, the workflow should preserve human decision-making and concentrate handler time there.
This is the principle ACE – RDT’s workflow orchestration engine – was built around. Orchestrate the middle, automate the administration, apply intelligent document processing where unstructured information would otherwise create bottlenecks, and bring AI to bear at the specific decision points where it improves outcomes – without replacing any of the systems on either side.
What good looks like operationally
A reasonable test for whether an operation has addressed the middle isn’t whether it has bought any specific piece of technology. It’s whether the proportion of handler time spent on activity that genuinely requires their judgement has gone up.
In a well-orchestrated operation, handlers spend more of their day on the small number of decisions only they can make, and proportionally less on the much larger volume of administration around those decisions. Document review, data entry, status chasing, payment processing, supplier coordination – these either happen automatically or are surfaced to handlers in a way that makes them quick to resolve.
You can usually see the change in three places:
Cycle time variance narrows. When handoffs are automated and information flows without manual prompting, the difference between the fastest-handled claims and the slowest-handled claims of a similar type compresses. Outliers usually existed because of waiting, not because of inherent claim complexity.
Cost per claim drops, but not where you’d expect. The savings rarely come from headcount reduction. They come from the same headcount handling more claims, or handling them better, because their time is concentrated on activity that adds value. The handlers themselves usually notice this before the management accounts do.
The operation becomes less dependent on its most experienced people. A lot of claims operations quietly run on the knowledge of a small number of senior handlers who know how to chase the right person, find the right document, escalate the right decision. When the workflow itself does that work, the operation becomes less fragile and easier to scale.
Common pitfalls when operations do try to fix the middle
A few patterns we see repeatedly, worth flagging because they’re avoidable:
Treating the workflow as one thing. The most expensive mistake is automating uniformly – applying the same level of intervention to every step. Some steps need full automation, some need rules-based business logic with human review, some need to stay human. Good workflow design starts by distinguishing between them. Operations that skip this step either over-automate decisions that needed judgement, or under-automate work that should never have required a person.
Starting with the technology rather than the bottleneck. A common opening move is to pick a vendor, then look for places to apply their product. The more effective opening move is to name a specific, measurable bottleneck – “we have too many claims sitting between triage and assignment, and we can’t see why” – and then look for the right tool. The specificity is what makes the business case real and the project deliverable.
Underestimating the importance of configurability. Workflow design isn’t a one-time exercise. Products change, claim types change, regulation changes. An orchestration layer that requires IT involvement every time the operation wants to adjust a rule is a slower-moving operation than one where ops teams can change the workflow themselves. The difference compounds over years.
How to start
The clients we work with who get measurable results from operational middle change share one characteristic. They don’t start with “we need to transform.” They start with one specific bottleneck they can describe in operational language, attach a number to, and feel the pain of.
From there, the work is sequential rather than monumental: identify the workflow, design the steps with the right treatment for each, integrate to the systems that already exist, and measure the cycle time and cost outcomes that result. Once one workflow has been done well, the second is significantly easier. The operation builds capability as it goes.
The organisations doing this well aren’t the ones with the most sophisticated technology stack. They’re the ones who were honest enough to look at what was actually happening in the operational middle – the part everyone else has been glossing over – and decide it was worth fixing.
If you’ve been waiting for the conditions to be perfect to start, this is a reasonable moment to stop waiting.
If any of this resonates – or you disagree with the framing – I’d be interested to hear from you. You can reach me through the RDT team, and if you’d like to see how ACE handles the operational middle in practice, you can book a conversation.
Joe O’Connor is Deputy CEO of RDT. RDT builds ACE – workflow orchestration and intelligent document processing for claims operations at insurers, MGAs and TPAs.
