Two jobs, not one
Warranty analytics is usually pitched as cost control: identify claims that fall outside cover. That matters, but the larger prize is often early detection of a fault pattern - a batch, a component, a production window - before it becomes a recall.
Those two goals need different models and different data, and conflating them produces a system that does neither well.
What a triage model can reasonably do
- Predict whether a claim will ultimately be approved, to route processing effort
- Estimate likely repair cost, to decide repair against replace
- Flag claims needing engineering assessment rather than administrative processing
- Identify claims that fit an emerging pattern worth investigating
Note what is absent: automatically rejecting claims. The asymmetry is severe - wrongly rejecting a genuine claim costs a customer, potentially a regulator's attention, and a complaint that costs more to handle than the claim.
Free-text descriptions are where the signal is
Structured claim fields are usually thin. The customer's description of the fault, and the engineer's notes, carry most of the information - and they are free text, inconsistent and full of shorthand.
Extracting structure from those notes is frequently the highest-value part of the work. Consistent fault categorisation enables pattern detection that no amount of modelling on structured fields alone will achieve.
Engineer notes in particular are worth the effort. They describe what was actually wrong rather than what the customer thought was wrong, which is the label you need for fault detection.
Detecting an emerging fault early
The valuable signal is a rate change within a slice - a specific component, batch, production week or supplier - not the overall claim volume, which moves slowly.
| Slice | Why it matters |
|---|---|
| Production date or batch | Isolates a manufacturing window |
| Component and supplier | Points at a sourcing change |
| Usage environment | Distinguishes design limit from defect |
| Time since sale | Separates early-life failure from wear |
Monitoring many slices means many chances for a false alarm, so the alerting threshold needs to account for that. An alert on every slice that has a bad week trains everyone to ignore alerts.
Keeping the customer outcome in view
A triage system that speeds up approval for straightforward claims is visible to customers as better service. One tuned only to find reasons to decline is visible as something else.
We would generally set thresholds so that the automated path only ever approves or routes onward - never declines - and let humans own every rejection with the model's reasoning attached as input rather than as a verdict.
Automate the yes. Leave the no to a person who can explain it.