Claims automation for an insurer that has tried before

The second attempt is harder than the first, and not for technical reasons. Somewhere in the building is a claims leader who sat through a vendor demonstration two or three years ago, watched a system read a clean first notice of loss and extract nine fields correctly, approved a program, and then watched it stall at eleven percent of volume because the real mail is not clean. That person is now the hardest audience in the room and also the most valuable one, because they know exactly where the last program broke. This is written for the insurer that has tried, and it starts from the three places these programs actually fail: document variety, adjuster trust, and the core system.

None of the three is a modelling problem. That is the most useful thing to say up front. The models available now read documents well enough that extraction accuracy is rarely the constraint. The constraint is that a claims operation is a chain of decisions made by people who are accountable for them, running on a policy administration system that was configured over a decade, and a system that automates part of that chain has to earn its place in every link.

Why the last attempt stalled

Document variety was underestimated by an order of magnitude. The pilot ran on a curated set. Production runs on whatever arrives: a first notice taken by phone and typed into a free-text box, a repair estimate from one of eleven estimating platforms, a medical bill on a standard form, a medical bill on a clinic's own letterhead, a police report scanned at low resolution, a photograph of a document taken on a phone at an angle, a fifty-page demand package from a law firm with exhibits in no particular order, an email chain where the relevant fact is in the third reply. A system tuned on the tidy quarter of that distribution meets the other three quarters and abstains, and abstention at scale reads to the operation as a system that does not work.

Adjusters did not trust it and were not obliged to. An adjuster carries a file and answers for the outcome. If a machine puts a recommendation on the screen with no visible reason and no way to check it against the page, the rational response is to ignore it and do the work the old way. Which they did. Adoption then read as culture resistance in the steering committee, when it was a straightforward user-interface and evidence problem.

The core system integration was left for the end. The policy administration or claims platform accepts what it accepts, through the interfaces the vendor supports, on the vendor's release schedule. Programs that treat write-back as the last sprint discover in month seven that the field they want to populate is derived, or that the interface is batch and nightly when the design assumed synchronous, or that a change request has a two-quarter queue. The design should have started from that constraint.

Nobody agreed what success meant, so the result was arguable. Straight-through processing rate is a number, but a rate on which subset, measured how, against which baseline, and net of what leakage effect. If finance and claims did not settle that before the build, the program's outcome becomes a debate rather than a result.

Document intelligence that survives real mail

Start with the intake, because everything downstream inherits its errors. A claims intake pipeline that works has properties that a demonstration pipeline does not need.

Page-level boundary detection before document-level classification. Real submissions arrive as one file containing many documents. A system that labels the file rather than the pages will mislabel every multi-document package, and multi-document packages are most of the interesting volume. Detect boundaries first, then classify each detected document from the evidence on its pages.

Two extraction strategies, chosen by document type. Structured forms with stable layouts are extracted by template and anchor and checked by arithmetic. Everything else, which is the majority in claims, goes to a language model reading the page with the target schema and the page image together, because the text layer of a scanned document is unreliable and the visual layout carries meaning that the text order destroys. Building one strategy and forcing all documents through it is the most common architectural mistake in this category.

Provenance on every extracted value. Page number, bounding box, the method that produced it, the model version, the confidence. This is not a nicety. It is what makes the adjuster interface possible, what makes an audit answerable, and what makes a regression traceable when a number changes between releases.

Cross-document reconciliation, which is where the value actually is. Single-field extraction is a commodity. The work an adjuster does that takes real time is reconciling facts across documents: does the date of loss on the first notice match the police report, does the vehicle identification number on the estimate match the policy, does the treatment date on the bill fall inside the coverage period, does the demand total equal the sum of the exhibits, is the same injury described consistently across three providers. Build the reconciliation layer and the system starts doing the adjuster's tedious work instead of their easy work.

Deliberate abstention with a reason. A system that says "low confidence" has told the adjuster nothing. A system that says "the estimate references a supplement not present in this file" has told them exactly what to do. Model the abstention reasons as first-class outputs. They also become the roadmap: the most frequent abstention reason next quarter is the next thing to build.

Straight-through processing, scoped honestly

Straight-through processing means a claim that opens, adjudicates and pays without a human touching it. It is achievable on a narrow band of claims and ruinous if applied wider than that band. The discipline is in defining the band and enforcing it in code.

The band is defined by a set of gates, each of which is a written rule with a business owner. Coverage is clean and in force with no lapse near the loss date. The reported amount is below a stated threshold. The claimant is not represented. No injury is alleged. The loss type is on an approved list. No fraud indicator fires. Policy history shows no recent claims pattern that requires review. The documents needed are all present and extracted above threshold with no reconciliation failure. Every gate is auditable, every gate has an owner, and any gate can be tightened in production without a deployment.

What matters operationally is the disposition of a claim that fails a gate. It should not fall to the bottom of a general queue. It should route with the reason attached and with everything the machine already worked out attached to it, so the adjuster who picks it up starts from a prepared file rather than from a raw one. That routing is what converts the automation program from a partial win on a small band into an improvement across the whole book.

Adjuster tooling is the adoption strategy

There is no separate change management program that fixes a tool adjusters dislike. The tool is the change management program. A few properties decide it, and each of them is an engineering decision rather than a training decision.

Every machine-produced value is one click from its source. Click the date of loss and the page appears with the box highlighted. This single feature does more for trust than any accuracy figure, because it converts the system from an oracle into a research assistant whose work can be checked in two seconds.

The system's summary is a draft the adjuster owns. Never a locked recommendation. The adjuster edits it, and the edit is captured as a training signal and as an evaluation case. Adjusters will correct a draft they can change; they will ignore a verdict they cannot.

