Multi-Account Document Gathering

Start by separating the two kinds of item, because they behave differently. Per-person items — identity document, proof of income, bank statements, employment details — must be supplied once by each party. Shared items — the tenancy agreement, the property listing, a joint account statement — need supplying once for the whole case, by whoever holds them.

Ask for per-person items by name, not by role. "Proof of income" addressed to a household produces one person's payslips and an assumption that the other is covered; the same request addressed individually to each named applicant produces both.

Say who is responsible for each shared item at the moment you ask. An item that belongs to "the applicants" collectively belongs to nobody, and it will be the last thing to arrive on every case you run.

Yes — and this is a privacy requirement, not a convenience. Co-applicants are frequently not in a relationship of full financial disclosure: flat-share tenants, business partners, separating couples, adult children supporting a parent. One shared login shows everybody everybody else's payslips.

A per-recipient magic link solves it cleanly. Each person opens a list containing only their own requested items, uploads against those, and never sees another party's documents. Your team keeps the single consolidated view, because the split is on access, not on storage.

It also fixes the bottleneck. When the link goes to one "lead" applicant who must forward everything, that person becomes an unpaid administrator and the case moves at their pace. Give each contributor their own entry point and the work happens in parallel.

By reading completion per person rather than per case. A case that shows 70% complete tells you nothing actionable; the same case showing applicant A at 100% and applicant B at 40% tells you exactly who to contact and about what.

That also changes what you send. Reminders addressed to everyone when one person is outstanding train the compliant party to ignore you, which costs you more on the next case than the delay you were chasing. Per-person status makes targeted reminders possible — the same logic as item-level status and feedback.

Give your team the consolidated view in one screen: every party, every item, every state. If someone has to reconcile two lists to answer "can we proceed?", the tool has moved the coordination problem rather than solved it.

Decide in advance whether a shared item is satisfied by one submission or by each party's copy, and encode that in the request rather than in your head. A joint bank statement is one item; two individual statements from the same joint account are two items that happen to look alike.

Duplicates are usually a symptom of an unowned shared item — both parties saw an unassigned request and both acted. Assigning the owner when you create the request removes most of them, and it is cheaper than deduplicating afterwards.

When a genuine duplicate does arrive, keep one as the accepted document and mark the other as not required rather than deleting it silently. The contributor should be able to see that what they sent was received and simply not needed, or they will send it again.

Define "complete" as every item in an approved state — not as every item received. Files stall at the end because receipt was treated as completion, and the review then surfaces two rejections after the parties have mentally finished.

Review items as they arrive, in parallel, rather than in one pass at the end. Each rejection then reaches the person who can fix it while they are still engaged with the case, which is worth several days on a multi-party file.

Then close access deliberately. When the case completes, contributor links should stop working, and each party should get a clear statement that nothing further is expected — otherwise you will field "do you still need anything from me?" for a fortnight. A workspace where everyone can see the state makes that final message unnecessary for most cases.