← All posts
Client Management6 min read

Client Approvals: Why Revision Rounds Multiply

Why agency revision rounds multiply, what an approval must contain to hold, how to separate feedback from decisions, and how many rounds belong in the contract.

Client Approvals: Why Revision Rounds Multiply

Revision rounds do not multiply because clients are difficult. They multiply because nobody wrote down what approval means, who is allowed to give it, and what happens the moment after it is given. This is about fixing the definition, which is cheaper than fixing it with software.

Agencies reach for a proofing tool at exactly the point they should be reaching for a sentence in the statement of work. The Atwork examples at the end are the cheap version of that sentence, not a replacement for it.

Why do revision rounds multiply?

Three causes, and they compound. Any one of them turns two rounds into five.

  • No single approver. Three people give feedback, two of them contradict each other, and you are now mediating your client's internal politics on your own time.
  • No definition of done. If nobody agreed what approved looks like, no version of the work can ever be the last one.
  • Feedback arrives as reaction, not decision. I'm not sure about the blue is an opinion. Change the blue to our brand navy, approved otherwise is a decision. The first one buys another round; the second one ends it.

Notice that none of the three is solved by better commenting software. They are solved by an agreement made before the first draft.

What does approved actually have to mean?

Three properties, all required. Miss one and the approval will not hold when somebody senior sees the work in week nine.

  • A named person. Not the client and not a committee. One human whose yes is final, agreed at kickoff.
  • A specific version. Approval attaches to an artefact, not a direction. Homepage v3, dated 8 Sep survives; the homepage does not.
  • A consequence. What becomes true after the yes — work starts, the invoice triggers, changes become a new scope item. An approval that changes nothing is just a compliment.
If your approval has no consequence attached, you have not been approved. You have been praised.
The three properties of an approval — a named approver, a dated version, and a consequence — set against a vague sign-off that has none of them
The three properties of an approval — a named approver, a dated version, and a consequence — set against a vague sign-off that has none of them

Who should give feedback, and who should approve?

Separate the two roles explicitly, because collapsing them is the most common cause of round five.

Anyone on the client side can give feedback. That is healthy; the marketing coordinator often spots the thing the CMO missed. But feedback is input, and input gets consolidated. Exactly one person converts consolidated feedback into a decision, and that decision is what you build against.

Say this at kickoff, in one sentence: Send us as much feedback as you like, from anyone. We'll act on it once Priya has told us which parts to act on. It sounds bureaucratic written down and it is enormously freeing in practice, because it stops you being the referee between two of your client's stakeholders.

The agency-side mirror matters too. One person on your team owns the round. If feedback arrives to three of you, some of it will be actioned twice and some not at all.

How do you stop feedback arriving as scattered opinion?

Ask for decisions in a shape, and give it one address.

  • One channel, named at kickoff. Feedback that arrives by email, DM, call and shared doc cannot be reconciled, and the reconciling is unbilled work. Pick the place, and politely move anything that arrives elsewhere into it.
  • Attach feedback to the thing. Comments that live on the deliverable itself are unambiguous. Comments in a thread require someone to translate the second one into a specific asset later.
  • Ask closed questions. Approve, or list the specific changes gets you further than thoughts? You are not being cold; you are telling the client what a useful reply looks like.
  • Set a return-by date. An open-ended review is the single most common cause of a slipped launch, and it never shows up in anybody's postmortem.

What if they ask for something out of scope mid-round?

Name it inside the round rather than after it. The expensive habit is absorbing the first three out-of-scope requests to seem accommodating, then trying to charge for the fourth — at which point the client reasonably asks what changed.

The workable version is a sentence, used every time and without drama: That's a good idea and it's outside the current scope. I can add it as a separate item with its own estimate, or we can park it for phase two. You are not refusing. You are pricing.

Doing this from request one is far easier than starting at request four, because the pattern is the message. Over-servicing is rarely a single decision; it is thirty small ones nobody logged.

How many rounds should a contract include?

Two, for most creative work, with the third priced. What matters is not the number — it is that the number exists and is written where the client can see it.

Two rounds with a named approver usually beats unlimited rounds with a committee, and it is a better deal for the client too: it forces the consolidation that makes their own feedback coherent. Write it into the statement of work, then reference it calmly the first time round three appears. The reference is only calm if the sentence was there from the start.

What does this look like in Atwork?

There is no dedicated approvals product here, and you do not need one. An approval is a status on the item that carries the work.

  • The deliverable is a row. The brief, the file, the comments and the current state all sit on the same item, so which version was approved is never reconstructed from a thread.
  • The state is a Status attribute — In progress, With client, Changes requested, Approved. The stage is visible to everyone at a glance, which removes most where is this? email on its own.
  • Feedback is comments on that item, so it is attached to the artefact rather than floating in an inbox.
  • The client sees it through a published surface, and whether they can act on it — comment, or move a status — is decided when you publish that surface, not by adding them to your workspace. The wider model is in what your client should actually see in a portal.
  • A workflow can nudge when something has sat in With client past its return-by date, which is the reminder nobody enjoys sending manually.
A delivery board with four columns — In progress, With client, Changes requested, Approved — and one card carrying its brief, file version and approver
A delivery board with four columns — In progress, With client, Changes requested, Approved — and one card carrying its brief, file version and approver

If you want this already built, the Creative Production & Review template ships exactly this shape — assets with a version and an approver, one row per round you actually sent, and every feedback item classified as actioned, parked, rejected or new scope. That last chart is the one to open before you renew a retainer. For the wider delivery picture there is also the Agency Client Delivery template.

If your rounds are multiplying because status is unclear rather than because approval is undefined, the companion piece on status updates without the weekly call is the one to read first.

Open your last three projects and count the rounds. Then find the one sentence that was missing from each — usually the approver's name. Write it into the next statement of work before you change any tooling.

Name the approver, number the rounds, and put the feedback on the deliverable. Then see whether you still need a proofing tool. Start free
AV
Adam Verhoeven

Put AI to work in your own workspace

Start free and see what your team can do with a real thinking partner.

Start free