Most document AI writing starts after the file has arrived. The model, the schema, the confidence policy, the review queue — all of it assumes a document is already sitting in a bucket. In production that assumption is where projects lose the most time, because somebody outside your company still has to find the right document, photograph it well enough to be readable, and send it to you.
The collection step is not a form. It is the part of the product that decides how many cases ever reach the pipeline at all. An extraction engine with excellent accuracy sitting behind a portal that 40% of applicants abandon is a 40% loss that no model improvement can recover.
This is a description of what that layer has to do, and which parts of it are load-bearing.
Upload success is the wrong number
The metric almost every intake system reports first is upload success: of the files that were submitted, how many were accepted. It is easy to instrument and it is close to useless, because it conditions on the person having already succeeded.
The number that matters is case completion — of the requests sent, how many ended with every required document present and accepted. The gap between the two is where the product lives:
- Never opened — the request reached a dead address, a spam folder or a channel the person does not check.
- Opened, never started — the person could not tell what was being asked or how long it would take.
- Started, abandoned mid-way — a step failed, usually a camera step, and there was no obvious recovery.
- Completed, then rejected — the documents arrived and a reviewer sent them back, which restarts the whole loop days later.
Each of those is a different fix. Reporting only the last one, or only upload success, hides three of the four.
A checklist is a contract with a person
The unit of collection is not the file, it is the requirement. “Proof of address” is a slot with an owner, an allowed set of document types, a state and a history. The file is what eventually fills it.
Modelling it that way makes several things possible that a plain upload box cannot do. The most important is expansion by value. A process that needs an identity document for each beneficial owner does not have a fixed number of slots — it has one requirement that expands into as many slots as there are owners, each keyed to the person it belongs to.
Without that, the portal shows a generic list of upload boxes and the applicant guesses which is which. The reviewer then receives four identity documents with no reliable mapping to the four people, and reconstructs it by hand. That reconstruction is invisible in every dashboard, because from the system's point of view the case completed successfully.
Each requirement should carry a plain-language title, a description written for the person and not the reviewer, the document types it accepts, and whether it is mandatory for this case. The types matter: they are what lets the portal say “this looks like a bank statement, but this slot needs a utility bill” at the moment of upload rather than three days later.
The link is the session
Requiring an external party to create an account before they can send you a document is the single most expensive decision in the whole flow. They have no ongoing relationship with your software, they will never sign in again, and every credential you ask them to invent is a place to drop out.
A shareable link with a bounded lifetime replaces the account. That design has real consequences you have to accept deliberately:
- The link is the credential — anyone holding it can act, so it needs an expiry, a scope limited to one case, and a revocation path.
- Expiry has to be recoverable — an expired link that dead-ends is a lost case; it should offer a way to request a fresh one.
- The channel is part of the design — email, SMS and messaging apps have different reach and different failure modes, and the case state has to be the same across all of them.
- Access has to be auditable — who opened it, from where, when, and what changed, because this is the evidence trail for a document nobody watched arrive.
The commercial argument for the pattern is that it works on a phone in a parking lot. The engineering argument is that it makes the case, not the user account, the thing state hangs off — which is what you want anyway when a case can be handled by three different people at the applicant's end.
Rejection is a flow, not an email
The place where document collection systems most often stop being products is rejection. The documents arrive, a reviewer looks, one of them is unusable, and the system sends a message that says so.
That message is where cases die. The applicant receives prose describing a problem, has no live link, cannot see which of the six documents was the problem, and has to reply asking. Meanwhile the case sits in a state that reports as “submitted”.
Rejection has to reopen the same case, at the specific requirements that failed, with the reviewer's reason attached to the requirement it belongs to — not to the case as a whole. The person should see five accepted items and one that needs redoing, with the note visible next to it. Everything already accepted stays accepted.
Two details make the difference between a reopening that works and one that annoys:
- The reason travels with the item — a reviewer note attached to the case forces the person to guess which document it refers to.
- Reopening does not reset accepted work — asking someone to re-upload five good documents to fix one bad one is how a recoverable case becomes an abandoned one.
A reminder sweep closes the loop for the cases that go quiet. It is unglamorous and it is usually worth more than a model upgrade.
What the portal owes the pipeline
Everything above is about the person. The other half of the job is what the collection layer hands downstream. A file with no context forces the pipeline to re-derive facts the portal already knew.
| Carried forward | What it prevents downstream |
|---|---|
| Which requirement the file was submitted against | Classifying from scratch to find out what the file was supposed to be |
| The identifier for expanded items | Guessing which of four identity documents belongs to which owner |
| Capture conditions and quality signal | Blaming the extractor for a photograph that was never readable |
| Channel, timestamps and access events | An audit trail that starts only once the file reached storage |
| Prior rejections on the same requirement | Re-reviewing a document that a colleague already sent back once |
The expected class is the most valuable of these. Classification is still worth running — it is what catches the mismatch — but comparing a prediction against a stated expectation is a much stronger signal than a prediction alone. It turns “this is probably a utility bill” into “this was submitted as proof of address and does not look like one”, which is an actionable statement.
Build or buy is the wrong framing
Teams usually ask whether to build the portal or buy one. The more useful question is which parts are genuinely specific to your process.
The requirement model is specific. Your checklist, your expansion rules, your document types and your acceptance policy encode how your business actually works, and a vendor's fixed template will fight you. That part should be configurable by the people who own the process, without a release.
Almost everything else is not specific. Link issuance and expiry, multi-channel delivery, capture, quality feedback, reminder sweeps, reopening, access logging — every company that collects documents needs the same behaviour, and every company that builds it discovers the same six months of edge cases. Our own document collection portal exists because the customers who built it themselves kept arriving at the same list.
The first mile decides the rest
It is easy to treat collection as plumbing in front of the interesting part. The measurements do not support that. Completion rate moves with checklist clarity, link recovery and rejection handling far more than it moves with extraction accuracy, and a case that never completes produces no extraction to be accurate about.
Treat the first mile as a product with its own metric, instrument the four ways a case fails, and hand the pipeline everything the portal already knew. The rest of the system gets easier because it is finally being fed on purpose.