Tell the client what is missing. Once.

Most of the delay in client work is not the work. It is waiting for six documents, four of which have arrived, while nobody on either side can see which two are missing without asking.

A checklist fixes that by putting the state where both people can see it.

Quick facts

Why the visible part matters

The difference between a checklist you keep and a checklist the client can see is the whole feature.

When only you can see the state, every step forward requires you to notice a gap, write a message, and wait. The process runs at the speed of your follow-ups. The client, meanwhile, has no way of knowing whether Thursday's upload arrived or was the right thing, so the rational move on their side is to wait for you to speak. Two people are now each waiting for the other, which is how a two-day task becomes a three-week one.

When the client can see it, the chase becomes asynchronous. They open the portal at some random moment - between meetings, on the sofa, at the point where they happen to be holding the document - see two items outstanding, and deal with them. That moment almost never coincides with your scheduled reminder, which is exactly why the reminder was a poor mechanism.

What it changes in practice

Fewer reminders, and better ones. You stop sending "just checking on those documents" and start looking at which portals are still incomplete. When you do write, it is about a specific item rather than a general nudge. If you'd rather not write it at all, an opt-in reminder can nudge the client after seven days of inactivity and escalate to you after fourteen.

No duplicate requests. The most damaging small failure in document collection is asking for something the client already sent. It reads as not paying attention, and it makes the next request slower. If the state is visible, it cannot happen.

The client can start where they like. A six-item list is not one task. Being able to clear items individually, in any order, over several days, matches how people actually deal with paperwork.

Feedback lands on the document. When something needs redoing, the comment goes on that file - "this statement is missing the page with the address" - rather than in an email about "the documents" that the client has to decode.

How to write a good list

The mechanism is only half of it. The wording decides whether the list gets completed.

• Only ask for what you will use. Clients estimate effort from the number of lines. Two speculative items can be the difference between starting tonight and deferring to a weekend that keeps not arriving.
• Name each item the way the client would. Not "PoA" or "SOF". "Proof of address - a utility bill, council tax letter or bank statement from the last three months showing your name and address."
• State what makes it acceptable. Which months, whose name, all four corners visible. This prevents the round trip where the wrong thing arrives.
• Flag the item that depends on somebody else. A reference, a certificate from a registry, an official translation, a file held by a previous adviser. That one sets the real completion date and clients almost always leave it until last.
• Say why, for anything that feels intrusive. One sentence. "We need three months of statements to verify the deposit; only I will look at them." Clients sometimes go quiet because a request feels exposing, and they will not tell you that is the reason.

There is a longer version of this, with starting lists for several professions, in our client onboarding document checklist.

What it is not

Being precise about the boundary is more useful than a longer feature list.

It is not a workflow engine. A list per client and a status per file. No branching, no routing, no conditional logic, no task assignment.

Its only automation is one opt-in reminder ladder. The design intent is that the client can see the state themselves, so most of the chase moves off you by default. When a checklist sits untouched, that visibility can be backed by a reminder: after seven days of client inactivity, an email nudges the client naming the specific items still missing; after fourteen days it escalates to you instead, so a genuinely stuck client surfaces on your side rather than getting nudged forever. It's a per-business toggle, off leaves the checklist exactly as visible-but-silent as before, and it does not replace writing a specific message yourself when that's what the situation needs.

It does not verify anything. It records that a document was provided against a request. Whether the passport is genuine, the statement covers the right period, or the certificate has expired is your judgement or your screening provider's. Droplana is a collection layer, not a verification service.

It is not a form. Clients upload documents against items. They do not fill in fields, and there is no structured data capture.

It does not merge files. Six photographed pages arrive as six items. Combine them yourself if you need one file - you have the tools and the client does not.

Where it fits

The checklist is the reason most accounting practices, legal firms, brokers and consultants use Droplana at all, because for them the painful direction is inbound rather than outbound. Sending work out was never the hard part.

Each client also gets per-file comments, a status on every file, and in-browser PDF signing in the same portal, so a request, its answer, the discussion about it and the signature all live in one place per client.

For the wider argument about why the receiving direction is harder than the sending one, see collecting files is harder than sending them. For what a client portal is generally and how to evaluate one, see the client portal guide.

Check our simple pricing (or start free)

Storage levels and team seats scale with your plan.
Security, per-client encryption, isolation, in-browser PDF signing, and data export are the same on every plan.
No per-client fees. Tax calculated by Creem at checkout.

See who uses Droplana