Claims processing automation

Count touches, not claims

Almost every claims automation business case starts with claim volume, and claim volume is the wrong denominator. Two operations processing the same number of claims can differ threefold in cost, because the expensive thing is not the claim, it is the number of times a human being opens it. A claim that arrives complete, matches a policy or a member, prices cleanly and pays is nearly free. A claim that comes in as a forty-page fax, gets keyed, pends for a missing document, waits nine days for a reply, gets re-reviewed by someone who has forgotten it, and then goes out with an error that produces a call and a correction has been touched seven times. The second claim costs twenty or thirty times the first, and your volume report shows them as one each.

So the first week of any serious effort is measurement, not modelling. Sample a few hundred claims and count, honestly, how many human touches each took and how long each touch was. Then group by claim type, by intake channel, and by the reason for the first touch. That distribution is the project plan. It is common to find that a small handful of pend reasons account for the majority of all rework, and that one intake channel produces several times the touches of the others. Both of those are addressable without any machine learning at all, and they should be addressed first because they are cheaper.

Intake is where the cost is, and it is the part that gets underscoped

Every claims operation has a clean electronic channel and everyone plans around it. Then there is everything else: email attachments, portal uploads of phone photographs, a fax line that is still running because a long-standing partner will not change, scanned bundles from a mailroom, and the occasional envelope. The clean channel is easy and is usually already automated. The project lives or dies on the rest.

Three problems inside intake deserve their own budget lines.

Splitting. A single sixty-page fax often contains four separate documents belonging to two claims, with the pages in the wrong order and one of them upside down. Deciding where one document ends and the next begins is a genuinely hard task, it is upstream of everything else, and it is almost never in the scope of a proof of concept. If splitting is wrong, extraction accuracy on the parts is irrelevant.

Matching. The document has to attach to the right claim, policy, member or account. Names are misspelled, identifiers are transposed, a claim number is handwritten. Fuzzy matching gets you a long way and the last stretch needs a human queue with good tooling, because a document filed against the wrong claim is worse than one that was never filed.

Image quality. Faxes arrive at low resolution, photographs are taken at an angle in poor light, and scans have specks and staples. A model evaluated on clean PDFs and deployed against that population will underperform its evaluation by a wide margin, and everybody will blame the model.

Perception versus decision, and why the split matters

The most durable architecture we have seen keeps two things apart. Machine learning does perception and routing: read the document, classify it, extract the fields, judge how confident it is, decide which queue and which person the work should go to, and predict whether a claim is likely to be complex or to end in a dispute. Deterministic rules do adjudication: eligibility, coverage, pricing, limits, the decision itself.

This is not caution for its own sake. It is because a claims decision has to be explainable to the claimant in a letter, reproducible months later when somebody asks, and consistent across two claims with the same facts. Rules give you all three by construction. A learned model gives you none of them without a great deal of extra machinery, and the value it adds at the decision step is usually small compared with the value it adds at the reading step, where the work actually is.

Keep the reconstruction requirement in the design from day one. For any claim, you should be able to retrieve which version of the rules ran, what inputs the rules saw, what the extraction produced and with what confidence, which document each field came from, and who touched it. That is a versioned event log rather than a database of current states, and it is much cheaper to build at the start than to retrofit after somebody asks about a decision made eleven months ago.

Confidence thresholds are an economics decision

Every extraction produces a value and a confidence. What you do with them is where the money is, and it is usually decided by whoever configured the tool rather than by anyone who knows what an error costs.

Three bands. Above a high threshold, accept automatically. Below a low threshold, send to full manual handling. In between, present the extracted value next to the document image for a one-keystroke confirmation, which is a few seconds of work rather than a few minutes.

The thresholds should come from arithmetic, per field. Compare the cost of an error on that field against the cost of a review of that field. A member identifier that is wrong causes a misrouted payment, a call, a correction and possibly a complaint, so it deserves a high bar. A free-text description that only feeds a search index can be accepted at a much lower one. Setting one threshold across all fields is the most common configuration and it simultaneously over-reviews the cheap fields and under-reviews the expensive ones.

Calibration matters more than raw accuracy here. A model that is right eighty-eight percent of the time and knows when it is unsure is worth more than one that is right ninety-three percent of the time and is confident about all of it, because the first can be routed and the second cannot. Check calibration explicitly: bucket by reported confidence and measure the actual accuracy in each bucket. If the ninety-percent bucket is right seventy percent of the time, every threshold you set is a fiction.

Step	Do it with	Why	Where it goes wrong
Classify and split documents	Model	Formats are open-ended and change without notice	Scoped as trivial; it is the hardest upstream step
Extract fields	Model, with per-field confidence	Layouts vary; templates break constantly	One global threshold across fields of very different value
Match to claim, member or policy	Rules plus fuzzy matching, human queue for ties	A wrong match is worse than no match	Auto-matching a low-scoring candidate to clear a queue
Eligibility, coverage, pricing	Rules	Must be explainable, reproducible and consistent	Pushed into a model because the rules were hard to write
Route and prioritise	Model	Predicting complexity and effort is a real prediction task	Optimising for queue length rather than for outcome
Draft the correspondence	Templates, with a model as a drafting aid	The letter is the record; it must say what was decided	Free generation of language that has to be exact

The exception queue is the product

Automation does not remove work. It sorts work, and everything the machine will not take lands in one place. That place decides whether the programme succeeds, and it is routinely treated as a leftover.

