CASE STUDY · INTELLIGENT DOCUMENT PROCESSING (IDP)
Automating data entry for an insurance back office with IDP.
- 18→3 hoursManual entry down from 18 to 3 hours a week
- 94%94% field accuracy on the validation sample
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised insurer's back office. Name withheld under confidentiality.
Document classification, field extraction and validation, with an exception queue. The system reads incoming documents, decides what each one is, pulls the fields the case system needs, checks them against rules, and either posts the record or sends it to a reviewer.
- 1The team spent 18 hours a week on manual data entry.
- 2Claims and policy documents arrived by email and post, in many layouts, and staff re-typed the same fields into the case system.
- 3Errors surfaced late, usually when a claim was already in progress.
- 4The people doing the work were experienced enough that their time was better spent elsewhere, and nobody wanted to hire more people to type.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01Early accuracy was weak on scanned documents that had been faxed or photocopied several times
Extraction confidence looked fine, but the totals did not reconcile. We added a reconciliation rule that compared line items with stated totals, and a pre-processing step to straighten and clean low-quality scans. Documents that still failed the check now go to review with the failing rule shown.
- PROBLEM 02The lesson was that confidence scores alone are not enough
Business rules catch what the model cannot see.
03 · THE PROCESS
How we ran it.
- 01Discovery
We sampled real documents with the team and wrote down every field, where it appears and what a correct value looks like. Staff told us which fields they distrusted most, and we started there.
- 02Build
Short iterations with a demo each week on the team's own documents. Reviewers saw their feedback reflected the following week, which kept them engaged.
- 03Parallel run
The pipeline ran beside manual entry. We compared outputs daily and tuned rules before staff relied on it.
- 04Go-live
Document types moved over one at a time, simplest first, with a weekly review of accuracy and exceptions.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Staff review exceptions instead of typing every document.
- NOW 02
The team reads a weekly accuracy and exception report and decides which rules to tighten.
- NOW 03
New document layouts are added through a defined process, not by emergency re-keying.
- NOW 04
Reviewer corrections feed back into the system, so the same mistake is not fixed twice by hand.
- 18→3 hours
Manual entry down from 18 to 3 hours a week
- 94%
94% field accuracy on the validation sample
05 · WHAT WE BUILT
How it works.
- Capture from a monitored mailbox and a shared scan folder, with duplicate detection by file hash and key fields.
- A classifier routes each document to a type-specific extraction step.Unknown types go to the queue rather than being guessed.
- Extraction returns a value and a confidence score per field.Thresholds are set per field, not globally, because a policy number needs a stricter bar than a free-text note.
- Validation checks formats, cross-field consistency and lookups against the policy system.
- The exception queue shows the document image beside the extracted fields.Corrections are stored as labelled examples for later tuning.
- Posting is idempotent and fully logged, so every record can be traced back to its source document.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- The team spent 18 hours a week on manual data entry. Claims and policy documents arrived by email and post, in many layouts, and staff re-typed the same fields into the case system. Errors surfaced late, usually when a claim was already in progress. The people doing the work were experienced enough that their time was better spent elsewhere, and nobody wanted to hire more people to type.
- What did Brandsmashers build?
- Document classification, field extraction and validation, with an exception queue. The system reads incoming documents, decides what each one is, pulls the fields the case system needs, checks them against rules, and either posts the record or sends it to a reviewer.
- What were the results?
- Manual entry down from 18 to 3 hours a week; 94% field accuracy on the validation sample.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
