From 6 months to 6 weeks: rebuilding a claims system in insurance

A Dutch non-life insurer came to us with a familiar problem: a claims intake system that was slowing down adjusters, losing data between handoffs, and had been on the modernisation roadmap for three years without moving.

The existing system was a combination of a 15-year-old on-premise application, a shared email inbox used as a queue, and three manual handoff steps between intake and the adjuster who would actually evaluate the claim. Average intake-to-assignment time: 4 hours. Error rate on initial data capture: 12%.

The business case was clear. The question was how to get there without an 8-month project that would land during a regulatory freeze.

Why the classic approach wasn't going to work

The textbook approach to this kind of project involves discovery, requirements documentation, vendor selection, design, build, QA, UAT, and deployment. Running in sequence, with sign-off at each stage, this typically takes 6–9 months.

For this project, there were two specific blockers.

First, the regulatory environment. New reporting requirements for claims data were coming into force in Q3, which meant any replacement system needed to be live before then, or the organisation would be running two systems simultaneously for claims already in the pipeline.

Second, the integration complexity. The claims system connected to six other internal systems: policy data, payment processing, document storage, communication logs, the adjuster scheduling system, and the regulatory reporting system. Each integration had its own data contract, owned by a different internal team.

A 6-month waterfall project with six integration points and a hard regulatory deadline was not a plan. It was a risk.

What we did instead

We proposed a different scope. Instead of replacing the full claims system, we would replace the intake layer: the part where claims arrived, got validated, and got routed to adjusters. This was the highest-pain part of the current system and the part with the most direct impact on adjuster productivity.

The approach:

• Start with a working intake form connected to the policy data system on day 1, with no full integration suite, just the one connection needed to validate the claim
• Add one integration point per week, in order of business impact
• Ship to production every Friday with a subset of real claims being processed through the new system
• Keep the legacy system running in parallel until the new intake layer had processed 1,000 claims without error

The timeline

Week 1: Working intake form, connected to policy data. First real claims processed through the new system, a pilot with four adjusters.

Week 2: Payment processing integration. Document storage integration. Pilot expanded to 20 adjusters. Error rate on initial data capture drops from 12% to 2.4%.

Week 3: Communication logs integration. Automated routing rules: claims matched to adjusters by coverage type and workload.

Week 4: Adjuster scheduling integration. Real-time queue dashboard visible to team leads.

Week 5: Regulatory reporting integration. Full compliance logging for every claim event.

Week 6: Legacy system traffic reduced to zero for new claims. 1,247 claims processed through the new intake layer.

Six weeks from kick-off to full production cutover, before the Q3 regulatory deadline.

The outcome

The measurable results at week 6:

• Intake-to-assignment time: from 4 hours to 22 minutes
• Data capture error rate: from 12% to 1.8%
• Adjuster capacity freed per week: approximately 11 hours (previously spent on manual data correction and queue management)
• All six integration points live and tested under real load

The project came in at approximately 40% of the budget that had been allocated for the full 6-month programme.

What made it possible

Narrowed scope with clear success criteria. Instead of "replace the claims system," the brief became "process 1,000 claims through a new intake layer without error before Q3." That is a testable outcome. You know when you have hit it.

Weekly production deployments. Every Friday, something was live with real users and real claims. This forced early discovery of integration problems: instead of finding them in UAT, we found them in week 1 with four adjusters and resolved them before they became delays.

Single-team accountability. One team held the full loop from brief to deployed code. There was no QA handoff, no separate integration team, no change approval board between the developers and the production environment. When something broke, the same people who built it fixed it.

The 6-month project estimate was not unreasonable given the original scope. The 6-week delivery was not magic. It was the result of reducing the scope to what actually needed to change, shipping continuously, and removing the handoff points where delays accumulate.