Turning a manual review into a model

The thing you are automating is almost never one decision

A manual review looks like a single job because one person does it end to end and describes it in one sentence: “Dana checks the invoices.” What Dana actually does is six or seven different things with very different automation profiles. Before anyone talks about models, sit with Dana for a day and write down where the minutes go. That afternoon changes most projects.

The decomposition is usually: get the item; pull the facts out of it; check those facts against things that are written down; exercise judgment where the written rules run out; decide; record a reason; handle whatever is missing or weird. Only the fourth is model-shaped, and it is very often the smallest slice.

We expect a particular result: the judgment layer is ten to twenty-five percent of handle time, and most of the clock goes to opening files, retyping fields into a system of record, and chasing documents that did not arrive. That is plumbing, not machine learning — cheaper, faster, lower risk, easier to reverse. Do it first and you often find the backlog gone and the judgment work was never the constraint.

Measure the humans before you try to model them

Take two hundred items your team already decided. Strip the decisions off. Hand the same two hundred to two experienced reviewers, independently, and have them decide again. Then measure how often the two agree with each other, and how often each agrees with the original decision on record. That is a week of part-time reviewer effort and it tells you more than a three-month pilot.

The agreement rate is a ceiling. If your own experts disagree on one item in four, a model graded against one reviewer's answers cannot score much above seventy-five percent — and neither could a second human. An accuracy number above the human agreement rate is measuring something other than correctness, usually because the test set was labeled by the same process that produced the training data, so the model learned to imitate a labeler rather than to be right.

The range in practice: for tightly specified checks — does this invoice line match this purchase order, is this field present and well formed — agreement above ninety-five percent is normal, and less than that means the process is broken in a way worth fixing on its own. For genuine judgment calls — is this claim worth investigating, does this clause deviate from our standard — sixty to eighty percent is the band we expect, and the low end is common. That is not a criticism of the reviewers. It is what happens when a policy is applied by people who each learned it from someone slightly different.

Low agreement is a diagnosis, not a setback. When two good reviewers disagree a third of the time, the policy does not exist in written form. Nothing can be automated against a rule nobody wrote down, but writing it down is a two-to-four week project and it improves the human process whether or not you ever build software. Some of the best outcomes end right there: no model, just a decision standard and a review of the twenty hardest cases.

Stage of the review	Typical share of handle time	What it actually needs
Acquire the item	10–25%	Integration and file handling. No model. The best ratio of saved minutes to engineering hours.
Extract the facts	20–40%	Extraction with field-level confidence and a correction path. The failure mode is bad source documents, not bad models.
Apply written rules	10–20%	Code. Deterministic, testable, explainable. No model here.
Exercise judgment	10–25%	The model-shaped part, and the part needing an eval set, thresholds and an abstain path.
Record the reason	5–15%	Structured capture at the moment of decision. Cheap, and it is what makes the next model possible.
Handle exceptions	10–30%	A queue, an owner, a service level. Automation raises this share and plans rarely account for it.

Your history is not a training set

Everyone with a five-year archive of decided items believes they are sitting on free training data. Sometimes they are. More often the archive carries four contaminations, each producing a model that tests beautifully and behaves strangely in production.

The decision changed the record. Approved invoices get a ledger code, a payment date, a reference number. Declined ones do not. Train on the whole record and the model learns the consequences of approval rather than the reasons for it. It looks like a ninety-nine percent model until you feed it something undecided, which is the only case that matters.

You only see outcomes for the ones you said yes to. If the review is a gate, everything you turned away has no result. Declined applications have no repayment record; rejected vendors have no delivery history. The model learns only from the population your current process already liked, which is where it adds the least.

The reason is not in the record. A reviewer approved it because a colleague vouched on a phone call, or a photo arrived by text. The system stores “approved.” The model hunts for a pattern that explains it and finds a spurious one, because the real one was never written anywhere.

Policy moved. Decisions from three years ago were made under thresholds that have since changed twice. Train on the full archive and you teach the model an average of every policy you have ever had, weighted by volume.

