Why Document-Automation Projects Stall — and What It Takes to Rescue One
TL;DR: Document-automation projects rarely die of a bad idea. They die because one boring layer — usually OCR — never quite works, and the impressive machinery built on top of it never gets to run end to end. We were brought into an EU flight-compensation firm as a task force to finish exactly that kind of stalled pipeline. We did not rebuild it. We fixed the layer that was broken, hardened the flow around it, and cut it over. If your automation project has been "almost done" for months, this post is about you.
There is a specific kind of project failure that almost nobody writes about, because it is embarrassing and undramatic.
The project was not too ambitious. Nobody chose the wrong model. There was no architectural catastrophe. Someone built a genuinely reasonable document pipeline — ingestion, classification, extraction, a CRM write-back — and it has been ninety percent done for six months, and it has never once processed a real document from one end to the other.
That is not a rare story. In back-office automation it might be the most common one. And when we were called into an EU261 flight-compensation firm, that was precisely the situation waiting for us.
//The shape of the failure
The firm handles claims under EU Regulation 261/2004 — the rule that entitles passengers to compensation for delayed and cancelled flights. That business runs on incoming paper. Objection notices. Court-cost invoices. Handover letters. Booking confirmations. Customer claim forms. A constant stream of PDFs, every one of which had to be read by a human, identified, and keyed into the CRM by hand.
They knew this was automatable. They had already tried. A pipeline existed.
It had stalled on OCR.
The OCR engine never worked reliably, and because nothing downstream could trust its output, nothing downstream ever really ran. The classifier was there. The extraction logic was there. The CRM integration was there. All of it sat behind a layer that could not consistently turn a scanned page into text — and so the whole apparatus was, functionally, decorative.
This is the pattern. The glamorous parts of a document pipeline are not where these projects die. They die at ingestion, at OCR, at the unsexy plumbing that everyone assumes is a solved problem and nobody wants to own. Classification is a fun problem. Prompt design is a fun problem. Making a smudged fax reliably become text is not, so it gets deferred — and it turns out to be load-bearing.
//Rescue, not rebuild
The instinct when you inherit a stalled system is to throw it away. It is almost always the wrong instinct, and it is usually ego dressed up as engineering judgment.
We were engaged as a task force with a deliberately narrow mandate: finish, fix, and cut over. Not rebuild. The prior team's model of the domain was sound — they understood the document types, they understood the CRM. What they had was one broken layer and no path to production, and those are two different problems from "this design is wrong."
So we fixed the OCR layer first, because until that worked nothing else could be evaluated at all. You cannot debug a classifier that is being fed garbage. Getting the foundation honest is what turns every downstream question from a guess into a measurement.
Then we hardened the flow around it into a single async pass: OCR, a keyword pre-filter, classification, summarization, field extraction, and a CRM-ready result at the end. One pass. One path. Not a constellation of half-connected services that each work in isolation and never in sequence.
//Three decisions that made it survivable
Do not OCR what you do not have to. Roughly half the incoming PDFs were born-digital — they already contained a text layer, put there by whatever system generated them. Running heavyweight vision OCR on those is pure waste. A triage step reads the text layer directly and skips OCR entirely. Half the work simply stopped existing, which is the cheapest performance win available to anyone processing documents at volume.
Keep the brain away from the credentials. The component that opens untrusted attachments — files arriving from the outside world, from anyone — holds no CRM credentials at all. It cannot write to the CRM even if it is compromised or confused. Results travel back over HMAC-signed callbacks to a separate workflow, and that workflow is the only thing in the system permitted to touch case data. This is not paranoia; it is the minimum posture for any system whose input is "a PDF a stranger emailed us."
When in doubt, ask a human. The classifier handles six document types plus an explicit "unknown" bucket. Anything low-confidence or unrecognized is routed to a person for review rather than written into the CRM. This is the decision that most distinguishes a system you can actually deploy from a demo that looks impressive.
That last one deserves more than a bullet.
//The bar is not accuracy. It is "no bad writes."
Here is the thing people get wrong when they evaluate document automation: they obsess over accuracy percentages, as though the goal were a high score.
The goal is not a high score. The goal is that the system never silently corrupts your data.
A pipeline that correctly processes 95% of documents and confidently mangles the other 5% into your case records is not 95% good. It is a liability, because now every record in your CRM is suspect and no human can tell which ones. You have not saved any work; you have converted a data-entry task into a far worse auditing task.
A pipeline that processes 80% and hands the remaining 20% to a human, clearly flagged, is genuinely useful — because the 80% is trustworthy and the 20% is honest about itself. Our headline result on this project was not an accuracy figure. It was one pass, zero bad writes: well-formed documents flow through automatically, and garbage or uncertain input gets flagged for a person instead of poisoning the case data.
Optimise for the floor, not the ceiling. Nobody ever got fired because the automation asked for help.
//If your project is stuck right now
A few questions worth being honest about:
- 1Has it ever run end to end, on one real document, in production? Not in a notebook. Not on the happy-path sample. If the answer is no, the pieces that "work" have not actually been tested, and your completion estimate is fiction.
- 2Which layer is everyone quietly avoiding? There is usually one. It is usually ingestion or OCR. It is usually the thing nobody put on the roadmap because it seemed too basic to warrant a ticket.
- 3What happens to a document the system does not understand? If the answer is anything other than "a human looks at it," you do not have a safety story, and you should not go live.
- 4Could the component that opens untrusted files write to your database? If yes, fix that before you optimise anything else.
A stalled project is rarely as far from done as it feels. It usually just needs someone willing to own the boring layer.
For the full architecture — the pre-filter that primes but never overrides the classifier, the callback design, and how the pieces fit — read the technical deep dive.
Sitting on a document-automation project that has been almost finished for months? See the full case study or tell us where it is stuck.