It has to be faster on the first day, not eventually. If the new screen requires more keystrokes than the old one for a common task, adoption is lost regardless of the intelligence behind it. Measure keystrokes and clicks for the five most common tasks before and after. This is unglamorous and it is decisive.

Disagreement is a one-key action with a reason code. The reasons feed the evaluation set and the abstention taxonomy. An operation that can see its own corrections aggregated by reason will start telling the build team what to fix, which is the point at which the program becomes self-sustaining.

Nothing is hidden. Which gates a claim passed, which it failed, what the model was uncertain about, what version produced the output. Claims professionals are audited constantly and they are correctly suspicious of anything they cannot explain to a supervisor.

Measurement finance will accept

Set the definitions before the build, in writing, with the finance leader's name on the document. The following list is the one we bring to that meeting.

• Straight-through rate, with the denominator stated. Percentage of claims in the defined band that completed with no human touch, plus percentage of total claims in that band. Two numbers, always reported together, because one without the other is a marketing figure.
• Cycle time from first notice to close, by segment. Segment matters: an aggregate improvement driven entirely by the simple band tells the operation nothing about the standard band where most of the labor sits.
• Touches per claim and handle time per touch. These move independently and both matter. A system can cut touches while lengthening each one, which is a real gain that a handle-time-only measurement will miss.
• Indemnity accuracy and leakage, sampled by an independent quality team. The question finance will ask is whether faster payment means overpayment. Answer it with a sampling program designed before launch, run by the existing quality function, on both automated and manual claims so the comparison is like for like.
• Reopen rate and complaint rate. The two lagging indicators that catch a system that closes claims cleanly and wrongly. Watch them by cohort for at least two quarters after launch.
• Correction rate by document type and by reason. The operational health metric. Rising correction rate on one document type usually means a form changed upstream, and it is visible weeks before it shows up in accuracy.
• Cost per claim, fully loaded, including the platform. The number the chief financial officer will use. Include hosting, model inference, licensing and the engineering support line, not just labor saved.

The first line of business, and how to expand

Pick the line with high volume, low individual severity, stable document types and an operations leader who wants it. Auto physical damage and simple property claims usually fit. Avoid starting with the line where the executive pressure is highest but the claims are complex and infrequent, because the evaluation set will be too small to measure anything and the first result will be noise.

Scope the first release to a defined band inside that line and to a defined document set, and write both down. Then expand along one axis at a time. Add document types within the same line before adding a line. When adding a line, keep the pipeline, the review tool, the reconciliation engine and the measurement, and replace only the document taxonomy, the extraction schemas and the gates. That is what makes the second line cost a fraction of the first, and it only works if the first was built as a platform rather than as a point solution. The distinction is visible in the code: are document types, schemas, rules and gates configuration, or are they conditionals scattered through the pipeline.

What we build, and how we work inside a claims organization

Precision Federal builds AI systems, data platforms and full-stack applications and delivers them into production, including inside U.S. federal agencies where the security, accessibility and auditability bar is set by the government and reviewed by someone other than us. That work shapes how we run an insurance engagement: the system has to explain itself, the controls are designed in, and the documentation is a deliverable rather than an afterthought.

In the first two to three weeks our engineers produce four things from real claims data inside the insurer's environment. A document census: an actual count of what arrives, by type, by channel, by quality, drawn at random from a real intake window rather than from a curated sample. A written technical scope with measurable acceptance criteria and the gate definitions. An integration design that names the core platform, the interfaces it supports and the write-back path, confirmed with the platform team. And a measurement definition signed by finance and claims quality. That package stands on its own and is worth having even if nothing further is built.

The build then runs in increments against real claims in the insurer's own environment, with security review, access control and accessibility inside the increments rather than after them. Adjusters use the tool from the first increment, in a shadow mode where their corrections are captured but nothing they do changes. The handover is a rehearsal: the insurer's own engineers deploy the system while ours watch, before the final invoice.

The insurer keeps all of it. Source, models, prompts, schemas, gate configuration, evaluation sets, corrections, documentation and the customer relationship. Our pre-existing tooling is named, carved out of the assignment, and licensed perpetually to the insurer for use in the delivered system so no future maintainer is blocked. Pricing is either fixed-price milestones tied to written acceptance criteria, or a committed team for a defined period when the roadmap runs longer than a single scope. We say which fits before you ask.

The first step is one email with a one-page brief: the line of business, the core platform by product and version, roughly what arrives and through which channels, who can grant access to real files, the date that matters, and who approves a scope change. We return a scoped, priced statement of work.

An illustrative example of the arithmetic

The following is illustrative and structural rather than a claim about any insurer. Put your own numbers in the shape and have finance agree the baseline first.

Take a line running 40,000 claims a year. Suppose 30 percent fall inside a defined simple band, and the program reaches straight-through processing on 60 percent of that band, which is 7,200 claims fully automated. Suppose the remaining 32,800 claims each see handle time fall by 18 percent because the file arrives prepared and reconciled. The automated band and the prepared-file effect are two separate benefits, and the second one is usually larger in total even though the first is the one that gets presented. That is why the routing design for gate failures matters as much as the gates themselves, and why a program measured only by straight-through rate will underreport its own result.

Bottom line

A second attempt succeeds by inverting the first one's order. Start from the real document distribution rather than a sample. Design the core platform write-back in week one because it sets the schedule. Build the adjuster tool as the adoption strategy, with every value one click from its page. Define straight-through processing as a narrow band behind written gates, and spend equal effort on what happens to the claims that fail a gate. Agree the measurement with finance before writing code. Then build the first line as a platform, so the second line is configuration. The insurer that does those six things has a program instead of another pilot.

Frequently asked questions