When an agency says a deliverable is approved, it should be able to answer four questions: Which version? Approved by whom? On what date? Approved for what action? A reusable tracker can capture those answers even when the actual review happens in a document or proofing tool.
Copy the table below into your project system. It is designed for a small team that produces website copy, social posts, designs, or reports. You can use it without buying approval software; if the number of review rounds grows, it also helps you test whether a product solves a real problem.
Define the approval path first
Before sharing any draft, name one agency owner and one final client approver. If the client needs internal legal or brand review, record that step and its owner too. Decide whether a client comment means “feedback received” or an actual approval. These are different outcomes.
For a two-stage process:
- Agency reviewer checks accuracy, scope, and completeness.
- Client approver reviews the version released to them.
- Agency records the decision and, if needed, creates a new version.
Do not publish, schedule, or deliver a changed version under an approval granted to an older one. If the change is purely typographic and your agreement allows it, record the exception. Otherwise request approval again.
Copy the tracker
The example below uses a fictional client and fictional dates. The Asset ID remains stable, while each substantive revision gets a new Version and review record.
| Asset ID | Deliverable | Version | Agency owner | Client approver | Review due | Status | Decision date | Decision evidence | Next action |
|---|---|---|---|---|---|---|---|---|---|
ACME-HOME-01 |
Homepage hero copy | v1 | Jordan | Sam | Nov 12 | Changes requested | Nov 12 | Review thread #1 | Revise headline |
ACME-HOME-01 |
Homepage hero copy | v2 | Jordan | Sam | Nov 15 | Approved | Nov 14 | Approval message on v2 | Publish v2 |
ACME-SOC-01 |
Social post and image | v1 | Taylor | Sam | Nov 18 | In client review | — | Review link | Follow up Nov 18 |
Never reuse v1 for an edited file after the client has reviewed it. A version label, stable file URL or revision ID, and dated decision make it possible to reconstruct what was approved.
Use a short status list: Draft, Agency review, Client review, Changes requested, Approved, Published, and Blocked. “Sent” is an event, not an approval status. A Blocked item needs an owner and the missing decision or asset written in Next action.
Set a review request the client can answer
Here is a message you can adapt:
Please review Homepage hero copy, v2 at [review link] by [date and timezone]. The current decision is on the headline and button text. Add comments at the linked version. Reply “Approved for website publication: v2” if no changes are needed. If another person must approve it, tell us who and when they can review.
The client should not have to search through past attachments to find the current file. Keep one review link associated with the version in the tracker. If a tool replaces the file at the same URL, confirm that the version history and decision still refer to the exact content the approver saw.
Handle changes and silence
When the client requests a change, log the request against the reviewed version, assign an owner, and produce a new version. Decide whether the revision changes scope or delivery date; if it does, get an explicit decision before promising the original timeline.
If the review deadline passes without a response, send a reminder that identifies the asset and remaining decision. Request an explicit decision; follow the agreement and applicable rules when a response is late. A final approver who is away may require a new date or a delegate with authority.
Measure the delay without blaming the client
Track the time from first review request to first response, number of review rounds, time between feedback and revised version, and percentage of items approved by the agreed date. These are internal measures. Do not claim an improvement until you have a baseline and actual results.
Look for patterns. A long client review may reflect an unclear request, too many approvers, or a deliverable that did not match the brief. Fix the cause before sending more automatic reminders.
When is software useful?
If you produce a few text deliverables monthly, a shared document plus this tracker can suffice. If clients review visual files, video, or many versions, a dedicated approval system may make comments and approvals easier to locate. If approval happens inside repeat client requests, evaluate whether a client portal provides an appropriate decision record.
Trial any shortlisted tool with the same fictional asset: submit v1, request a change, submit v2, approve v2, and attempt a later edit. Check whether permissions and the recorded decision behave the way your agreement requires. Vendor documentation can describe a feature; only your test confirms the workflow you plan to use.
Next step: choose one deliverable that is currently awaiting client review. Give it an asset ID and version, name the approver, send a precise request, and record the decision in one place. Your approval process becomes real on that first item.