Approve with changes: the answer most approval processes miss

Why a yes-or-no approval forces extra rounds or reluctant yeses, and how Approve with changes, with a note, gets small fixes made without another round.

Gareth Thurlow 8 min read

A phone showing a review opened from an email. Tom Becker, the client, pins a comment on the homepage hero, “Logo a touch bigger?”, chooses Approve with changes and says what to change, and the request turns Approved with changes: Leo Ortiz has been told.

Your client loves the poster. There's one thing: the date in the footer should say Saturday, not Sunday. If your approval process only offers yes or no, they now have to pick between two bad answers, and either one costs you.

There's a third answer most approval processes leave out: approve, with changes. This article covers why it matters, when to use each decision, and how to make sure the changes actually get made.

What a yes-or-no approval costs you#

A two-button approval looks simple. In practice it forces a client with a small fix into one of two moves.

The needless round. They say no. You fix the date, export again, upload again and ask again. They open it, check one word and say yes. A two-minute fix has cost two days, and the client has been asked to review the whole thing twice for the sake of a footer.

The reluctant yes. They say yes, then mention the fix somewhere else: a reply to the email, a chat message, a comment on the phone to the account lead. The record says approved without conditions. The fix lives in someone's inbox. If that person is off the next day, the poster prints with Sunday on it, and the record says the client approved it.

Neither of those is the client's fault. The process didn't give them a way to say what they meant: "yes, once you've fixed this".

The needless round is also why approvals feel slow: every extra round is another wait for an answer.

Three decisions, and when to use each#

Skybase gives every approver three decisions: Approve, Approve with changes and Request changes. Each one means something specific, and it helps to agree what with your client before the first request goes out.

Approve#

The work is right as it is. Nothing needs to change before it goes ahead.

A note is optional, under Add a note. Use it for anything the team should know that isn't a change, like "Approved. Please send the print files to Jo directly."

Approve with changes#

The work can go ahead once some small, specific changes are made, and the approver doesn't need to see it again to trust them.

That last part is the test. Ask: would I need to see this again before it goes out? If the answer is no, it's an approve with changes. Typical cases:

  • a typo, a date or a phone number
  • swapping one word for another the client has already chosen
  • a logo nudged to match the others on the page
  • a missing legal line the client supplies word for word

A note is required, under What needs to change?. The decision can't be sent without one, so the changes are always written down, on the record, next to the version they apply to.

Request changes#

The work needs to change, and the approver needs to see it again before they can say yes. Typical cases:

  • a colour, a layout or a crop, where "looks right" can only be judged by looking
  • copy that needs rewriting rather than correcting
  • anything the approver would describe as "try it this way"

A note is required here too. The next version will only fix the right thing if the note says what that is.

A phone showing a review opened from an email. Tom Becker, the client, pins a comment on the homepage hero, “Logo a touch bigger?”, chooses Approve with changes and says what to change, and the request turns Approved with changes: Leo Ortiz has been told.

Write a note someone can act on#

Both kinds of change are only as good as the note. A useful note says what to change, where, and to what:

  • Vague: "The footer's not right."
  • Useful: "Footer date: Saturday 14 June, not Sunday."
  • Vague: "Can we make it pop more?"
  • Useful: "The headline's too close to the photo. Give it more space, and try it in the darker navy."

The first useful note is an approve with changes. The second is a request for changes, because nobody can approve "more space" without seeing it.

If the change is on a particular spot, the approver can pin a comment there too, on the image or the PDF page. The note says what, and the pin shows where.

How the decisions combine across approvers#

With more than one approver, the request's rule decides how their answers add up. You choose it under Decided when when you ask.

With Everyone must approve:

  • One Request changes sends the work back straight away, even while others are still to decide.
  • Once everyone has decided, the request is approved. If anyone chose Approve with changes, it's settled as Approved with changes, and their notes stay on the record.

With Any one approver, the first answer decides, whichever of the three it is.

