Replace WeTransfer Dropbox for Clients

Both tools are good at one job: getting bytes from A to B when email attachments are too large. WeTransfer shines for one-off handoffs; Dropbox shines when collaborators already share a workspace. Neither is designed to express "we need these eight evidence items, in this order, from these people, before we can proceed."

Document collection fails when the request itself is ambiguous. A transfer link says "send us files." It does not say which files, in which format, for which decision, or what happens if the scan is unreadable. Your team then spends the case translating uploads back into a mental checklist.

If your process already has named requirements — identity, income proof, signed forms, property extracts — the transfer tool is the wrong layer. You need a request object with items, not a pipe for anonymous blobs.

A Dropbox folder labelled with a client name looks organised until two people upload the same passport under different filenames, a guarantor drops a zip of mixed scans, and nobody marks which checklist line each file satisfies. Storage hierarchy is not completion status.

A client file is a set of decisions against named items: received, needs update, approved, not required. Folders only answer "is there a file somewhere?" They cannot answer "is the income proof for applicant B still outstanding?" without a human reading every object.

That human reading becomes the bottleneck. Reviewers open zips, rename files, chase clarifications in email, and paste status into a spreadsheet that drifts from the folder within a day. The portal model keeps the checklist as the source of truth and treats uploads as attachments to items, not as the file itself.

WeTransfer downloads expire. Dropbox shared links get forwarded, bookmarked, and left open after a case ends. Both create operational and privacy debt: either the file disappears when you still need it, or access outlives the reason you granted it.

Client intake needs the opposite pattern — access tied to the case and the contributor, with a clear end. Magic links to a personal checklist give each person only their items for as long as the case needs them, without a permanent shared folder that every forward multiplies.

When a transfer expires mid-review, someone asks for a resend and the version history fragments across inboxes. When a Dropbox link is still live after closing, you have standing access you may no longer intend. Neither failure mode belongs in a regulated document collection flow.

Rejection is where transfer tools quietly collapse. A blurry ID in a WeTransfer package usually triggers a new email: "please send again." The client does not know which file failed, and the second package often repeats the first mistake plus three extras.

Item-level feedback keeps the request intact. The reviewer marks one checklist line as needs update, adds a short note ("crop shows only the top half of the card"), and the same portal item stays open for a replacement upload. Other approved items stay approved; nobody rebuilds a zip.

That loop is the difference between a pipe and a validation portal. Collection without a decision step just moves risk into the next stage — underwriting, signature, or filing — where a missing page is more expensive.

Do not flip every open case overnight. Start with new intakes: publish a checklist template, invite contributors with individual links, and keep WeTransfer/Dropbox only as an escape hatch for the first fortnight while you watch where people get stuck.

For in-flight cases already mid-transfer, finish them on the old path or migrate only the outstanding items — never force a client who already uploaded a complete zip to re-enter everything. Capture those files against checklist lines once, then close the transfer channel for that case.

Tell clients the change in one sentence they can reuse: "use this link; it lists exactly what we still need." Internal teams need a matching rule: no new client document requests via personal Dropbox or WeTransfer once the portal template is live. Exception paths should be rare and logged.