Most agencies don't have a client approval process. They have a client approval hope: send the work, wait, and if nobody complains for long enough, treat that silence as a yes. It mostly works, until it doesn't, and the round where it doesn't is usually the one where a client comes back three weeks post-launch asking why a page still looks like the draft they "never technically approved."
A real client approval process fixes that by making sign-off a specific, recorded action instead of an absence of new complaints. This is the workflow, laid out step by step, that turns "looks fine, I guess" into an actual close.
Why silence isn't sign-off
Every agency has run a project where a client stopped responding to a review request and the team quietly shipped it, assuming no news was good news. Sometimes that's fine. Sometimes the client was traveling, missed the email, and comes back to a live change they never actually looked at, let alone approved. When that happens, "you didn't say anything" is technically true and completely useless as a defense, because from the client's side, they never agreed to anything.
The fix isn't to chase harder. It's to build a process where the client has to take one small, specific action to move a request from "reviewed" to "approved," so there's a real record either way.
The four states every item needs
A client approval process only works if every deliverable, every page, every fix, every design comp, moves through the same small set of states:
- Open. Work is in progress or hasn't been reviewed yet.
- In review. The client has been asked to look and hasn't responded either way.
- Approved. The client has taken a specific action confirming they've seen the current version and it's good.
- Reopened. The client looked and wants a change, with a note on what's wrong.
That's it. Four states, no ambiguous middle ground. "Client seemed happy on the call" isn't a state. "Client said 'looks good' in a Slack message three weeks ago about a different version" isn't a state either, it's a state from the past attached to the wrong deliverable.
What a missed approval actually costs
It's tempting to treat a loose approval process as a paperwork problem, annoying but harmless. It isn't. The whole point of getting sign-off on the right version is that fixing the wrong one later is disproportionately expensive, and the software industry has measured exactly how disproportionate. A defect caught early, during development, costs a fraction of the same defect caught after it ships: 2026 defect-cost data puts the multiplier at roughly 100x between a bug found in development and the same bug found in production, and the Consortium for Information and Software Quality now pegs the cost of poor software quality in the US at around $2.41 trillion a year. An approval that rubber-stamps a draft, or slides through on silence, is how a cheap early fix quietly becomes an expensive late one.
The client-facing cost is just as real. Roughly 68% of users abandon a site after hitting two visible defects, so "we shipped a version nobody formally checked" isn't a filing error, it's a direct line to the exact impression the client hired you to avoid. A recorded approval on the correct, final version is the cheapest insurance you can buy against relitigating the work three weeks after launch.
Who actually clicks approve
Assign a named approver per project before the first review round, not after a dispute starts. On the client side this is usually the person who signs the invoice, not whoever happens to be in the feedback thread that week. A designer on the client's marketing team leaving "love it!" in a comment is useful signal, but it isn't sign-off if that person doesn't have the authority to approve spend or scope. Get the actual approver's name in the kickoff doc, and route every formal approval request to them specifically, even if a wider team is looped in for day-to-day comments.
On the agency side, make sure whoever is marking things "in review" is also the one confirming a fix actually matches what was requested before it goes back to the client. Sending something back for a second round of client review when it clearly doesn't address the original note wastes the one resource an approval process is supposed to protect: the client's attention.
Build proof into the ritual, not around it
The weakest point in most approval workflows is the gap between "we said we fixed it" and the client actually re-checking. A developer marks an item resolved, the client is told it's done, and unless they go back and look at the live page themselves, "done" is just a claim. Most clients don't re-check, which means most approvals are really approvals of a promise, not the work.
Closing that gap doesn't require a new step, it requires the existing step to carry evidence. When an item flips to resolved, attach a before/after pair of the exact element that changed, automatically, so the client's approve click is based on something they can see in the same thread where they raised it. If you want to see what that comparison actually looks like before wiring it into a workflow, our free before/after image slider generates the same drag-to-compare view from any two images, useful for portfolio case studies too, not just live approval threads.
A workflow you can copy today
Here's the version we'd run on a real project, adaptable to whatever tool stack you're already using:
- Kickoff: name the approver, agree on the review window per round (48 hours is a reasonable default), and agree what "approved" formally means for this project, sign-off email, a click in a tool, a specific phrase in writing.
- First pass: work goes out for review as "in review," never silently pushed straight to "approved" by default.
- Client responds: either an explicit approval action, or specific, itemized change requests, not "can you make it pop more."
- Fixes shipped: each fix goes back with proof it addresses the specific note, ideally a visual before/after of the exact thing that changed.
- Re-review: only the items that were reopened need another look, not the whole deliverable from scratch. Re-reviewing everything every round is how a two-day approval window turns into two weeks.
- Final approval: a real, recorded action from the named approver, timestamped, attached to the final version, not the draft from round one.
A one-page approval agreement you can paste into a kickoff
The workflow above only holds if both sides agreed to it in writing before the first review round, not after the first dispute. This is the table we drop into a kickoff doc and get initialed. It takes five minutes and prevents the argument that otherwise happens in week six.
| Field | What to lock down |
|---|---|
| Named approver | The one person with authority to sign off on spend and scope, by name, not "the client team" |
| Review window | How long each round stays open before it escalates (48 hours is a sane default) |
| What "approved" means | The specific recorded action that counts: a click in a tool, a sign-off email, a named phrase in writing |
| Included rounds | How many revision rounds are in scope before further changes become a change order |
| Proof standard | What a resolved item must carry (a before/after of the exact element) before it goes back for approval |
| Silence rule | What happens if the window closes with no response, escalate to a call, never auto-approve |
The single most important row is the last one. A default of "no response means it ships" is the exact policy that produces the three-weeks-later dispute this whole process exists to prevent. Make silence trigger a human nudge, not an automatic yes.
The failure mode this doesn't fix on its own
A process only holds if both sides respect the review window. If a client is allowed unlimited rounds with no deadline, the "reopen with a note" state becomes a way to relitigate the whole project indefinitely, and that's a scoping problem a workflow can't solve by itself. Agree on a number of included revision rounds in the contract, and treat rounds past that as a change order, not a failure of the approval process. The process's job is to make each round fast and specific; it isn't a substitute for scope discipline.
Where this connects to the rest of client work
A tight approval process doesn't replace a good design review process earlier in the project, it's what happens after design review produces something ready to ship. And the tooling underneath both should be the same: whatever your client is looking at to approve, they shouldn't need to install anything to comment on it or click approve. If you're evaluating tools for this whole loop rather than building the process by hand, our best client feedback tools for agencies comparison covers exactly this from the tool-selection angle.
Where Shotline fits
Shotline's approval workflow is built around this exact four-state model. Clients open a share link and comment on the live page with just a name and email, no account, no extension. Every item carries a real state, open, in review, approved, or reopened with a note, and when your team or your coding agent marks something resolved, Shotline automatically recaptures a fresh before/after pair of that exact element as proof, so the client's approval is based on evidence they can see in the thread, not a promise from a developer. Pricing is from $19/mo (billed annually; $25 month-to-month) with unlimited seats and unlimited client guests, so adding every approver on every project never turns into a seat negotiation.
For the full pricing math against specific tools you might already be considering, see /pricing. Shotline is free to try for 14 days, no card required, if you want to run your next approval round through it: start a free trial.
