Chasing Missing Items: A Follow-Up Cadence for the Client Request List

The request list goes out, and some of the missing items stay missing. The client uploads two of five, replies to a different thread about a third, and the rest sit. From here, the file moves only as fast as the chase that follows the list.

A follow-up cadence for the client request list settles that chase before it starts: how many touches, who sends each one, what each message says, when the matter climbs to a manager or partner, and where the chase is recorded so the Preparer and the Reviewer can read it. The plugin drafts; the Firm's preparer prepares; the Reviewer signs off. The chase is people's work, and so is every message in it.

This piece gives a cadence table, four message templates, an escalation ladder and a chase-log format the Firm can paste into its procedures. Building the list itself is covered in using AI to build the client request list.

Why the chase stalls

Without a cadence, each reminder gets written from scratch by whoever remembers the file. The client sees a different list each time, worded a little differently, sometimes still asking for something they already sent. Nobody can say whether this is the second reminder or the fourth. The file sits, and the only record is a string of emails in one person's inbox.

A fixed cadence takes those choices out of the moment. The Firm decides once how many touches there are, who sends each one and what it says. After that, the Preparer follows the plan instead of improvising it.

Start from the checked list

The chase runs on the list the Preparer checked by hand, never on a draft. Each open row keeps the ID and the plain name it had on the first request, so every reminder asks for the same items in the same words the client already saw.

When something arrives, the Preparer opens it, confirms it's the item the row asked for, and closes the row before the next touch goes out. A reminder never asks for an item that's already in the folder.

The cadence

The Firm can run three touches from the Preparer, then hand the file up. The table below is one version the Firm can adapt.

The Firm sets the gap between touches once and uses it for every client, so anyone reading the chase log can tell at a glance whether a touch is late. Under this approach, a partial reply doesn't restart the count. Touch 2 is still Touch 2; it just lists fewer items.

Four message templates

Each template uses placeholders in square brackets. None of them holds client data beyond the item names from the checked list, and none says when the work will be finished or what the client gains by replying.

Touch 2, reminder. "Hi [first name], thank you for sending [items received]. I'm still missing [number] items from the list I sent on [day]: [open items, one per line, each with its reason]. Please upload them to the portal you already use. If an item doesn't apply this time, please reply and tell me so. Thank you, [Preparer name]"

Touch 3, manager copied. "Hi [first name], I'm following up on [number] items that are still open on your file: [open items]. I've copied [manager name], who works on your file with me. If an item is hard to find, reply with what you have and we'll work out the next step together. Thank you, [Preparer name]"

Escalation note. "Hi [first name], I'm [name], the [role] on your file. A few items from our earlier requests are still open: [open items]. I'd like to set up a short call to go through them. Could you reply with a time that works for you? Thank you, [name]"

Doesn't-apply reply. "Thank you for letting me know that [item] doesn't apply this time. I've noted that on your file. [Still open: items, or: Nothing else is open on the list.] Thank you, [Preparer name]"

The Preparer checks each message against the chase log before sending it; the Reviewer reads the log during review and signs off on the prepared file. Nobody sends a reminder they haven't read.

The escalation ladder

Escalation changes who talks to the client. It doesn't change who checks the work or who signs off.

Rung 1: Preparer to manager. After Touch 3, the Preparer hands the open rows and the chase log to the manager. The manager picks the next step: one more touch, a call, or the next rung.

Rung 2: manager to partner. The partner on the file contacts the client directly, with the escalation note or a call. The partner works from the same open rows, so the client hears the same item names again, not a new list.

Rung 3: a decision on each open row. The partner records what happens to every row still open: still waiting with a new date to look again, confirmed by the client as not applying, or carried as an open item. In this workflow, the Preparer records each unresolved item and its proposed treatment; the Reviewer decides its treatment in review and signs off on the file.

The chase log

The log sits in the client file next to the request list, not in someone's inbox. One row per item:

The Firm can keep the status words to five: open, received, doesn't apply, escalated, and open at review. Received means the Preparer opened the document and matched it to its row. Doesn't apply keeps the client's own reply in the row.

The Firm's status board can point to the log. A file waiting on the client shows the touch in its note, such as "waiting on client, Touch 2."

What the Preparer and the Reviewer read

Under this approach, before the Preparer marks the file ready for review, every row in the log carries a status other than open, or an escalation record with an owner and a next step.

The Reviewer reads the log as part of the review. Each doesn't-apply row shows the client's reply, and each open row shows who owns it and what happens next. Every file ends with the Reviewer's sign-off, and the Reviewer signs knowing exactly what the chase did and didn't bring in.

Each open row also carries onto the sign-off packet for the file, with its owner and next step.

A Doe example

The names, file and counts below are made up for illustration.

Alex Doe, a Preparer at Doe & Co. CPA, checks the request list for the synthetic Doe Holdings file. Five items are open, E1 to E5. Touch 1 goes to the client, Jane Doe, on a Monday.

By Thursday Jane uploads E1 and E2. Alex opens both, matches them to their rows and closes them. Touch 2 goes out listing only E3, E4 and E5. Jane replies that E5 doesn't apply this time, and Alex logs her words in the row.

Touch 3 asks for E3 and E4, with Morgan Doe, the manager, copied. Nothing comes back. Morgan takes the file up the ladder and calls Jane, who sends E3 the next day. E4 is still missing, so the partner records another request as the next chase step, with Alex, the Preparer, as owner; Pat Doe, the Reviewer, decides E4's treatment in review.

Pat Doe, the Reviewer, reads the log: three items received, one doesn't apply, one open with an owner and a next step. Three plus one plus one is five, the same five the list started with. Pat reviews the file and signs off, and E4 stays on the sign-off packet.

Where TracePrep fits

We've built a TracePrep plugin that drafts these steps in your Firm's workflow, while your preparer decides and your Reviewer signs off. Join the waitlist and we'll tell you when plugin access opens.

Get on the list for plugin access

This is general information, not tax or legal advice. In TracePrep's workflow, the plugin drafts, the Firm's preparer prepares, and the Firm's Reviewer signs off. Access to the plugin is by waitlist. Keep client data inside the systems your Firm has approved.