How to request documents from clients, and chase them without nagging

Why documents arrive late

A client who is busy running a business does not ignore you on purpose. Late documents usually come down to four things:

• They do not know exactly what you need. “The usual documents” means something different to every client.
• They do not know by when. Without a date, “when I get a minute” becomes the date.
• They do not know where to send it. Email, a messenger, a portal, a paper folder: when there are several routes, the file waits.
• They cannot see what is still missing. After one partial reply, nobody is sure what is outstanding, including you.

A good request answers all four. A good follow-up repeats the answer, only shorter.

Ask for a specific list and one date

Write the request as a list of items, not a paragraph. Each item names the document, the period and the format. A good request has five parts:

• The items. “Bank statement, October, PDF” rather than “bank statements”.
• One due date. Not “soon” and not “by the deadline”. Pick a date several working days before your own filing deadline, so you have time to check what arrives. If a return is due on the 25th, ask for the documents by the 12th or the 15th.
• The reason, in one line. “For the October VAT return.” People answer faster when they see what depends on it.
• One place to send it. A single link or address, the same every month.
• What done looks like. “If there were no sales this month, tell us and we will mark it as nil.”

Want a ready-made list to start from? See the document request list template.

Pick the channel the client already answers

Email, a client portal and a messenger such as Telegram can all work. What matters is that the client actually opens it, and that you send the request once, not three times.

• Use the channel where this client already replies. You know who answers email in minutes and who only reads chats.
• Follow up in the same channel as the request. Switch only when you escalate to a call.
• Keep the list somewhere the client can come back to. A message scrolls away. A page with the list and the date does not.

A chase rhythm that does not feel like nagging

Decide the rhythm once, for all clients, and stick to it. Clients stop taking it personally when it is the same for everyone, and you stop deciding each time whether it is too soon to ask. This is a suggested rhythm, not a rule from any authority: adjust it to your clients.

If the filing deadline is close, compress the steps rather than skip them: the same order, with fewer days between.

Three messages you can copy

Edit the parts in brackets. Keep each message short enough to fit on a phone screen: that is the one that gets read.

Track what is missing, not who is late

Keep the list per request item, not per client. After a partial reply, the follow-up should name exactly what is outstanding, and that is only possible if each item has its own status.

• Mark each item as received, accepted or still missing. Received is not accepted: the file still has to be the right one.
• Say why a file is rejected. “This is the March statement, we need April” is one line. Silence costs another round.
• Keep the request, the messages and the files together. When a colleague opens the client, they should see what was asked, when, and what came back.

How this works in Claister

This is the routine Claister is built around. As the product works today:

• The request is saved to the client portal first, before any message goes out. The client sees the list and the date in one place.
• Claister prepares editable email and Telegram drafts. You choose the channel and press send. Generating a draft never sends anything.
• The send is recorded against the request. After three days without a newer send or a returned document, Claister offers an editable follow-up. You still send it yourself.
• Files that come back share one review queue, whether they arrive by portal, email or Telegram. Claister can suggest which request item a file belongs to. A person confirms or rejects it; it never attaches a file or closes a request on its own.

Client work: onboarding, documents and handovers