Ask an operations manager how much time their team spends chasing clients for documents and you will usually get an estimate, a sigh, and an assumption that this is simply what the work involves.
It is worth questioning the assumption. Chasing is rarely caused by clients who cannot be bothered. It is almost always produced by the way the request was made and the way its progress is tracked. Change those two things and most of the follow-up work stops existing.
What the chase actually costs
The visible cost is the reminder emails. The larger cost is the reconstruction that happens before each one.
Before a person can send a useful follow-up, they have to work out what the client has already sent. That usually means scrolling a thread, opening two or three attachments to check which version arrived, and comparing what they find against a list that exists in their head or in a spreadsheet. The message itself takes a minute. Establishing what to put in it takes ten.
Multiply that by every open matter, application or onboarding case and the cost stops looking like admin overhead and starts looking like a process defect.
It is worth doing the arithmetic on your own numbers. Take the number of open cases waiting on documents, multiply by the number of follow-ups each one needs before it closes, and multiply by the time it takes to work out what to put in each message. A team carrying sixty open cases, averaging three follow-ups each, at ten minutes of reconstruction per message, is spending thirty hours on establishing facts the system already knows. The messages themselves account for perhaps three of those hours.
That ratio is the useful part. When most of the cost sits in reconstruction rather than in communication, buying a faster way to send messages will not help. The saving comes from removing the need to reconstruct anything.
Cause one: the request was ambiguous
A request that reads “please send your ID and proof of address” is four decisions the client now has to make on your behalf. Which form of ID. Whether a photo is acceptable or it needs to be a scan. How recent the proof of address has to be. Whether a phone photograph of a bank statement counts.
Clients answer those questions reasonably and often differently from how you would have answered them. The result is a document that has to be rejected and requested again, which reads to the client as though they were asked twice for the same thing.
Naming each item separately, with its acceptable formats and any age limit, removes most of this. It costs a few minutes at the point of request and saves a cycle of correction on a meaningful proportion of cases.
Cause two: nobody shares a view of what is outstanding
This is the cause that most process improvements miss, because the person doing the chasing does not experience it as a problem. They know what is missing, more or less, and they can find out by checking.
The client cannot. From their side, they sent something a week ago and heard nothing. They have no way to tell whether they are finished, whether one item was rejected, or whether the firm is simply slow. So they wait, which reads to you as ignoring the request.
When both sides can see the same item-level status, the dynamic changes. A client who can see that three of five items are received and two are still open will usually close the gap without being asked. Visible progress is a stronger motivator than a reminder, because it shows the end of the task.
Cause three: follow-up depends on someone remembering
Even with a clear request and visible status, some clients will stall. The question is whether the follow-up happens because the process schedules it or because a person notices.
Manual follow-up is inconsistent by nature. Cases with an approaching deadline get chased; quiet ones drift. The client who most needs the reminder is often the one nobody thought about that week.
Scheduled reminders remove the noticing step. They also make the cadence consistent, which matters more than it sounds in workflows where the check itself must be applied the same way to every applicant. An inconsistent chase pattern in tenant referencing, for example, is a fairness problem before it is an efficiency problem — a point covered in more detail in how to collect Right to Rent documents securely.
Fixing one cause is not enough
The three causes interact, which is why partial fixes disappoint.
Fix only the request, and you get better first submissions from clients who read carefully — a real improvement, but the ones who stall still stall, and you still cannot see who they are without checking.
Fix only the visibility, and you can now see precisely which items are outstanding on which cases. That is genuinely useful internally and changes nothing for the client, who still cannot see their own position and still received a request they found ambiguous.
Fix only the reminders, and you arrive at the outcome described below, which is worse than doing nothing.
The order is what makes the difference. Specificity makes items trackable. Tracking makes status shareable. Shared status makes reminders accurate. Each step depends on the one before it, and skipping to the end is why so many teams conclude that automation did not work for them.
What automation can and cannot fix
This is where a lot of teams go wrong. Having identified chasing as the problem, they automate the reminder and leave the request unchanged.
Automating a vague request does not produce documents faster. It produces the same confusion at a higher frequency, which is a good description of being annoying. The client still cannot tell what is wanted, but now they hear about it every four days.
The order matters. Fix the specificity of the request first, make the status visible second, and only then schedule the reminders. Automation applied in that order removes work. Applied in the reverse order, it damages the relationship you were trying to protect.
A worked example: a guarantor who never replies
A letting agent is referencing a tenant with a joint applicant and a guarantor. The tenant responds quickly. The joint applicant responds after one reminder. The guarantor, who has no relationship with the agent and no interest in the tenancy beyond a favour to a family member, does not respond at all.
Under a thread-based process, the agent discovers this late, because the guarantor’s silence looks the same as an inbox they have not checked. The chase begins at the point the referencing was supposed to finish.
Under an item-level process, the guarantor has their own named request, their own visible status, and their own reminder schedule from the day the referencing starts. The agent can see the gap on day two rather than day nine, and the tenant — who has more influence over the guarantor than the agent does — can see it too. The multi-party version of this problem is set out in tenant document collection for property teams.
What this looks like in practice
A collection process that does not require chasing has four properties. Each requested item is named separately. Each item carries its own status. Both sides see the same status. And follow-up runs on a schedule the system keeps.
None of that is exotic, and none of it depends on the client behaving better than they do now. It depends on the request carrying enough structure to be tracked.
CVOR is built around that structure: document requests are issued as named items against a recipient, each item shows as outstanding or fulfilled, reminders run on a schedule, and the record of what was requested and when stays attached to the workflow itself.
The deeper point is that chasing is a design output. Teams treat it as a fact of client work because they have only ever run the process one way. It is worth asking what proportion of your follow-up volume would survive a request that could not be misread and a status that both sides could see.
For the collection process itself, see how to collect documents from clients securely. For the tracking side, see how to track which documents are still outstanding.
CVOR governs document workflows for compliance-sensitive organizations.
Explore the platform →Frequently asked questions
How do you stop chasing clients for documents?
Remove the three causes rather than sending better reminders. Make each requested item specific and separately named, give both sides the same view of what is still outstanding, and put the follow-up on a schedule the system runs. Most chasing disappears when the client can see their own position without asking.
Why do clients ignore document requests?
Usually they are not ignoring it. A request that bundles several documents into one paragraph gives the client no way to make partial progress, so it becomes a task to do later rather than now. Clients who can see three of five items already received tend to finish the remaining two.
Is it worth automating document follow-ups?
Yes, but only after the request itself is specific. Automating reminders on top of an ambiguous request produces faster nagging rather than faster documents, and it damages the relationship you were trying to protect.
How often should you follow up on an outstanding document?
There is no universal cadence, but a schedule set in advance and applied consistently outperforms ad hoc reminders sent whenever someone notices. Consistency also matters where the check itself must be applied evenly to every applicant, as with Right to Rent.