Build a document matrix before building reminders.
"Please send your documents" forces the client to guess and guarantees another email. A document matrix should identify each item by service or meeting type, who supplies it, accepted format, relevant period, due date, review owner, and what counts as complete.
Be precise enough that a coordinator and client reach the same conclusion. "Bank statements" might mean all pages for three named accounts covering a defined period. "Current contract" should distinguish the signed version from a draft. If alternatives are acceptable, name them. The collection tool cannot repair an ambiguous request.
| Matrix field | Why it matters | Example exception |
|---|---|---|
| Requirement | Names the exact item and relevant period | Client uploads last year's file |
| Applies when | Prevents irrelevant requests | Entity document requested from an individual |
| Completion evidence | Separates received from usable | Image is unreadable or missing pages |
| Version rule | Identifies the current document | Unsigned draft arrives after an executed copy |
| Review owner | Stops files from waiting invisibly | Document needs clarification before the meeting |
Receiving a file is not the same as accepting it.
The workflow should move through requested, received, needs review, accepted, rejected, and superseded. A file can exist in storage while the meeting is still blocked. The review queue needs the client, requirement, filename, received time, assigned reviewer, and reason it cannot be accepted.
Keep the original file. If the system extracts a date, name, or document type, show that result as a proposed classification rather than silently renaming or replacing evidence. When the client sends a corrected file, link both versions and mark which one is current. Staff should be able to reconstruct what was received and why a version was rejected.
Reminder rules should know what is still missing.
Send one current list, not a new email per document. Remove accepted items automatically, explain rejected items in plain language, and give the client one secure place to return. Stop reminders when the file becomes ready, the meeting moves, the engagement closes, or staff pause the request.
Plan the exception path before the happy path. Clients will reply with attachments, upload several documents under one name, send a password-protected file, photograph the wrong page, or use a shared email address. The workflow should create an owned task rather than pretending those items are complete.
Useful message: "We have the signed agreement. We still need the March through May statements for account ending 4821. Upload them here by Tuesday so we can review them before Thursday's meeting." It names what arrived, what is missing, why it matters, and the next date.
Implement the smallest end-to-end path.
- Choose one meeting or service type with a repeatable document list.
- Write the document matrix and completion evidence with the staff who review files.
- Create a secure request linked to the correct client and engagement record.
- Route new files to storage, preserve the source, and create the review task.
- Show the client and staff the same accepted, rejected, and missing status.
- Trigger reminders from that status and stop them on completion or manual pause.
- Run a small batch through the old checklist and the new system until every mismatch is explained.
Measure days from request to ready file, staff touches, wrong-version uploads, rejected files, reminders sent after completion, and meetings delayed by missing items. Faster upload is not the goal if staff still spend the morning rebuilding the checklist.