Approvals

How to Get a Client to Formally Sign Off on a Design

Feedback ends a conversation. Sign-off ends a liability. A repeatable process for getting clients to formally approve design work, and why most teams confuse the two.

Most design work doesn't go wrong because the work is bad. It goes wrong because nobody agreed, in writing, on the moment it was done.

A client says "looks great" in a Slack thread. Three weeks later they ask for changes to the thing they said looked great. You have no leverage, because "looks great" isn't approval. It's a mood. You collected feedback. You never collected a decision.

This is the distinction that runs underneath every revision dispute, every scope argument, every "I thought we already agreed on this" email: feedback ends a conversation. Sign-off ends a liability. They feel similar in the moment. They are not the same artifact, and treating them as interchangeable is what costs you unpaid rounds.

Why "looks good" isn't approval

Feedback is continuous. It's the client reacting to the work, pointing at things, asking questions, suggesting changes. It's valuable, and you want lots of it early. But feedback is, by nature, open-ended. There's always more of it available. A comment thread can run forever.

Approval is discrete. It's a single, dated, attributable act: this version, this scope, signed by this person, on this date. It closes the round. It converts an opinion into a record.

The reason this matters isn't pedantry. It's that the two have completely different consequences when a dispute appears:

With feedback, the client's position is always "I'm still reacting." There's no point at which they committed to anything.
With sign-off, the client's position becomes "I approved this on the 14th." That sentence ends arguments.

If your process only produces feedback, you have no defensible line between "in revision" and "done." Every project is permanently open.

The approval receipt

The artifact that closes the gap is what we'd call an approval receipt: a record that captures who approved what version on what date, against what scope. Not a thumbs-up emoji. Not a "yep, ship it" in chat. A record you can point to.

In a traditional agency this was a signed PDF or a change-order form. The mechanism is old. The principle is older. What's changed is that the tooling most design teams use, comment threads, feedback widgets, live-site annotation, produces the conversation but never produces the receipt. You finish the project rich in feedback and poor in decisions.

A good approval receipt has four things:

The version. A specific, frozen state of the work, not "the site," but the site as it existed at sign-off.
The approver. A named person, not "the client." Decisions need an owner.
The date. The moment the round closed.
The scope. What was being approved, this page, this round, this deliverable, so a later request lands clearly outside it.

If a tool gives you those four, every future "can we just change..." conversation starts from a known baseline instead of a blank one.

A repeatable sign-off process

This works whether you're solo or running an agency. The point is to make the moment of approval an explicit step, not an inference you draw later from a vague message.

1. Define the rounds before you start. In the proposal or contract, state how many revision rounds are included (two is common) and what happens after. The client agrees to the structure before any work exists to argue about.

2. Present a specific version for review. Not "here's the latest." A named, frozen state: "Round 1, for your review." The client knows they're reviewing a thing, not an ongoing draft.

3. Collect feedback in one place, in context. All comments pinned to the actual work, not scattered across email, Slack, and Loom. This is the feedback phase: open, generous, fast. Resolve items one by one.

4. Close the round explicitly. When every item is resolved, you don't just move on. You ask for sign-off on this version. This is the step almost everyone skips. The client doesn't drift out of the round. They close it with a decision.

5. Capture the receipt. The approval is recorded: version, person, date, scope. Now the round is genuinely done, and you both have the same record of it.

6. Anything after this starts a new round. Because the previous round closed with a receipt, a new request is visibly a new request, billable, schedulable, yours to scope, rather than a continuation of a round that never formally ended.

The whole method rests on step 4. Skip it and you're back to inferring approval from tone.

How to actually ask for sign-off without it being awkward

The reason people skip step 4 is that asking "do you approve this?" feels stiff, like you're producing a contract mid-friendship. It doesn't have to. The ask is easiest when three things are already true:

The structure was agreed up front. If the client said yes to "two rounds, each closed with an approval" at kickoff, the sign-off request is just you following the plan you both signed. No surprise, no tension.
The round is genuinely at zero. Ask for approval only when every comment is resolved. Asking while items are open invites "well, almost." Asking at zero invites "yes."
The wording is plain. "Everything from this round is done. Can you confirm this version is approved so I can lock it and move on?" That's it. You're not asking for a signature in blood. You're asking the client to confirm what's already obvious.

Most clients approve immediately, because you've made it easy and unambiguous. The awkwardness you're imagining comes from asking badly, at the wrong time, with no prior agreement, not from asking at all.

Why this protects you specifically

Scope creep isn't usually a client acting in bad faith. It's the natural result of a process with no closing punctuation. If nothing ever formally ends, everything is implicitly still open, and the client genuinely doesn't perceive a new request as new, because from their side, the conversation never stopped.

A sign-off step inserts the punctuation. It's not adversarial. It's clarifying. Most clients prefer it, because it tells them exactly what they're agreeing to and when they're agreeing to it. The ambiguity you're removing was costing them too, in their own internal uncertainty about whether things were settled.

Where the tooling fits

You can do all of this manually: signed PDFs, change-order emails, a spreadsheet of dated approvals. It works. It's just friction, and friction is where steps get skipped. The step that gets skipped is always step 4, because it's the one that requires you to stop and ask.

Tools built around feedback collection won't help here, because they're optimized for the conversation, not the decision. They make commenting frictionless and leave approval undefined. That's the gap Lyba is built to close. It runs the feedback phase like any review tool, but it ends rounds with a formal sign-off and a recorded approval receipt, so the closing step is part of the workflow instead of something you have to remember to do.

But the tool is downstream of the principle. Get the principle right first: stop collecting "looks good," and start collecting decisions.

FAQ

How do I get a client to formally approve a design? Make approval an explicit step, not an inference. Agree the round structure up front, present a specific frozen version, resolve all feedback, then ask for a clear yes on that version and record it. The record should capture who approved, what version, when, and against what scope.

What counts as a design sign-off? A sign-off is a discrete, dated, attributable decision by a named person to accept a specific version of the work. A positive comment ("looks good") is feedback, not sign-off, because it doesn't commit anyone to a specific version at a specific time.

How many revision rounds should I include before sign-off? Two included rounds is a common default for smaller projects, but the number matters less than defining it in writing before you start and closing each round with a recorded approval so the cap is enforceable.

What if the client won't sign off or goes quiet? Make the ask easy and specific, tied to a version with all feedback resolved, and set a reasonable deadline ("please confirm by Friday, or send any final changes"). A clear, low-friction approval step gets answered far more often than a vague "let me know what you think."