The project that never ends almost always shares one root cause: nobody ever defined what "approved" actually means. So feedback trickles in, revisions loop back on themselves, and a two-week deliverable quietly eats two months of your margin while everyone stays polite about it.
The fix is not a firmer email or a more agreeable client. It is a repeatable sign-off system that runs the same way every time, no matter who the client is or how they like to work. Four pieces make it work: versioning, a single source of truth, clear stages with gates, and deadlines that hold. Get those in place and "are we done?" stops being a feeling and becomes a fact.
Why designs never get signed off
Watch a stalled project closely and you will see the same handful of failures, none of them about talent or effort:
- The ask was vague. "Let me know what you think" invites a wandering opinion. It never invites a decision.
- No one owns the decision. Three people comment, none of them is empowered to say yes, and the design floats in limbo waiting for a phantom final voice.
- There is no deadline. A review with no due date is not a task, it is a wish. It slides to the bottom of a busy client's inbox and stays there.
- The target keeps moving. Feedback arrives across email, Slack, a forwarded PDF and a phone call, so version two answers half of round one and reopens the other half.
Every one of these is a process gap, not a personality problem. A client who "won't make up their mind" is usually a client who was never asked a clear question by a clear date. Fix the structure and the behaviour follows.
Version everything (and show one at a time)
Give every deliverable a version number and stick to it: v1, v2, v3. It sounds trivial, but ambiguous versions are where most sign-off disputes live. When a client says "I liked the earlier one," you need to know exactly which file that was, and so do they.
The harder discipline is showing one version at a time. The temptation is to send three homepage directions and let the client pick, which feels generous. In practice it multiplies the surface area for feedback, invites Frankenstein requests that stitch bits of each together, and pushes the real decision back onto you. Present your recommended direction, hold the alternates in reserve, and only widen the field if the client genuinely rejects the lead option. One version, one focused review, one clean answer.
Archive superseded versions rather than deleting them. You want a paper trail of what was shown and when, so that "we already signed off on that layout" is a link, not an argument.
One source of truth
Feedback scattered across five channels is feedback you will lose. The moment comments live in email threads, Slack DMs, a marked-up PDF and a meeting nobody minuted, you become the human integration layer, manually reconciling contradictions the client never even knew they wrote. That is unpaid, error-prone work, and it is exactly where revisions multiply.
Pick one place where all feedback lands and route everything to it. Every comment sits on the specific thing it refers to, so "the button" is never ambiguous, and both sides can see the full history in one view. This is the same principle behind good website feedback collection for live pages, and it matters just as much for static work: our guide to PDF markup for client review covers how to keep document feedback in one anchored place instead of a chain of re-attached files.
When there is a single source of truth, approval becomes checkable. Anyone can open it and see what is resolved, what is still open, and who said yes. No source of truth, and "approved" is just a word someone remembers differently later.
Set stages and gates
A deliverable should not go from your screen to the client's inbox in one leap. Break the journey into named stages, and treat each one as a gate that must close before the next opens. A gate is simply a checkpoint with an owner and a rule: nothing proceeds until the right person signs off.
| Stage | What happens | Who signs off | Deadline |
|---|---|---|---|
| Internal review | Team checks quality, brief fit and obvious errors before the client ever sees it | Design lead | Before client send |
| Client round 1 | Client leaves first-pass feedback on v1, consolidated in one place | Client decision-maker | 3 business days |
| Revision | You address round 1 comments and produce v2 | Design lead | 2 business days |
| Client round 2 | Client confirms fixes or raises final, in-scope points only | Client decision-maker | 2 business days |
| Final sign-off | Client formally approves; deliverable is locked and moves to build or print | Client decision-maker | 1 business day |
Name the client decision-maker at the start of the project, in writing. One person owns the yes. Others can contribute comments, but the design does not pass a gate until that named person signs off. This single rule kills the most common stall of all: waiting on approval that no one present is actually allowed to give.
Deadlines that actually hold
A stage without a date is not a stage. Every gate in that table has a deadline, and the deadlines are short on purpose. A three-day review window respects the client's time while making clear that this is a task with an edge, not an open invitation. Long windows do not get more thoughtful feedback; they get forgotten and then rushed.
Make the deadline mean something. Agree up front that if a review date passes without feedback, the version stands as approved and the timeline shifts by the number of days lost. Put that clause in the proposal, not in a tense email three weeks later. Clients respect a deadline far more when they signed it themselves at the start.
A good approval request does the work of holding the deadline for you. It should contain:
- One version, clearly numbered, with old versions out of the way.
- A specific ask: what you want feedback on, and what is already locked.
- A review-by date, stated plainly, with the consequence of missing it.
- One link where all comments go, so nothing scatters.
- A single sign-off action, so approving is one obvious click, not a composed reply.
Ambiguity is the enemy of speed. When the client knows exactly what to look at, exactly by when, and exactly how to say yes, most of them do.
Where Roundmark fits
To be transparent, this is Roundmark's blog, so here is the honest version of where it helps. You can run the whole process above with a spreadsheet and discipline. A purpose-built tool mostly removes the friction that erodes the discipline over time.
Roundmark gives each project one shareable link. The client clicks the canvas to drop a numbered pin and comment, with no account and no password thanks to a magic link, so round 1 does not stall on a login screen. Every comment becomes a thread you can reply to and mark resolved, which means a design is only "done" when every thread is closed and the client has signed off, unambiguously and on the record. Reviewers are unlimited on every plan, so inviting the whole client team never inflates your bill. If you want the specifics, the pricing page lays out the plans, including the free tier and the 14-day trial on paid plans. The tool is optional. The process is not.
FAQ
What is a design approval process?
It is the repeatable sequence a design goes through from draft to signed-off: who reviews, in what order, by when, and how approval is recorded. A written process turns "are we done?" into a clear yes or no and protects both sides from endless revisions.
How do I get clients to approve designs faster?
Remove ambiguity and add deadlines. Show one version at a time, state exactly what you need feedback on, give a review-by date, and make signing off a single clear action. Most delays come from vague asks and no due date, not from difficult clients.
How many revision rounds should an agency offer?
Two rounds per deliverable is a common, healthy default, written into the proposal, with extra rounds billed as change requests. Bounding revisions protects your margin and nudges clients to consolidate feedback instead of dripping it in.