FDE case study: NovaSure claims intake and triage
A motor and health insurer is slow to settle claims and the regulator has noticed. This case follows one forward deployed engagement from the first meeting to production: what was broken, how discovery found the one number to move, what was built, who was involved, the gates it had to pass, and what it changed.
The client
NovaSure sells motor and health insurance. Claims are handled in three regional centres by a team of adjusters who check each claim against the policy, decide what to pay, and send the hard cases to review.
| Measure | Value |
|---|---|
| Employees | 1,200 |
| Regional claims centres | 3 |
| Claims a month | 42,000 |
| Average settlement time | 7.5 days |
| Adjusters | 180+ |
| Claims escalated or reworked | 22% |
What is broken
- Re-keying. Claims arrive as PDFs, photos and emails, and adjusters type the details into the claims system by hand.
- Scattered policy wording. The terms that decide a claim live in more than 400 documents.
- Inconsistent fraud triage. Each centre decides differently which claims need a fraud review.
- Regulator pressure. The regulator has flagged NovaSure's settlement times against its service levels.
What they already tried
- A vendor chatbot demo, which looked good on clean samples and failed on real scanned claims.
- An RPA project, which broke every time the claims system's screens changed.
- Hiring more adjusters, which added cost without fixing the process.
After three attempts the CIO no longer wants a tool. They want a partner who owns the outcome: someone who will stay until settlement time actually drops. That is the brief a forward deployed engineer is sent in on.
Weeks 1 and 2: discovery
- Shadow the adjusters for three days and map the claims process as it really runs: 11 steps from a claim arriving to a payment decision.
- Audit 500 historical claims to see where time goes, which fields are re-keyed, and what makes a claim go back for rework.
- Pick the KPI: settlement time on standard motor claims, from 7.5 days to under 4. It is a number the business already tracks and the regulator already watches.
- Meet IT Security on day 4, not at the end: data residency, how personal data is handled, and the fact that everything must run in NovaSure's Azure tenant.
- Write a 6-page SOW: a proof of concept in 2 weeks, a pilot in 6, and production in 8, each with a gate to pass before the next starts.
The solution: an AI claims intake and triage assistant
The assistant prepares each claim for an adjuster rather than deciding it alone. A claim moves through six steps:
- Intake: the PDF, photos or email arrive in one queue.
- Extract: OCR reads the scans and an LLM pulls the claim fields out as structured data.
- Policy RAG: the relevant policy wording is retrieved and quoted with citations.
- Triage agent: the claim is routed to auto-approve, to an adjuster, or to fraud review.
- Human review: an adjuster checks the prepared claim and approves, corrects or rejects it.
- Write-back: the result goes into the core claims system, with an audit trail of every step.
| Layer | Choice |
|---|---|
| Models | Azure OpenAI, with an open-weight model served by vLLM as the fallback |
| Orchestration | LangGraph, with checkpoints and human-in-the-loop review |
| Storage and retrieval | Azure Blob Storage for documents, pgvector for policy passages |
| Access and privacy | SSO and role-based access control, PII masking |
| Quality and visibility | Langfuse tracing and evals on every change |
Who was involved
| Role | Part in the engagement |
|---|---|
| Forward deployed engineer | Runs discovery, builds and deploys the system on site, and owns the technical result |
| Engagement lead | Owns the client relationship, the SOW and the commercial terms |
| Product and research liaison | Takes what the field learns back to the vendor's product and research teams |
| CIO (sponsor) | Owns the budget and the decision at each gate |
| Head of Claims | Owns the KPI and the adjusters' process |
| IT and Security | Data residency, personal data, and the Azure tenant |
| Data team | Historical claims for the audit and the evals, and access to the core system |
| Adjusters | Shadowed in discovery, the pilot users, and the people who review every prepared claim |
Delivery: 16 weeks, three gates
| Stage | Weeks | Scope | Gate to pass |
|---|---|---|---|
| Proof of concept | 1 to 2 | Extraction and policy lookup on historical claims | More than 90% field accuracy |
| Pilot | 3 to 8 | 12 adjusters on live claims | Settlement time and adjuster satisfaction |
| Production | 9 to 16 | All 3 centres, with monitoring and runbooks | KPI met 4 weeks in a row |
Each gate is a decision the sponsor makes on evidence, written into the SOW before any code. A gate that is missed is a conversation about scope, not a surprise at the end.
Outcomes
| Measure | Before | After |
|---|---|---|
| Settlement time | 7.5 days | 3.2 days |
| Claims prepared automatically for the adjuster | None | 61% |
| Claims reworked or escalated | 22% | 9% |
Together these are worth an estimated ₹4.8 Cr a year to NovaSure.
What the FDE handed back
A forward deployed engineer also works for their own company. What they learn on site goes back into the product, so the next client starts further ahead. From NovaSure that was:
- A reusable claims template for the next insurer
- 3 platform bugs found in the field and fixed
- A 2,000-claim evaluation set
- A reference customer
- The KPI came from shadowing the work and auditing real claims, not from the model
- Meeting security in week 1 shaped the platform: Azure tenant, PII masking, an open-weight fallback
- The assistant prepares claims and a person decides, which is what made a pilot acceptable
- Every stage had a written gate, so each go or no-go was a decision on evidence
- For your capstone domain, write the client table and the "what is broken" list the way this case does
- Choose one KPI and write its current value and target, then the three gates that would prove you moved it
Every expert started right here.