Each approver decides once per version, and that decision stands. If an approve with changes turns out to need another look after all, the next round is a New version, and everyone on the request is asked again.

What happens after an approve with changes#

The request is settled, and the work can move on. That's the point: nobody waits for another round. But the changes still have to be made, so make them hard to miss.

  1. The note stays with the version. Anyone opening the request later sees the decision, who made it, when, and exactly what they asked to change.
  2. Turn feedback into tasks. If the approver pinned comments to show where, Make a task turns a comment into a task on the job, with an assignee and a due date. It works after the request is decided, which is exactly when you need it here.
  3. Let an automation move the job. A project's automations can start when an approval request is approved, with changes or not. A rule can assign the job to whoever makes the fixes, or move it to the right column.
  4. Check the change before hand-off. Whoever sends the final files reads the note one more time. It takes a minute and catches the change that slipped.

The decision also shows on the sign-off record, the PDF of every version and every decision. An approval with changes is recorded as exactly that, with the note, so nobody later reads it as an approval without conditions.

A worked example: Harbour Studio#

Take a small studio, say Harbour Studio, rebranding a client called Northwind. Harbour is made up: it's the example in Skybase's sample workspace. Two requests go to Tom Becker, Northwind's contact, in the same week.

The first is "Social launch kit": nine tiles for launch day, from Ava, the copywriter, and Priya, a designer. Tom likes all nine. On tile three, the line "Launching soon" should say "Out now", because the tiles go out on launch day. He doesn't need to see that again. He chooses Approve with changes and writes: "Tile 3: 'Launching soon' should read 'Out now'. Everything else is good to go." He pins a comment on the line so there's no doubt which tile.

Ava turns the pinned comment into a task with Make a task, assigned to herself and due the same day. She makes the change, ticks off the task, and the kit goes out on time. The record shows Tom's decision and his note, so if anyone asks why tile three differs from the file he first saw, the answer is there.

The second is "Brand guidelines v3". Tom's team wants a darker navy for print. That's a colour: nobody can approve it without seeing it. He chooses Request changes: "Darker navy for print, please." Leo, a designer, adds Deep Harbour (#0B2545), uploads a New version and Tom is asked again. He approves it.

Same client, same week, two different decisions, and each one was the right size for the change.

Tell your client what each decision means#

Clients don't always know they have a middle option, or when to use it. A line in your kick-off email or your first brief saves a lot of rounds:

When you review, choose Approve if it's ready, Approve with changes if it only needs small fixes you don't need to see again, and Request changes if you'd like to see it again before it goes ahead.

You can also say it in the brief on a request where you expect small fixes, under What should they look at?: "If it's only typos, approve with changes and list them."

A short summary#

  • Yes-or-no approvals turn small fixes into extra rounds or into fixes nobody wrote down.
  • Approve means ready as it is.
  • Approve with changes means go ahead once these small changes are made, and I don't need to see it again.
  • Request changes means I need to see it again.
  • Both kinds of change need a note that says what, where and to what.
  • After an approve with changes, turn the feedback into tasks and check the note before hand-off.

For the rest of the process, how to stop chasing clients for approval covers due dates, reminders and making the ask easy to answer. To see the three decisions in the app, see how approvals work. Sending artwork for print? Artwork approval software shows how sign-off works for print and packaging.

Written by

Gareth Thurlow

Founder, Skybase

Gareth founded Skybase to give agencies and client teams one place for client work, from the brief to the sign-off.

  • Client work

    Client approvals without the email chain

    A client approval process for agencies: named approvers, review links that open without signing in, a clear decision with a note, and every version kept.

    10 min read

  • Product guides

    Six automations that take hand-offs off your plate

    Project management automation for agencies, kept simple: six rules that assign, notify and tidy up at every hand-off, and the limits worth knowing first.

    9 min read

  • Client work

    Sharing work with clients: what they should see

    How to share a project with clients: what a free guest can see and change, how to keep internal work private, and when a client counts as a paid user.

    8 min read