Client video review and approval workflow: versions, statuses and sign‑off that stick

Approval is a record, not a feeling

The purpose of a review workflow is not to collect opinions. It is to produce a fact: this exact version, of this exact deliverable, was approved by this person, on this date. Every mechanism below — immutable versions, one approver, per-format sign-off — exists to make that sentence true and provable.

Measure the usual habits against it. A verbal OK on a phone call about “the latest cut” fails every clause: no version, no deliverable, no record. A thumbs-up in a chat thread under a link that has since been replaced fails silently, which is worse. When the disputed invoice or the “that’s not what we signed off on” email arrives — months later, after the file has aired — the record is what settles it. If the approval exists only as a memory, the client’s memory wins.

One consequence is worth stating early because it surprises people: approval attaches to a deliverable, not to a project. A campaign that ships as a 30‑second 16:9 master, a 15‑second cutdown and a 9:16 vertical is three approvals, not one. The 16:9 being approved says nothing about the vertical reframe the client has not yet seen — and the version that airs is the one you need the yes for.

Versions are immutable — v3 with one fix is v4

The single rule that carries the whole workflow: once a version has been sent, it never changes. Not the file, not the link, not the content behind the link. If v3 needs one caption fixed, the result is v4 — even if the change took eleven seconds.

The reason is mechanical, not bureaucratic. Feedback points at timecodes inside a version: “00:41 — hold this shot longer.” The moment a file is silently replaced behind the same name or the same link, every existing comment points at the wrong frames, and nobody is told. Re-uploading “the same version, fixed” is how a client ends up approving a cut they have never actually watched.

Immutability also dissolves the filename problem everyone recognises. A version name is a counter, nothing more: ACME_SPOT30_v01, v02, v03, zero-padded so they sort. The forbidden words are the emotional ones — _FINAL, _FINAL2, _FINAL_approved_THISONE — because final is a status, not a filename. Which version turned out to be final is something the record decides afterwards; baking the hope into the name only guarantees that three files eventually claim it.

A version, then, is a small contract: one immutable cut, one review round against it, one outcome — changes requested or approved. The outcome closes the version. Everything after it belongs to the next one.

What to send: the review encode

What the client watches is not the master — it is a review encode made from it, and the two live different lives. The master stays in the project, untouched, waiting for delivery. The review encode is built to do one job: play instantly, anywhere, at a size that streams over hotel Wi‑Fi.

The arithmetic makes the case. A 90‑second 1080p25 spot as ProRes 422 HQ is roughly 2 GB — a download, not a click. The same cut as H.264 at 10 Mbit/s is about 110 MB and starts playing before the client’s coffee arrives. A working recipe: H.264 high profile, 1080p, 8–12 Mbit/s, AAC audio — and the frame rate of the timeline, unconverted. A 25 fps cut pushed through a 30 fps review export stutters on every pan, and the first feedback of the round becomes “why is it juddery?”, which costs a day of explaining.

Two options earn their place on professional work. Burned-in timecode across the top or bottom turns every note into a precise one — a client who can read 00:00:41:13 off the frame writes better feedback than one describing “the bit near the middle”. And a discreet watermark (“REVIEW — NOT FOR PUBLICATION”) exists for one specific accident: review encodes have a way of escaping onto the client’s social channels, and an 8 Mbit/s watermarked file is a much better thing to find published than an unmarked one that now looks like your delivery.

One audio note: if the deliverable is a broadcast mix at −23 LUFS, it will sound quiet on a phone speaker next to everything else the client watched that day. Either mention it in the message that accompanies the link, or review with a louder temp level and deliver the compliant mix — silently sending broadcast loudness invites the note “can you turn it up?” on a mix that is already correct.

One consolidated round per version

The loop’s natural failure state is trickle feedback: the marketing manager replies Tuesday, the CEO watches it Thursday night, the product owner adds “one small thing” the following Monday. Cut after each message and a three-stakeholder client generates three versions per actual round — each new version resetting everyone’s attention and inviting fresh notes on things previously settled.

The discipline that prevents it: one version gets one round, and a round is a single consolidated list of notes. The client-side contact collects everyone’s comments, resolves their internal contradictions — if the CEO wants the logo bigger and the brand manager wants it gone, that is the client’s meeting, not your timeline’s — and the round closes with a deadline. What arrives after the deadline joins the next round. This is also where vague notes get translated while context is fresh: “make it pop” becomes “00:12 — brighter grade on the product shot” at collection time, not at 11 p.m. against a render deadline.

Timecoded notes against an immutable version are what make the round mergeable at all — five people’s comments sort into one timeline pass instead of five contradictory emails. It is the same principle that makes transcripts searchable by timecode upstream: an address in the material beats a description of it.

Who may approve: one name, three statuses

Anyone can comment. Exactly one named person can approve. Settle that name before v1 goes out — asking “who owns the final yes?” at kickoff is free, while discovering at v6 that the actual decision-maker has not seen the film yet is the most expensive surprise in post. The late-arriving stakeholder with veto power is not a difficult client; it is a missing line in the brief.

With one approver in place, every version sits in exactly one of three states: awaiting review — sent, clock running; changes requested — the consolidated round arrived, version closed, next version owed; or approved — the record exists, and delivery can proceed. Older versions a new one replaces are simply superseded. If a version cannot be placed in one of these states — “they sort of liked it but want to show it internally” — it is awaiting review, whatever the email says. The status model is what turns “where are we with the client?” from a feeling into a lookup, for you and for whoever asks.

How review rounds die

• Feedback lands on the wrong version. The client kept the v2 attachment and wrote Thursday’s notes against it while you were cutting v4. Immutable, numbered versions make the mismatch visible; replaced files make it invisible.
• The file changed behind the link. Every comment now points at the wrong frames, and the approval on record describes a cut nobody can produce again. If it changed, it is a new version.
• The approval lives in a phone call. Fine relationship, useless record. Follow every verbal yes with the written one, attached to the version it belongs to.
• The review encode became the deliverable. The client downloaded the 10 Mbit/s watermark-free review file and published it. Watermark the review, and make the real delivery a separate, explicit handover.
• Trickle feedback ate the schedule. Three stakeholders, three uncoordinated replies, nine versions. One consolidated round per version, with a deadline, is the fix — and it is the client contact’s job, agreed up front.
• The link had friction. The approver was asked to create an account, or the link expired over the client’s holiday — so the approval arrived as a phone call instead, and the record died. Whatever tool carries review, the approving side must be able to watch and click yes with nothing in the way.

Where Launchr Post fits

Everything above is discipline you can run with exports and email — it is just manual bookkeeping that has to survive deadline pressure. Launchr Post runs it as machinery instead. The cut that left the dailies chain as an editor package comes back through the app’s Send to review: each send becomes an immutable numbered version on a client review link, comments arrive timecoded against that version, and approval is clicked per version and per format — so the 9:16 cutdown carries its own yes. Approvers never create an account and are never charged; the plans count your team, not your clients. Status flows back into the app’s review panel, where “where are we with the client?” is a column, not an archaeology project.