Skip to content
Case study

Claims triage that explains its own decisions

A triage model with a logged override path, a documented model card, and a monthly review session with the claims team that owns it.

Handling time
-31%
Overrides logged
100%
Claims scored daily
12k
Model cards
3

The situation

Claims triage was manual and inconsistent. Two adjusters could route the same claim differently, and neither decision was recorded in a way that could be reviewed later.

Constraints

This is a regulated decision affecting individuals, so it was treated as high risk from the first design session. Every automated decision needed a logged reason and a human able to overturn it.

What we did

A triage model scoring 12,000 claims a day, with three model cards covering the components and a documented override path used by the claims team.

The override is not an escape hatch bolted on at the end. It is the primary interface: the model proposes a route, the adjuster confirms or changes it, and the reason feeds the next evaluation cycle.

Governance in practice

When the regulator asked how a decision was reached, the answer took an afternoon rather than a project, because the documentation had been written during the build rather than reconstructed afterwards.

Results

MeasureBeforeAfter
Average handling time14 days9.7 days
Claims routed automatically0%62%
Decisions with a logged reasonPartial100%
Time to answer a regulatorWeeksSame day

What we left behind

  • A project in the client's own repository, with tests and CI
  • Documented definitions with named owners
  • Runbooks for every scheduled job, written for a non-engineer
  • Two weeks of training for the team taking it over

Tell us which number you cannot trust

Send one paragraph about the report that always starts an argument. A data lead, not a salesperson, replies within one business day.