Follow Up on Client Approvals Without Chasing Every Thread

A client has the draft. The team is waiting for a decision. You are the person remembering when to follow up.

That is a small job until several projects need it at once. Each reminder brings another question: which version did they see, did someone already reply, and what happens if the decision arrives late?

A useful AI workflow can gather those facts and prepare the next step. Start by writing the rules for when a reminder should stop.

This article gives you a proposed workflow for a small agency. You can reproduce the worksheet with a document, a project tracker and your existing communication tools. Paid implementation is optional; the blueprint does not require it.

Define the decision you are waiting for

Consider a fictional design studio waiting for a client's decision on homepage draft v3. The studio has a named client approver, one review thread and an agreed response date.

The AI prepares an internal follow-up recommendation. A coordinator checks it and sends any message. The AI does not approve the design, change the project schedule or contact anyone.

This is a synthetic example, not a deployed Flow integration or a customer result.

Write four lines before choosing software:

• The job ends when: The coordinator records the client's decision on the correct version, or accepts ownership of an unresolved exception.
• The system may decide: Which approved records to gather and whether a reminder draft meets the written rules.
• A person must decide: Ambiguous feedback, changes to scope or dates, and any message outside the approved follow-up process.
• The receipt is: The decision and its source, or the unresolved issue with an owner and next review time.

This applies the FlowOS approach of keeping context, ownership, workflow boundaries and exceptions together. It is a workflow design you can adapt, not a claim that FlowOS currently connects to your agency's tools.

Keep one approval record per deliverable version

Give the coordinator a record they can inspect without reconstructing the conversation.

Include:

• Project and deliverable identifiers
• The exact version awaiting review and its source link
• The named client approver and verified contact
• The original request and communication thread
• What decision was requested
• The agreed response date, time zone and working-day rules
• Latest relevant reply and when the source was checked
• Reminder history
• Current state and next owner

Use explicit states such as awaiting decision, changes requested, approved, paused and needs clarification. These are suggested working labels.

Keep the source message beside the state. A summary saying “client approved” leaves too much unresolved if it omits which version, who replied or what conditions they attached.

A new version needs a new approval decision. If v4 replaces v3, stop reminders for v3 and make the new request explicit. Preserve the earlier record rather than making its history look as if it referred to v4.

Set the reminder rule before drafting the reminder

For the fictional studio, suppose the coordinator chooses this initial pilot rule:

• Prepare a first reminder on the next agreed working day after the response deadline.
• Prepare a second reminder two working days later if there is still no relevant reply.
• After two reminders, return the unresolved request to the account lead.
• Require coordinator review before every external message during the pilot.

These intervals are illustrative choices. Set your own with the client and account lead. A time-sensitive launch and an exploratory concept review may need different arrangements.

Count working days using the agreed calendar and time zone. Do not let the model invent either. If no response deadline was agreed, ask the account lead what to request before describing the client as late.

Silence never changes this workflow's state to approved. It triggers the agreed follow-up or escalation step.

Write the exceptions that stop a routine reminder

A reminder should leave the routine path when any of these conditions appears:

• A relevant reply arrived. Stop the prepared reminder and review the reply.
• The feedback is conditional. “Looks good if the pricing section changes” remains unresolved until the condition is handled and the decision is clear.
• The wrong version was reviewed. Ask the coordinator to reconcile the version before continuing.
• The respondent's authority is unclear. Route the decision to the account lead; do not silently replace the named approver.
• The client asked for more time. Record the request for a person to decide. Do not promise a revised delivery date.
• The client disputes scope or cost. Stop the reminder sequence and pass the issue to the person who owns that decision.
• A message bounced or the tool result is uncertain. Check the communication record before trying again.
• The reminder limit was reached. Assign the unresolved issue to the account lead instead of generating another nudge.

Keep “waiting for a client decision” separate from “waiting for an internal decision.” They need different owners.

The account lead's escalation note should contain the exact missing decision, its source, any stated consequence for dependent work and the next decision needed. Avoid an unsupported statement that the whole project is blocked.

Check again immediately before sending

A draft prepared at 9 a.m. can be obsolete by 10 a.m.

Before the coordinator sends it, check the current thread, deliverable version, approval state and reminder history again. If any relevant input changed, discard or revise the draft before approval.

Where software performs the send, have the implementer bind the approval to the exact recipient, thread and message being sent. Changed message content needs a fresh review. Use a send record and a way to prevent two workers from sending the same reminder.

An example of a real tool-level review mechanism appears in n8n's human-in-the-loop documentation: selected AI tool calls can pause for human approval, showing the proposed tool and its parameters. Approval allows execution; denial cancels that action. That feature alone does not establish the version checks or duplicate prevention described here. Those need their own implementation and tests.

For a first manual pilot, the coordinator can perform these checks in the existing tracker. You do not need to automate sending to find out whether the preparation is useful.

Give the coordinator a usable draft

Here is a synthetic internal handoff:

Decision needed: Approve homepage v3 or request changes.

Source: The existing review thread and the exact v3 document reference.

Current finding: No relevant reply was found in the checked thread as of the recorded check time. Other channels have not been checked.

Proposed message: “Hi Alex, could you confirm whether homepage v3 is approved or needs changes? The review link is in this thread. If you need more time, please let us know so we can review the next steps.”

Before sending: Check any other agreed reply channels, confirm the current version and verify that another team member has not already followed up.

Next owner: The coordinator reviews and sends, or returns the exception to the account lead.

In a real handoff, use the actual source references and check time. A missing source should remain visibly missing. Do not let the model fill the gap with a plausible link or claim that every communication channel was checked.

Test the stop conditions

Use synthetic records before giving the workflow real client information. Test a routine overdue request, then change one fact at a time:

1. Add a reply after the reminder draft is prepared.
2. Replace v3 with v4.
3. Add conditional approval.
4. Change the respondent to someone whose authority is unknown.
5. Record a reminder sent by another coordinator.
6. Reach the reminder limit.
7. Make the communication source unavailable.

For each case, write the expected next state, owner and permitted action. Check that the workflow returns those results and preserves the supporting record. A convincing reminder draft does not compensate for missing a stop condition.

Only use client material you are authorized to process with the chosen service. Keep access limited to the relevant project. A prompt telling the model to respect client boundaries does not replace enforced access controls.

Review the work the process creates

During a small supervised pilot, record preparation time, coordinator review time, corrections, unnecessary reminders and unresolved exceptions. Also note how often the founder still has to reconstruct the situation.

Treat these as questions to investigate, not promised improvements. If the coordinator spends longer checking the AI's work than preparing the reminder manually, simplify the workflow or improve its inputs before expanding it.

Start with one recurring deliverable and one coordinator. Write the version rule, reminder limit and exception owner first. The aim is a follow-up process your team can explain and operate without depending on the founder's memory.