Design it deliberately. The reviewer should see the document image and the extracted value side by side, with the source region highlighted, so verification is visual rather than a hunt through pages. Corrections should take one keystroke, not a form. Every correction should be captured as labelled data with the original image, because that stream is the cheapest training set you will ever get and most operations throw it away. Items should carry the reason they landed there, so you can rank causes by volume and go fix the top three.

Watch the queue's age distribution rather than its length. A queue of two hundred items where nothing is older than a day is healthy. A queue of two hundred where forty items are three weeks old is a queue with a category of work nobody knows how to handle, and it will keep growing quietly until somebody looks.

Give it a staffing rule, too. The failure we see most is an exception queue that grows during the day and is cleared by whoever is free at four o'clock, which means the oldest and hardest items are always worked last by the least prepared person.

The pilot succeeds. Then the tail arrives.

Claims volume is concentrated and complexity is not. A handful of claim types typically carry most of the volume, and that handful is what a pilot is built on, which is why pilots work. The rest of the volume is spread across a long list of types, each rare, each with its own quirks, and collectively it can carry the majority of the exceptions and most of the dollars in dispute.

Plan for that from the start in three ways. Scope the pilot to a defined slice and say so out loud, so nobody reads eighty-five percent on three forms as eighty-five percent overall. Build the tail path first rather than last, meaning the route by which an unrecognised document reaches a competent human quickly and cleanly, because that path is what carries every future surprise. And set the rollout expectation honestly: the second half of the volume usually costs more than the first half, and a plan that assumes otherwise will be late in a way that damages trust in the whole programme.

There is also a human curve to plan for. Experienced processors slow down for a while when the work changes shape, commonly for a month or two, because they are checking the machine as well as doing the work. That dip is normal and it is not evidence the system is bad. Say it in advance, or somebody will discover it in week three and read it as failure.

What to measure

Straight-through rate, defined strictly. A claim is straight-through only if no human touched it from receipt to final disposition. A claim that auto-adjudicated and then pended for a document is not straight-through, and counting it as one is the most common way these programmes report success they have not achieved.

Touches per claim and cost per claim, both segmented by claim type and intake channel. This is the number the business case was built on and it is the number that should be tracked.

Cycle time at the median and the ninetieth percentile. The mean hides everything. Complaints, escalations and interest costs come from the tail, and an operation can improve its mean while its ninetieth percentile gets worse.

Rework and error rates from a sampled audit. Pull a random sample every month and have a person adjudicate it independently. Automated accuracy figures measure agreement with whatever the system produced; only a sampled audit measures whether the answer was right.

Exception queue age distribution, and the top reasons items land there, ranked by volume and by hours consumed.

What we find in the first two weeks

• Straight-through rate counted loosely, with pended claims included in the numerator
• Document splitting assumed solved, and the multi-document fax discovered in week five
• One confidence threshold for every field, whatever an error on that field costs
• Reviewer corrections discarded, throwing away the best training data in the building
• Adjudication logic drifting into the model because the rules were hard to write down
• No way to reconstruct a decision from six months ago with the rule version that produced it
• Cycle time reported as a mean, so the claims causing complaints are invisible
• The exception queue treated as overflow rather than as a staffed part of the operation

A build order that survives contact

Step two is the one that gets skipped and it frequently pays for the whole programme. A missing-document loop that takes nine days because the request goes out by post, or an intake form that lets a submitter omit a required field, are process defects that a week of ordinary work will fix. Automating around them instead means paying to industrialise a mistake.

When you do not need software for this

Below a few thousand claims a month, a full automation programme rarely pays. What does pay is smaller and duller: fix the intake form so the commonest missing field cannot be left blank, replace the paper request loop with an electronic one, publish a checklist to the partners who submit the messiest work, and work the top three pend reasons until they stop being the top three. That is weeks of work rather than quarters and it will often halve the touches.

It is also worth being honest about the other direction. If your claims system is being replaced in the next year, build nothing deep against the current one. If the real problem is that decisions are inconsistent between processors, the answer is written rules and calibration, not extraction. And if what you actually need is fraud detection, treat it as its own programme with its own data and its own review process, because bolting it onto a throughput project produces a system that is mediocre at both.

Build when volume is high enough that a few seconds per claim is real money, when intake is genuinely varied, when the exception queue is already the bottleneck, or when you cannot answer basic questions about where time goes. Those conditions are common, and where they hold the returns are large and durable.

Before it touches a live claim

• Touch study completed, with cost and hours per claim type and channel
• Straight-through rate defined strictly and agreed in writing
• Evaluation set drawn from real intake, faxes and photographs included
• Per-field confidence thresholds derived from the cost of an error on that field
• Calibration measured, not assumed, and re-measured after every model change
• Adjudication in rules, versioned, with the version recorded on every claim
• Any decision reconstructable: inputs, rule version, extraction, confidence, people
• Exception queue staffed, aged, and instrumented by reason
• Reviewer corrections captured as labelled data and flowing back into training
• Shadow run against live volume, with a sampled human audit before cutover

Bottom line

Claims automation pays, and it pays for reasons that have little to do with the model everyone demonstrates. The money is in reducing how many times a person opens a claim, and most of that is intake, routing and a well-designed place for the work the machine will not take. Let the model read and route; let rules decide, so the answer can be explained and reproduced. Set thresholds from what an error costs. Measure straight-through strictly, cycle time at the ninetieth percentile, and accuracy from a sampled audit rather than from the system's own agreement with itself. Do those and the tail is manageable. Skip them and you will have a very good pilot and a rollout that never lands.

Frequently asked questions