Contents
Every claim has two people who need it to go well.
There is the business: carrying the indemnity cost, the loss-adjusting expense, the cycle time, the audit, and the Consumer Duty obligation that sits behind all of it. And there is the claimant: carrying the stress of a bad day, wanting two simple things, progress and fair treatment.
Almost every piece of technology sold into claims serves one of those two people. It takes cost out for the business, or it puts a friendlier face on for the customer. Rarely both. We think that split is the central problem in claims technology, and closing it is the whole point of how we built SwiftCase.
Why claims technology keeps picking a side
Look at the tools in a typical claims operation and you can usually tell, within a minute, which side of the claim they were built for.
The cost-takeout tools optimise the business. Straight-through processing, automated triage, supplier rate engines, fraud screening. They are measured on loss ratio and headcount, and they are largely invisible to the claimant, who experiences them as a slightly faster letter or a slightly shorter queue.
The experience tools optimise the customer. Branded portals, status pages, chat widgets, satisfaction surveys. They make the front door warmer, and they are measured on Net Promoter Score and complaint volumes. But they often sit on top of the same slow, manual operation underneath, so they improve the feeling of the claim without changing its substance.
The reason for the split is structural, not lazy. A tool that lives beside the claim, rather than running it, can only ever touch one side. A portal does not move the case forward; it reports on a case that humans are still moving by hand. A triage engine does not talk to the customer; it scores a case that someone else will explain. To serve both sides at once, you cannot bolt onto the operation. You have to be the operation.
What "both sides at once" actually looks like
When the same system runs the workflow and talks to the customer, a single improvement lands on both sides of the claim at the same time. That is the part worth slowing down on, because it is easy to say and hard to build.
Take first contact. A non-fault collision comes in at 2am. On a fragmented operation, the case waits until Monday for a handler to open it, triage it, and call the customer back. On a single platform, the case file builds itself as the detail arrives, the workflow triages it in seconds, the SLA clock starts, and the customer gets a calm, consistent first contact at the hour they actually needed it. The business pulls days out of the lifecycle. The customer gets progress on the worst night of their year. Same event, both sides, one system. We wrote about why first contact matters more than ever and where most operations lose it.
Or take a total-loss conversation. Done badly, it is a cost centre for the business and a grievance for the customer. Done on one platform, a named engineer sets the value, the agent presents it with comparable evidence shown in both directions, and any dispute escalates straight back to that engineer. The business gets consistency and a defensible file. The customer gets a calm conversation where nobody is trying to talk them into a number. We explained the design in why our AI never agrees a total-loss value.
In both cases the gain is not split between the business and the customer. It is the same gain, experienced from two directions, because there is one operation underneath instead of two systems pointed at each other.
The proof that both sides move together
This is not a thesis we are testing. It is the production behaviour we see.
At Laird Assessors, the platform runs out-of-hours intake, supplier chasing, and total-loss conversations. The business outcome is a 70 per cent reduction in case-creation time, across the whole platform rather than from any single bot. The customer outcome is consistent first-contact quality at any hour, with every conversation logged and defensible. The same deployment took cost out for the business and improved the experience for the claimant. That is rare in claims technology, and it is the thing we keep optimising for.
At the other end of the scale, a UK specialist motor insurer in the non-standard segment, with around 500,000 policies and more than 750 million pounds in gross written premium, runs more than 600 of its people on SwiftCase for email ingestion and task automation. Insurer-scale operations, in production today. You can read the specialist motor insurer case study for the detail.
Across the platform as a whole, that is more than 11.8 million cases since 2015, 40,000 users, and seven industries, with claims the deepest. The point of the scale is not the number. It is that the operation underneath has been hardened enough to carry both sides of a real claim without dropping either.
Both sides only works if a human owns the money
Serving the customer well does not mean letting the AI decide the claim. The opposite, in fact. The fastest way to fail the customer side of a regulated claim is to let a machine generate a value, negotiate an offer, or settle a case, because the moment a complaint reaches the Financial Ombudsman, there is no named human owner and no defensible record.
So the platform draws a hard line. The AI runs the operation: it reads the mess, opens the case, triages it, presents engineer-set values, drafts communications for approval, and escalates cleanly when a conversation needs a person. A human owns every decision that involves money or judgement, and every action is attributed to that named person in Timeline, our immutable audit logger. That is what makes the customer side safe and the business side defensible at the same time. We go deeper on the principle in human-in-the-loop AI for claims.
Why this is an operating system, not a feature
The reason one platform can serve both sides is that it is not a claims feature bolted onto a core system. It is the operating system the claim runs on: the workflow engine, the case file, the automation, the approval and authority controls, the immutable audit trail, and an agent layer that takes real action across voice, SMS, WhatsApp, web chat and email from a single definition.
That architecture is what lets a single improvement reach the business and the customer in the same motion. A faster intake is a lower cost and a calmer customer. A symmetric total-loss conversation is a consistent settlement and a fairer experience. A self-building audit trail is a Consumer Duty file and a customer who can trust the record. The seam between the two sides closes because there is only one system, not two.
Where to start
You do not have to take both sides on faith. The way most insurers and assessors test this is a 30-day pilot on one workflow: the noisiest, most manual conversation you have, deployed on your data and measured against your own SLA and cost-per-claim. If it lowers cost for the business and improves the experience for the customer, on the same workflow, at the same time, you have your answer. If it does not, you have spent a month.
We brought this argument to the ILC ClaimsTech 2026 final as a finalist, and we built a short hub around it for the people who heard the pitch: one platform, both sides of the claim.
The next decade of claims belongs to the operations that finally serve both sides at once: lower cost for the business, a fairer and faster experience for the customer, provably, on the same system. That is the whole idea.
Further reading:
- The ILC ClaimsTech 2026 hub: the pitch, the proof, and the pilot, in one place
- Why our AI never agrees a total-loss value: the human-in-the-loop design, end to end
- Where claims AI actually moves your P&L: indemnity, loss-adjusting expense, cycle time and resilience
- Insurance solutions: the operational walkthrough by workflow
- Laird Assessors year in review: both sides, proven in production