Certificate, renewal and application intake: confidence-gated document extraction feeding an n8n workflow that writes into the agency management system, with everything under the bar going to a human with the source page highlighted.
A commercial-lines insurance brokerage: 40 staff, roughly 2,600 active policies across a dozen carriers. The work that was drowning them was not sales and not claims. It was paper arriving in email — certificates of insurance, renewal packets, endorsements, loss runs, carrier declarations — and a person opening each attachment and retyping fields into the agency management system, one window on each side of the screen.
Measured over three weeks: about 340 inbound documents a week across seven recurring types, at a median of 11 minutes of handling each. That is roughly 1,900 hours a year of a human being a very expensive optical character reader. Their previous attempt at fixing it — a template-based OCR product — had been abandoned because every carrier laid its forms out differently and a form redesign broke the template silently, which is worse than not having it.
We usually recommend document intake as a company's first AI project, for three reasons that have nothing to do with the technology. The work is high-volume and low-variance. The output is checkable in seconds — a human can see at a glance whether a policy number is right. And an extraction error is almost always reversible, unlike, say, an incorrectly cancelled contract. It is the ideal place for an organisation to learn what supervised autonomy feels like before touching anything customer-facing.
The first step is not extraction, it is deciding what the document is — and, crucially, being allowed to say "I don't know". Unknown document types go to a human queue rather than being forced into the nearest matching schema, which is exactly the failure mode of the template system they had before. Unknown-type rate settled around 4%, and reviewing those was how we found two document types nobody had told us about.
This is the design decision that makes the whole thing work. A single confidence score for a document is nearly useless: a certificate can have a perfectly legible policy number and an ambiguous additional insured clause. So every field carries its own confidence and its own source coordinates on the page.
{
"doc_type": "certificate_of_insurance", "doc_confidence": 0.99,
"fields": {
"policy_number": { "v": "GL-8842-119", "c": 0.99, "page": 1, "bbox": [...] },
"effective_date": { "v": "2026-03-01", "c": 0.98, "page": 1, "bbox": [...] },
"each_occurrence": { "v": 1000000, "c": 0.97, "page": 1, "bbox": [...] },
"additional_insured": { "v": "Harbor Point LLC, its officers…",
"c": 0.71, "page": 2, "bbox": [...] }
},
"gate": { "auto_write": ["policy_number","effective_date","each_occurrence"],
"to_human": ["additional_insured"] }
}Fields above the threshold write automatically. Fields below it go to a review screen showing the proposed value next to the cropped region of the source page it came from. The reviewer is not reading a PDF and typing; they are confirming or correcting one highlighted value. That is the difference between 11 minutes and about 40 seconds.
We ran 1,200 historical documents whose correct values were already known, and plotted accuracy against confidence per field type. That gives a real curve, and the threshold is chosen from it against an agreed error budget rather than picked because 0.9 sounds high. Some field types settled at 0.995; the messier free-text ones never cleared the bar at all and are permanently human-reviewed. Both outcomes are fine and both are written down.
The workflow — mailbox trigger, classify, extract, gate, review, write, notify, file — is an n8n workflow, and that was a deliberate choice against our own instincts. Their operations lead is technical enough to read and edit a visual workflow and not technical enough to maintain a Python service. Six months after handover, the thing that matters is whether they can add a new carrier's form themselves. They can. We have built the same pipeline in Temporal for clients where the reliability bar was higher and a platform team existed to own it; the right answer is the one that survives your team, not ours.
The pieces that were not left in n8n: the extraction service, the confidence gate, and the writer that talks to the agency management system. Those are versioned code with tests, because a silent change to a threshold is a compliance problem and a visual editor makes silent changes easy.
Brokers get the same document emailed by the insured, the carrier, and the certificate holder, often days apart, sometimes slightly modified. Every document is content-hashed and every write is keyed on (policy, document type, effective date), so a duplicate is recognised and reconciled rather than creating a second record. A changed version of a previously processed document raises a diff for a human, which turned out to catch several mid-term endorsements the manual process had been missing entirely.
| Measure | Baseline | Week 9 |
|---|---|---|
| Median handling time per document | 11m 0s | 1m 10s |
| Documents fully auto-processed, no human | 0% | 57% |
| Documents with 1–2 fields reviewed | 0% | 36% |
| Documents fully manual | 100% | 7% |
| Field-level accuracy on auto-written fields | — | 99.4% |
| Backlog age at month end | 6–9 days | same day |
Modelled against the baseline, that is on the order of 1,500 hours a year returned. The brokerage redeployed it into renewal outreach, which is revenue-generating work their producers had been skipping. Running cost is a few hundred dollars a month in model spend; the expensive part was, as always, the integration with the agency management system, which had no usable API and required a supported but undocumented import path.
It is the cheapest, safest, fastest-paying automation there is, and it is where we usually start.