Every claim checked against the policy, answered in minutes.
A UK vehicle-warranty administrator assessed every claim by hand: read the email, work through a 69-clause terms document, check the vehicle's MOT and tax history, look up the part, price it, negotiate. About thirty minutes a claim, and a hard ceiling of roughly fifteen claims a day per person. This is the system designed to do the first pass of that — and how it was validated against real data before anyone committed to building it.
Claims handling determines the margin.
Roughly 35–40% of claims get paid, and most of those are negotiated down. Every check a handler skips under time pressure is money out of the door — and the check most likely to be skipped is the slowest one.
Each claim meant decoding a garage's email, finding the warranty schedule, working through the terms for valid grounds to decline, checking tax and MOT status, checking the MOT advisory history for a pre-existing fault, identifying the part, pricing it, applying the labour cap against standard repair times, and then negotiating.
Every one of those steps is a person applying a written rulebook to checkable facts. The rulebook doesn't change between claims. That's what makes it automatable — and the consumer-facing rejections carry legal and reputational risk, which is what makes getting it right non-negotiable.
Validated against real data before pricing.
Nothing was assumed that could be measured. Two findings changed the design, and one reduced the scope of the project.
We instrumented the real inbox
Rather than trust "claims come in by email", we measured it: 46 business emails over four days. Only about one in five was a new claim — a 5:1 noise ratio nobody had quantified. Claims also arrived spread across several emails, keyed by number plate, and the portal was already sending semi-structured forms that a script could parse directly. Every one of those facts changed the intake design, and none were knowable without looking.
The volume was a quarter of what everyone assumed
The working assumption was 10–30 claims a day. Measured, it was about 2.5. That single number reshaped the revenue projection and the business case — downwards. It is exactly the kind of finding an audit exists to produce, and exactly the kind most people would rather not go looking for.
We priced real parts before promising pricing
Three real vehicle-specific parts were priced end to end against the live market and benchmarked against external retail sources. Two landed within about 5%. The third failed — usefully — and produced the validation layer described below.
The client's own documents disagreed
The terms and the customer booklet stated different servicing allowances, and two repeat-claim rules contradicted each other. Surfacing and resolving those into a single canonical rule set was an early credibility win — and the reason the encoded rules, not the source PDFs, became the single source of truth.
No decision is made until all facts are assembled.
A linear pipeline with deterministic checkpoints, one shared claim record, and every side-effect — email out, portal write — held to the very end.
Intake
Watches the claims inbox, captures the email and its attachments, and extracts text from PDFs.
Triage
New claim, correspondence on an existing one, or noise. Multi-email claims are threaded by number plate and merged. Correspondence routes to a person untouched.
Extraction
Email and attachments become a typed claim record, validated against a required-fields schema. Never free text downstream.
Evidence
Warranty schedule, official tax and MOT status, full advisory and mileage history, and payment state for subscription products.
Rules
The terms as executable rules: validity, then vehicle, then coverage. Every rule that fires records the clause behind it.
Pricing
Only if the claim survives. Labour at the capped rate against standard times; parts from live market comparables.
Verdict
Decline, counter-offer or accept — plus two internal states: request more information, or escalate to a person.
Response
Common outcomes are templates. Judgment cases get written prose inside a fixed skeleton, with every figure injected by script.
The cost shape follows the pipeline. Claims that fail early cost around two pence to process, and roughly 60% are declined — most of those answered by template. Only survivors reach the expensive stages. Blended, well under twenty pence a claim.
The AI never decides a verdict.
What the rules do
Every decision comes from the terms encoded clause by clause and run as deterministic code. The same claim always produces the same answer, and every outcome names the clause it relied on. That is what makes a decline defensible to a customer, an underwriter or an ombudsman.
What the AI does
Three jobs only: turn a messy inbound email into structured data, classify a described fault against a component list, and draft the wording of the reply. Each returns a typed value the rules consume — never a verdict.
How that's enforced
Every figure in an outbound email is injected by script, not written by the model. Any clause the model cites is checked against what the rules engine actually decided before the email can send. A citation that doesn't match is caught rather than posted.
Why it's built this way
Language models are excellent at reading bad emails and writing clear replies, and unreliable at applying a rulebook consistently. So each side does what it's actually good at. This isn't caution for its own sake — it's the only version a regulated business can defend.
Identifying and pricing parts without a licensed catalogue.
Pricing a claim properly means knowing the exact part. The industry-standard catalogue for that has no API and its terms prohibit automation — a dead end.
The way through: the marketplace is both the part-number source and the price source. Listings carry manufacturer part numbers in their item data. So the pipeline goes number plate → make, model and year from official vehicle data → the garage's part description normalised → a discovery search → and where two or three independent listings agree on the same part number, that number is treated as confirmed. Then a tight re-search on that number, split by condition, produces the comparables.
Offers are anchored at the lower quartile of validated prices, with the median as the settlement ceiling — and every counter-offer ships with the listings it was derived from attached.
Two design decisions and the reasons for them.
Every external service sits behind an interface
Mid-project, a data provider account was suspended without warning and the appeal was refused. Because the pricing source was wrapped behind a swappable interface with a tested fallback, the design absorbed it at a cost of around half a penny per claim, with no change to the pipeline. Single-provider risk stops being theoretical the first time it happens.
One pipeline, a config per product
The client launched a second, subscription-based product mid-design, with entirely different validity rules. Because the engine is one pipeline driven by per-product configuration, that became a config rather than a second system — and the same structure is what would let the engine serve a different warranty administrator by encoding their terms instead.
The system must match the team’s decisions before it handles claims.
Three phases, each gated on measured agreement with the current team and advanced only on the client’s written approval.
Shadow
The engine assesses every real claim in parallel with the team. Nobody acts on its answers. A dashboard shows agreement rate, verdict breakdown and payout differences, claim by claim.
Supervised
The engine drafts, a person approves with one click. Declines are always signed by a human.
Autonomous
Within thresholds the client sets, and only for the initial outcome. Negotiation, edge cases and final sign-off stay with the team.
Scope is deliberately narrow. Version one automates the initial outcome only. Follow-up negotiation is a genuinely different, judgment-heavy job — that boundary came from analysing the real inbox, not from a whiteboard.
Repetitive decisions handled manually.
The same approach applies to claims, applications and approvals.
The approach applies wherever a person repeatedly applies written rules to verifiable facts. Describe the decision and you will get a direct assessment of whether it is worth automating.