The response is smaller than people expect. Build a fresh gold set: three hundred to eight hundred items, sampled to over-represent the hard middle rather than the obvious ends, adjudicated by your two best reviewers with ties broken by a third and a sentence of reasoning per item. Freeze it. Never train on it. It costs a few thousand dollars of expert time, outlives every model you put behind it, and is the only way you will compare a replacement vendor to the incumbent.

The numbers, in both directions

Start with what the current process costs, on one line: items per month, times average handle minutes, times a fully loaded hourly rate — salary plus payroll taxes, benefits and a share of management and tooling, generally 1.25 to 1.45 times base pay. Four thousand items a month at eleven minutes each is about 733 hours; at a fifty-five dollar loaded rate that is roughly forty thousand a month, a bit under half a million a year.

Then add the two costs nobody puts in the spreadsheet: what the misses cause downstream, and what it is worth that an item clears in four hours instead of five days. On some queues cycle time is the entire business case and the labor saving is incidental.

Against that, building. A narrow system — ingest, extraction, deterministic rules, a review interface, an audit trail, one integration — is commonly six to twelve weeks and sixty to a hundred fifty thousand dollars. Add a judgment layer with an evaluation harness, calibrated thresholds, an exception queue, monitoring and two or three integrations and it is three to six months and roughly one hundred fifty to four hundred thousand. Running costs land the opposite way from what people assume: inference is the smallest line, and queue tooling, monitoring and the humans still working exceptions dominate.

The test we apply before quoting: if the annual manual cost is under about one hundred fifty thousand dollars, custom engineering rarely pays back inside two years unless cycle time or error cost carries the case alone. Below that line the honest advice is to buy off the shelf, fix the intake, or leave it alone. We have given all three.

Two outcomes is the wrong design. Three is the right one.

The most common structural mistake is building a system that must answer every item. Give it a third option — approve, decline, and I am not sure, send this to a person — and everything else gets easier.

Once abstention exists, accuracy stops being the number that matters. The design object is a curve: at any confidence threshold, what share of volume does the system handle and how precise is it on that share? Deciding fifty-five percent of the queue at ninety-nine point three percent precision and routing the rest to people is a good system, and it is the shape most successful deployments take. Deciding all of it at ninety-two percent accuracy is a worse business outcome and a much better slide.

Two refinements are routinely skipped. Your error directions do not cost the same — a wrongly approved four-hundred-dollar invoice costs four hundred dollars, while a wrongly declined claim costs an appeal, a complaint, possibly a lawyer, and a customer who tells other people. Set the two thresholds separately, from the cost asymmetry. And on an imbalanced queue accuracy means little: if three percent of items are what you are hunting for, saying “no” to everything scores ninety-seven percent. Ask for precision and recall at a stated operating point, on a stated slice.

Insist on calibration too. A confidence score is useful only if items scored at 0.9 are right about ninety percent of the time, and plenty of models produce confident-looking numbers with no such relationship, which makes every routing rule built on them arbitrary. Half a day to check, and it belongs in the acceptance criteria.

Roll it out in four stages, and do not skip the first

Shadow. The system runs on live traffic and shows nobody anything, two to six weeks, while you compare its answers to the humans'. This is where the surprises arrive, because live traffic is never the scoping sample. Faxed pages. A supplier who changed their invoice template in March. A whole category nobody mentioned because another team handles it.

Assist. The reviewer sees the suggestion, the evidence behind it and the confidence, then makes the call. Handle time should drop. Watch for automation bias, which is not hypothetical: people shown a plausible answer stop reading the source. Inject a known-wrong suggestion at a low rate and measure how often it is accepted. Tell the team you do it — it stops being adversarial the moment it is transparent, and it produces a number you can act on.

Automate the confident band, with permanent sampling. Auto-decide above the threshold, route the rest, and pull five to ten percent of auto-decided items for human audit — forever, not for one quarter. Where nobody downstream reports errors, that sample is your only drift detector, and drift is not optional: suppliers change formats, customers change behavior, and your own policy changes without telling the model.

Give people a way to appeal. Any affected party can ask for a human look. It costs little, it is the right thing to do, and it is quietly the best data collection instrument you have: appeals are a curated stream of your worst failures, labeled by the people most motivated to be precise about why.

