The Client Design Approval Workflow, From Brief to Sign-Off

"Seemed happy" is not a state

You sent the final files. Three weeks later the client asks for "a few small tweaks," and you realize the project you thought was closed never actually closed. Nobody said no. Nobody said yes either. It just drifted.

This is the failure mode at the center of most freelance overruns: approval was a vibe, not an event. "The client seemed happy on the call" is a feeling you had. It is not a version, not a date, not a name attached to a decision. When the scope creeps or the invoice stalls, a feeling is not something you can point at.

A working design approval workflow fixes this by making approval a state with a boundary. Something is either approved or it isn't, and both of you can see which. The rest of this piece breaks the client approval process into five gates, defines what "done" means at each one, and shows how to scale the whole thing down when the job is a single banner ad.

The five gates

Every project, a rebrand or a one-off social tile, passes through the same five gates. The difference is how much ceremony each gate gets, not whether it exists.

1. Brief agreed

Done means: both of you have signed off on what the work is, what it's for, and what "finished" looks like, before anything gets designed. Scope, deliverables, format, number of revision rounds, and the deadline are written down somewhere you can both find later. This is the first approval, and skipping it is why later approvals fall apart.

If the brief is a moving target, every downstream gate inherits the ambiguity. Pin it here.

2. Draft shared

Done means: you've shown work, and it's clearly marked as a draft awaiting review, not final, not delivered. If you're presenting options, this is where you show two or three directions side by side rather than one polished guess. Give each version a name or number so "the blue one" and "version 2" refer to the same thing in everyone's head.

3. Feedback window

Done means: the client has given consolidated feedback within an agreed period, or the window has closed. This is the gate that leaks the most, because feedback arrives in dribs across email, chat, and voice notes, and half of it contradicts the other half. Getting clean, specific, in-context notes is its own skill, more on that in getting better design feedback from clients.

The window needs a date. "Let me know what you think" has no edge; "notes by Thursday the 18th" does.

4. Revision round(s)

Done means: you've addressed the agreed feedback, the number of rounds matches what the brief allowed, and the client can see what changed. Revisions should stack on the version they belong to, so v1 to v2 to v3 reads as a lineage instead of scattering across final_FINAL_v2 filenames. If you don't already have a repeatable structure for this, the design revision process for freelancers walks through one.

The contract should name the round count. When you hit it, the next round is a change request, not a freebie. See the aftermath of gate five below.

5. Written sign-off

Done means: a specific person has approved a specific version, in writing, on a specific date. This is the design sign-off, the artifact the whole workflow exists to produce. A verbal "yeah, love it" on a call is a good sign, not a sign-off. If it isn't written down against a version, it didn't happen.

Who actually approves

An approval is only as good as the authority behind it. Before gate five, know the answer to one question: who is the single named person whose "yes" ends the project?

Get that name in the brief. Not "the team," not "we". A person. When the decision-maker is clear, the creative approval process has a terminus. When it isn't, you get the committee problem: five stakeholders, five sets of notes, and a "final" round that reopens because someone who never saw the drafts weighs in at the end.

You can't stop a client from having a committee, but you can insist it routes through one throat. Ask the client to nominate a single point of contact who collects internal opinions and hands you one consolidated, reconciled set of notes. Their job is to resolve the contradictions before the feedback reaches you, not to forward you the whole email thread and let you referee.

Silence is not approval

The most expensive ambiguity in freelancing is the unresponsive client. You delivered a draft, asked for notes, and got nothing. Two weeks pass. Is that approval? Is it a stalled project? You don't know, and not knowing means you can't schedule your next job.

Decide in advance, in the contract, what silence means, because the default, that silence leaves the project hanging forever, is the worst option. A feedback window with a real date and a stated consequence closes the gap:

• Feedback is due by a named date. "Notes by the 18th," not "whenever you get a chance."
• State what happens if the date passes. Common choices: the current version is deemed approved; or the project pauses and re-entry costs a reactivation fee; or the timeline slips by however long the client took.
• Put it in writing before the project starts. A clause the client agreed to up front is enforceable in a way a mid-project complaint never is.

Silence isn't a yes. But a contract can convert silence into a defined outcome instead of an open question. If most of your review still happens over email, it's worth reading why email falls apart as a review tool. The unresponsive-client problem gets much worse when approvals are buried in a thread.

The sign-off artifact

When the sign-off happens, capture four things. Miss any one and the artifact loses its power to protect you later:

