Case study
Claims FNOL Modernization
Replacing a dated claims intake screen with one modern form that works the same way for auto, home, and business claims.
- Claims UX
- Systems integration
- AI-assisted triage
- Auto · Home · Business
The brief
- Client
- National P&C insurance carrier — claims operations (generalised)
- Sector
- Insurance — claims intake
- Scope
- Modernizing First Notice of Loss intake for auto, home, and business claims
- Role
- Lead engineer and systems architect for the intake platform
- Team
- Worked with claims operations, compliance, the team that owned the existing integrations, and the call centre staff who would use it daily.
- Dates
- 2025 · phased rollout, one claim type at a time
What was already there
- 3claim types, three different intake paths
- 10+ yrsthe existing claims system had been running
- 1intake form after the rebuild
- 0existing system connections broken
The problem
The old system worked. It was just slow, dated, and inconsistent.
The company already had a claims system, and it had been running for more than a decade. Claims were filed, assigned, and paid through it every day. This was not a case of replacing paper forms with software. The software was already there and it was doing its job.
The problem was how it had aged. Auto, home, and business claims each had their own intake path. Those paths were built at different times by different teams, so they asked for the same information in different ways and stored it in different formats. Anyone who handled more than one claim type had to learn all three.
Routing was the bigger issue. Deciding which adjuster got a claim was mostly manual, and the rules were not the same across the three paths. The same type of loss could land in a different queue depending on which path it came through. When a claim went to the wrong place, it sat there until somebody noticed, and that delay came out of the customer’s first few days.
So the goal was easy to state and harder to do. One intake experience for all three claim types. Routing that works the same way every time. And none of it allowed to break the connections to policy, billing, and notifications that were already working fine.
Who this affected
Five groups used this system every day.Each one needed something different from it. Getting all five right at the same time was the hard part of the job.
What each group needed
The customer filing a claim
A short, clear form they can finish on a phone. Most people file a claim once every few years, so it has to make sense to somebody who has never seen it before and is having a bad day.
The adjuster
Claims that arrive in the right queue with the right details already filled in. When routing is wrong, the adjuster spends the first day or two sorting that out instead of working the claim.
The call centre agent
One system to learn instead of three, and no typing the same details into a second screen. Every re-entry is another chance for a typo, and typos follow a claim all the way to the end.
Compliance
A clear record of what was reported, when it arrived, and where it was sent. Some response-time rules change by state and by claim type, so the system had to handle different rules rather than assume one.
The platform team
No big switch-over. The existing connections to policy, billing, and notifications were working. Their position was reasonable: prove the new path first, then move traffic to it.
Approach
How we got from three paths to one
Four steps, rolled out one claim type at a time.
Compare the three paths
We listed every question each path asked and lined them up side by side. Most of the differences turned out to be the same question worded differently by teams who had never compared notes. What was left was a short list of fields that genuinely differ between auto, home, and business.
Build one form
A single intake form for all three claim types. It only splits into different questions at the point where the claim type actually needs different information. Everything before that is identical, so there is one thing to learn, one thing to test, and one thing to maintain.
Connect it to what was already running
Instead of replacing the existing connections to policy, claims, and notifications, we extended them to accept data from the new form. Everything that already worked kept working, and the new form could run alongside the old path until we were confident enough to switch over.
Make routing automatic
The assignment rules were written down properly for the first time and applied the same way across all three claim types. On top of that, a model reviews each new claim and flags the ones that look complex or unusual, so the adjuster knows before they open the file. The model flags it. A person still decides.
Decisions
- Buy a new claims platform, or improve the one already in place?
- Options: Replace it with a vendor platform (Guidewire, Duck Creek, Five Sigma, Snapsheet) · Rebuild the intake on top of the existing system
- Chosen: Rebuild the intake
- Those vendor platforms are good products. But they replace the entire claims system, and the entire claims system was not the problem. The problem was the intake form and the routing rules sitting on top of it. Replacing everything would have meant a multi-year project, a new licence to pay for every year, and rebuilding years of working connections — all to fix a much smaller thing. So we fixed the smaller thing.
- Replace the existing system connections, or extend them?
- Options: Rebuild the integration layer for the new form · Extend what was there to accept it
- Chosen: Extend them
- Rebuilding would have been more satisfying and left something cleaner behind. It also would have put every connection at risk at the same time, in a system handling live claims, with no way to test it gradually. Extending meant we could run the new form next to the old one, one claim type at a time, and go back if something looked wrong.
- How much should the model be allowed to decide?
- Options: Flag issues only · Flag and pre-sort claims · Sort and prioritise claims on its own
- Chosen: Flag and pre-sort; a person decides
- The model is good at spotting patterns across thousands of past claims that a person reading one file would miss. It is not accountable for the outcome, and in claims that matters — a claim sent to the wrong place is somebody waiting on money after a bad week. Flagging early gets most of the benefit. Letting it decide adds risk we had no need to take.
The interface
What we built
One intake form for all three claim types — connected to the systems that were already running, with routing rules that work the same way every time.
- One form for auto, home, and business claims
- Shared questions first, claim-specific questions only where needed
- Written-down routing rules, applied the same way every time
- A model that flags complex or unusual claims at the start
- Existing system connections extended, not replaced
- Automatic text updates so customers stop having to call and ask
- A record of what was reported, when, and where it went
Outcomes
- One formIntakewas three separate paths
- Same rules every timeRoutingwas manual and different per path
- GoneRe-typing between systemsagents no longer enter a claim twice
- Much less oftenClaims sent to the wrong queueexact figures not cleared to share
Exact percentages are not cleared for public sharing, so the numbers above describe direction rather than invented precision. The changes themselves are straightforward to state: three intake paths became one, agents stopped re-typing claims into a second system, and routing went from manual and inconsistent to a written set of rules applied the same way every time.
The part that mattered most is the hardest to measure. Somebody reporting a loss now does it once, in one place, and gets told what happens next without having to ring up and ask. That does not show up on a dashboard. It is just the difference between a company that sounds organised on a bad day and one that does not.
People only open this form on a bad day. Its job is to be quick, be clear, and then get out of the way.