Automation for · Document intake
Automation for document intake.
Documents arrive by email, by chat, by upload and occasionally by photograph. Somebody reads each one, decides what it is and whose it is, renames it, files it, and updates the thing that tracks whether it arrived at all.
That work is invisible while it is being done and extremely visible the day a document cannot be found.
What this usually looks like
One process, whatever the channel.
- 01 Every inbound document captured from whichever channel it arrived on BUILT
- 02 Classification by rule where a rule is reliable, by model where it is not BUILT
- 03 Deduplication against a shared registry before anything is filed BUILT
- 04 Filing to the right record, with the history backfilled BUILT
The model is never allowed the final say on anything that matters, and the new process starts with the past rather than beside it.
What happens when it breaks
A classifier that is confident and wrong.
A classifier that is confident and wrong is worse than one that refuses, so the design question is not accuracy, it is what happens to the cases it should not decide. Those go to a person, deliberately, and that path is built first.
The rest is ordinary engineering done properly: one error handler, one alert to one person, retries where a retry helps, and the work in flight preserved so recovery is catching up rather than reconstructing.
A professional services firm moved its document intake onto this. Its registry now holds 2,417 filed documents across email and WhatsApp, deduplicated against one another, and the history was backfilled into the correct client records so the new process started with it rather than beside it. Read the case
Everything arrives somewhere
Who reads every document before anything happens?
Tell me how documents reach you and what has to happen to each one. I will tell you what I would automate first and what should stay with a person.
Tell Dan on WhatsApp (opens in a new tab)or email dan@burdetsky.xyz