1. Version: which exact file or option is approved. "The homepage" is not a version; "Homepage v3, the one delivered on the 14th" is.
2. Scope: what this approval covers and, by implication, what it doesn't. It approves the design, not unlimited future edits.
3. Date: when it was approved. This starts the clock on delivery, invoicing, and any post-approval change policy.
4. Name: who approved it. The named decision-maker, not "the client" as an abstraction.

That's the whole sign-off: version, scope, date, name. It can be a one-line email you send and they confirm, a signed line item, or a timestamped click in a review tool. The format matters less than the fact that it's a record you can point at, not a memory you're both reconstructing differently.

After sign-off: new scope, new money

Approval is a wall, not a suggestion. Once a version is signed off, changes to it are new work, and the graceful way to say so is to have said so already.

When the post-approval "quick tweak" arrives, you don't argue about whether it's in scope. You point at the signed-off version, and the change lands cleanly on the other side of the wall: new scope, new estimate, new line on the invoice. Framed early, this doesn't read as you being difficult. It reads as you being the professional who told them, at brief time, that changes after sign-off are quoted separately.

The wall protects the client too. It gives them a clear moment (the sign-off) where they know this is the decision, and that after it, changes cost money. Ambiguity about that boundary is what turns good client relationships sour.

Scaling down: don't ceremony a banner ad

Five gates sound heavy. They aren't, because the ceremony flexes with the job.

For a single social tile or a banner ad, the whole workflow can be three messages: "here's the brief, confirm it," "here's the draft," "reply 'approved' to sign off." The gates are still there (brief, draft, sign-off), just collapsed and lightweight. What you never skip, even on a fifty-dollar job, is the written yes at the end. That one line is what stops a trivial job from turning into unpaid revisions a month later.

The rule of thumb: match the paperwork to the risk. A logo system for a company's next decade earns a formal sign-off document. A story graphic due tomorrow earns a confirmed reply. Both get a sign-off; only one gets ceremony.

One project, all five gates

Here's the whole workflow on a small identity project, start to finish:

1. Brief. You send a one-page brief: three logo directions, two revision rounds included, notes consolidated by Maya (the named decision-maker), final files on approval. The client confirms in writing. Gate one closed.
2. Draft. You share three directions side by side, labeled A, B, and C, marked as drafts for review.
3. Feedback window. You ask for consolidated notes by Friday. Maya replies Thursday: direction B wins, with two specific tweaks. Gate three closed on time.
4. Revision. You apply the notes and post v2 of direction B, showing what changed from v1. That's round one of the two the brief allowed.
5. Sign-off. Maya approves "Direction B, v2, on the 14th" in writing. That timestamped yes is the sign-off. You deliver the finals and invoice against a decision nobody can later dispute.

If a "small tweak" arrives on the 20th, it meets the wall: it's outside the signed-off scope, so it's quoted as new work. The project closed because you built a place for it to close.

Where the workflow lives

You can run all five gates from email and a shared drive, until the thread forks, the download link expires, and "approved" is buried three replies deep. BlickDrop turns each gate into a visible, timestamped state instead of a vibe. The brief, the drafts, the red-lines, the approvals, and the final files land on one timeline you both read top to bottom. Show options side by side and the client taps the winner. It stamps approved with a time. They never make an account: a share link or the project's own email address is the whole onboarding, and their emailed replies land on the timeline as comments. Start a project at signup.

FAQ

What should a design sign-off include?

Four things: the exact version approved, the scope that approval covers, the date, and the name of the person who approved it. Anything less and you can't point at what was agreed when a dispute or a change request arrives later. The format (a confirmed email, a signed line, a timestamped click) matters less than having a record instead of a shared memory.

Is client silence the same as approval?

No. Silence is an open question, not a yes, and treating it as approval invites a reopened project the moment the client resurfaces. The fix is to define silence in the contract before the project starts: a dated feedback window with a stated consequence, such as the current version being deemed approved or the timeline slipping. That converts an ambiguous non-answer into a defined outcome you agreed to up front.

How many revision rounds should be in the contract?

Name a specific number in the brief (two or three is common for small projects), so both sides know when included revisions end. Once you hit the limit, further changes are change requests, quoted as new work rather than absorbed for free. The exact count matters less than stating it, because an unbounded "we'll revise until you're happy" has no floor.

What do you do when the client is a committee?

You can't stop a client from having internal stakeholders, but you can insist they route through one named point of contact. That person collects the internal opinions, reconciles the contradictions, and hands you a single consolidated set of notes. Without that funnel, you end up refereeing five people's conflicting feedback and reopening "final" rounds every time a late voice appears.