Running a review round (and how many you should need)

Two rounds is usually right. Why projects need five, how to consolidate feedback so an editor can act on it, and what to do when a late stakeholder appears.

Adam Murray7 August 20269 min read
On this page

Two rounds should be enough for most brand work. One to address substance, one to confirm the fixes and catch detail.

Projects that need five aren't usually suffering from a bad editor. They're suffering from a review process that lets new opinions enter at every stage — which means each round generates as much work as it resolves, and the piece slowly converges on nobody's vision.

What each round is for

Round 1 · Structure and substance. Does it do the job the brief set? Is the story right, the message clear, the length defensible? This is where big changes belong, and where they're still affordable.

Round 2 · Detail and polish. Timing, colour, audio levels, graphics, captions, the specific frame a title sits on. Confirmation that round 1's notes landed.

Round 3, if it exists · Confirmation only. A final check, not a new set of notes.

The failure is structural notes arriving in round 2. Restructuring after the polish pass wastes the polish and demoralises everyone. Which means round 1 has to include everyone whose opinion counts — the entire discipline of review is front-loading the substantive feedback.

Consolidate before you send

The single highest-leverage thing in this article.

Feedback from four people, forwarded as four emails, is not a review round. It's four review rounds delivered simultaneously, containing contradictions the editor now has to arbitrate — which is a job they can't do, because they don't know who outranks whom.

One person consolidates. One document goes out.

Consolidating means:

  • Merging duplicates
  • Resolving contradictions before sending, not after
  • Cutting notes that fall outside the brief
  • Ordering by timecode, ascending
  • Marking each note as must-fix or nice-to-have

That last one matters more than it looks. Without it, an editor treats everything as mandatory and either blows the schedule or picks for you.

The note format

Covered fully in giving feedback on a cut, and worth compressing here:

1:12–1:40 · must-fix · My attention drops through this section.
We're still on the factory and we made that point at 0:30 —
and we haven't shown the product doing the thing yet.

Where, priority, what you observe, why it matters. Describe the symptom, not the prescription — "this drags" gives an editor room to solve it better than "cut ten seconds here" does.

Set the turnaround both ways

Review latency is the largest schedule risk on most projects, and it's the brand's contribution.

Commit to a number. "Notes within two working days of receiving a cut" is a real commitment and belongs in the hand-off alongside the delivery dates.

A creator who's promised a Friday delivery and receives Tuesday's notes on the following Thursday has had their schedule taken. They'll usually absorb it once, silently, and price the next project accordingly.

Version discipline

Number every cut. v1, v2, v3. Never "the new one" or "final_final".

Notes reference a version. A note against v2 that arrives after v3 shipped is worse than no note — it looks actionable and isn't.

Keep old versions accessible. "Can we go back to how it was in v1?" is a normal request and impossible to answer if v1 is gone.

One reviewer per round decides. Named, in advance.

When you genuinely need more rounds

Not every long review is dysfunction.

Legitimate reasons: legal or compliance review that can only happen on a near-final cut; a genuinely experimental piece where nobody knew what it should be; a scope change the brand asked for and acknowledged.

That last one is worth naming explicitly. If you change your mind about something substantive after round 1, that's your prerogative — and it's a scope change, not a revision. It should be discussed as such, including its effect on the schedule and probably the fee. Treating a change of direction as a "revision" is how creators end up doing unpaid work and how good relationships quietly end.

The stakeholder who appears at the end

Everyone has met this. The executive who hasn't been involved, sees the near-final cut, and has fundamental objections.

Three things help, in descending order of effectiveness:

Prevention. Identify them at brief stage and get them into round 1, even if it's a five-minute conversation over a rough cut. The one named approver in the hand-off list exists for exactly this.

Triage. Separate their notes into "this violates the brief" and "this is a different preference." The first category is legitimate and must be addressed. The second is a taste disagreement arriving too late, and it should be handled by whoever owns the project, not passed to the editor.

Honesty about cost. "We can do that, it's another round and it moves delivery by a week" is a fair and neutral sentence. Often the change stops being important once it has a price.

Where Acumin fits

Delivery Rooms anchor every comment to a frame, so notes carry their timecode automatically and arrive in timeline order rather than as prose. Versions sit side by side, and a note against v2 stays attached to v2 when v3 lands — which removes the most common version-confusion failure.

Because everyone comments in one place, consolidation is partly structural rather than entirely a discipline someone has to enforce. It doesn't resolve contradictions for you. Two people can still leave incompatible notes on the same frame, and deciding between them is a human call — the room just makes it obvious that it needs making.

How to use this today

On your current project, name the single person who consolidates notes and the single person who approves. Tell the creator who they are.

Then commit to a turnaround time in writing. Those two things fix more review problems than any tool.


Related: Giving feedback without destroying the edit is what goes inside a round. Timecode feedback is the format that makes notes actionable first time.

Written by
Adam Murray
Founder, Acumin

Adam builds Acumin. He spends his days on the same two problems this library is about: working out what a piece of content is actually worth, and getting a brief through production without it turning into something else.

Want this done on your own channel?

Acumin reads your public content and your category and hands back what to make next — every call with its confidence and the evidence it rests on. The first Snapshot is free.