What happens to the reviewers, and why your dashboard gets worse

This is missing from nearly every plan we are asked to review, and it causes real trouble in month two.

Automation takes the easy items first, because those are the ones it is confident about. What is left in the human queue is the hard residue, so average handle time per item goes up — eleven minutes becomes nineteen — even as total cost falls sharply. An executive who was not warned that the per-item metric is expected to worsen will conclude the project failed at exactly the moment it started working. Change the metric before launch to cost per hundred items processed end to end.

Second, the work gets harder per hour. A reviewer who did forty items with a comfortable mix now does fourteen difficult ones back to back — more tiring, more error-prone. Plan for a smaller, more senior queue team rather than the same team doing less, and say so during planning.

Third, and least obvious: your senior reviewers became senior by grinding through thousands of easy items and gradually seeing the edges. Remove the easy items and you switch off the mechanism that produces the people who adjudicate the hard ones. Keep a rotation of routine items in front of newer staff. It looks like waste on a spreadsheet and it is not.

When you should not build this

These are the cases where we would say so in the first conversation, and where hiring anyone is the wrong move.

The rule is actually a rule. If the policy can be written as conditions and thresholds, write it that way. A model that reproduces a deterministic policy ninety-seven percent of the time is worse than an if-statement that does it every time, and harder to change when the policy moves.

The information is not in the system. If the judgment depends on a phone call, an email thread in a personal mailbox, or a photo texted from a job site, no model can see what the reviewer sees. Fix the intake first — often a smaller project with a bigger effect, and a prerequisite either way.

The volume is small. A few hundred items a month at a few minutes each does not fund a build. It might fund a better form, or an off-the-shelf tool and an afternoon of configuration.

The decision has to be explained to someone who can contest it. When a person can appeal, or an auditor can ask why, the explanation must be the actual reason rather than a narrative attached afterward. Extraction plus explicit rules gives that natively; a classifier's score does not, and text generated to justify a score after the fact is a liability, not an explanation.

Nobody will own the exception queue. Routing thirty or forty percent of volume to a human requires that the human exists, has time, and has an escalation path. Unfunded, the queue becomes a backlog, the backlog becomes pressure to raise the automation threshold, and the threshold gets raised for operational reasons rather than accuracy ones. That is how these systems actually fail.

The mistakes we see most

• Modeling before measuring reviewer agreement — the ceiling was knowable in week one for a week of effort
• Training on the full historical archive, including the fields that only exist because a decision was made
• A single accuracy number with no threshold, no slice and no baseline
• No abstain path, so the confident cases subsidize the hopeless ones
• Symmetric thresholds on a process where the two errors cost wildly different amounts
• Skipping shadow mode, and meeting the real document population in front of users
• Sampling audits for one quarter, then stopping, on a queue with no other error signal
• No plan for the reviewers, whose per-item metrics are now guaranteed to look worse

Before you start

• Someone sat with a reviewer and timed the stages
• Two reviewers redid two hundred items blind, and you know the agreement rate
• The decision standard exists in writing, or writing it is work package one
• A frozen gold set is adjudicated, reasoned, and never trained on
• The current process cost is on one line, with error and cycle time beside it
• The design has three outcomes, and abstention is one of them
• Thresholds are set from the cost of each error direction, separately
• Acceptance criteria name precision, recall, coverage and calibration
• Shadow mode is in the plan with a duration, not as an option
• Sampling audit is funded permanently, and the exception queue has a named owner

Bottom line

Most manual reviews can be substantially automated, and most of the value sits in the unglamorous parts: getting the item, pulling the fields, applying the written rules, capturing the reason. The judgment layer is real and smaller than it looks from outside. Measure your own reviewers first — their agreement with each other is the ceiling on anything anyone can sell you, and it is the cheapest number in the project. Build a small frozen evaluation set and treat it as the asset it is. Design for three outcomes rather than two. Then roll out slowly enough that the first surprise happens in shadow mode instead of in front of a customer.

And be willing to stop. A fair share of these investigations end with a written decision standard, a fixed intake and no model at all — a good outcome, reached for two weeks of engineering rather than two quarters.

Frequently asked questions