Document processing

What this problem is

Document processing is the repeating work of receiving files — contracts, forms, certificates, packs — and turning them into something the next person can act on: fields, a checklist, a filing location, or a decision pack. It is not “AI for documents”. It is an operational pipeline with controls.

Is this your problem?

• Files arrive by email and wait in personal downloads folders
• Someone re-types the same fields into a spreadsheet or CRM
• Version confusion: two people work from different PDFs
• Missing pages or signatures are found late
• Retrieval means searching Slack, email, and a drive with three naming schemes

Current workflow

A document arrives as an attachment. A coordinator saves it somewhere, skims it, copies key fields, and pings a colleague if something is missing. Naming is improvised. The “latest” file is the one in the most recent email. Exceptions sit with whoever last touched them.

Where it fails

• No intake: documents never become cases
• Extraction is re-typing, so errors and delay travel together
• There is no completeness check against a required pack
• Access and retention are accidental, not designed
• Downstream systems are updated by copy-paste, so they drift

How to measure the baseline

Count documents or packs per week, minutes from receipt to a complete structured record, error rate on sampled fields, rework hours, and exception rate. Use cases_per_week, minutes_per_case, error_rate_pct, rework_hours_per_week, and exception_rate_pct. Sample for accuracy; do not assume extraction quality from a demo.

Metrics that matter

• Cases per week — Volume of discrete items (leads, invoices, tickets) in a typical week. (cases/week)
• Minutes per case — Average handling time from pickup to completion of one case. (minutes)
• Error rate — Share of cases that contain a defect requiring correction. (%)
• Rework hours per week — Time spent correcting errors or re-doing work in a typical week. (hours/week)
• Exception rate — Share of cases routed to human exception handling. (%)

Root causes

• The organisation never listed what a complete pack contains
• Storage is a drive, not a record with status
• Only one person understands the document type
• Tools were bought for filing, not for workflow
• There is no review step, so people either over-check everything or trust nothing

What should be automated

• Intake that stores the original file with an immutable copy
• Suggested extraction of known fields, with confidence visible
• Completeness checks against a required list
• Routing of incomplete packs back to the sender or an owner
• Write-back of approved fields to the system of record

What should remain human-controlled

• Anything that creates a legal, financial, or safety commitment
• Review of low-confidence fields
• Interpretation of unusual clauses or poor scans
• Retention and access decisions that policy has not already settled

Example intervention architecture

Illustrative only — not a client result. A drop-zone or mailbox creates a case and stores the original. Extraction proposes fields. A completeness checklist shows what is missing. High-confidence, low-consequence fields can batch-review; high-consequence fields always stop. Approved data writes to CRM, finance, or a case system. People still decide; the pipeline removes hunting and re-typing.

Failure modes

• Treating model output as ground truth
• Writing extracted data over a correct human record
• Processing documents you have no right to retain
• A queue nobody monitors
• Formats that were never in the test set, silently skipped

When not to automate

• Volume is low and documents are genuinely unique each time
• You cannot store the files lawfully
• There is no system of record to write into
• Quality of scans is so poor that typing is still faster after review
• No one will own exceptions — unread queues are worse than email

Related problems

• Invoice intake

Sources

• ICO guidance for organisations (UK data protection)
• NCSC cloud security guidance