A client approval workflow needs one current deliverable version, a defined reviewer, a clear decision and an owner for the next action. Keep feedback, requested changes and approval separate. When a revision changes the work, show the new version and confirm whether earlier approval still applies before delivery or publication.
- Identify current versionRequest a decision about named work.
- Name decision ownerSeparate contributors from authorized resolution.
- Attach feedbackKeep comments against that version.
- Confirm valid approvalVerify required approval before delivery or publication.
A revision can make an earlier approval no longer applicable.
Define the decision you are requesting
Ask the client to make a specific decision about a specific version. “Please review” can mean anything from a quick look to final publication approval. State whether you need feedback, a decision on one issue or approval to deliver the finished work.
Name the approval owner during onboarding. Several people may contribute comments, but the agency needs to know who resolves conflicting feedback. If the client has several required approvers, record the order or conditions rather than assuming one positive response is enough.
Separate review statuses
| Status | Meaning | Next owner |
|---|---|---|
| Ready for review | Agency checks complete; version identified | Client review contact |
| Feedback received | Comments exist; no final decision yet | Agency review owner |
| Changes agreed | Specific revisions accepted for action | Delivery owner |
| Revised | New version prepared for the required check | Reviewer or approval owner |
| Approved | Required decision recorded for this version | Delivery or publication owner |
| Superseded | A later version replaced this one | No further action on old version |
Use labels your client understands. The purpose is to prevent a comment, an agency revision and a final approval from being treated as interchangeable.
- Feedback receivedComments exist without a final decision.
- Changes agreedSpecific revisions are accepted for action.
- Revised versionNew work awaits its required check.
- Approved versionRequired decision is recorded for this version.
Statuses prevent comments, revisions and approvals from being treated as interchangeable.
Keep feedback attached to the work
Store the current version in one agreed place and make its identifier visible. If feedback arrives by email or in a meeting, record it against that version. Preserve the original wording where it affects a decision.
For example, a client might approve the structure of an article while asking for a claim to be removed. Record a conditional decision and the required change. The delivery owner can then prepare the revised version and follow the agreed final check. Do not mark the whole article approved simply because the response contains the word “approved.”
Resolve conflicting comments before revising
Two stakeholders may request incompatible changes. Ask the agreed decision owner to resolve them rather than sending the production team contradictory instructions. Summarize the conflict plainly and identify the decision needed.
- Identify conflictShow incompatible stakeholder requests plainly.
- Ask decision ownerRequest the agreed owner to resolve direction.
- Assess scope changeRoute a different deliverable through scope review.
- Revise agreed workGive production one settled instruction.
Do not send contradictory instructions to the production team.
This keeps revision work tied to an agreed direction. It also helps identify a scope issue. A request for an entirely different deliverable should be assessed through the scope change workflow, rather than treated as another ordinary revision.
Make reminders and approval checks conditional
A reminder should stop when the client responds, a new review date is agreed or the version is superseded. If a reply arrives through another channel, someone must update the review record. Automatic reminders cannot compensate for a record that is never maintained.
Before delivery or publication, check the current version and its required approvals again. This final check is especially useful when a file changed after a review meeting. The person carrying out the action should not have to infer which comments count as permission.
Review where the process gets stuck
Track deliverables waiting without a named reviewer, comments requiring a decision, and revisions completed against outdated instructions. Measure time by stage so you can distinguish agency preparation from client review.
Avoid treating every delay as a client failure. A confusing request, missing context or inaccessible file can make review harder. Improve those inputs first. For recurring reporting work, agree which reports require approval and which are simply shared for information.
Agree on the response window and late-feedback route
Record when feedback is expected and who follows up if it does not arrive. If the client needs more time, have the responsible owner record the effect on the next step rather than leaving an old due date in place.
- Expected feedback dateRecord when a decision is due.
- More time neededUpdate the effect on the next step.
- Follow-up ownerName who runs escalation or rescheduling.
- Outstanding decisionKeep version and contact visible without assuming approval.
A reminder requests a decision; it does not create approval.
A reminder is a request for a decision. It does not establish that the deliverable is approved. Keep the current version, review contact and outstanding decision visible while the agreed escalation or rescheduling process runs.
When several stakeholders contribute, ask the authorized decision owner to consolidate conflicting direction before production starts another revision. The agency should be able to distinguish a late response from an unresolved client decision and a scope change.
Questions and answers
Should every client comment create a revision task?
Review comments first. Some are questions, some conflict with other feedback, and some change scope. Convert only agreed changes into delivery tasks, with a version reference and an owner. Keep unresolved decisions visible until the authorized person settles them.
Can approval transfer to a revised version automatically?
Do not assume it does. Decide which changes require another check and record that rule. If an edit changes a claim, deliverable or agreed direction, confirm that the revised version has the required approval before it is delivered or published.
How do we track approval given in a meeting?
Record the approver, specific version, decision and any conditions, then confirm the record through the agreed channel. A meeting note saying the client was happy is less precise than a traceable decision about the work that will actually be delivered.