Video post-production workflow: named versions, review gates, and a clean lock

A video post-production workflow is the sequence of named versions a project passes through after the shoot — intake, assembly, rough cut, picture lock, finishing, master — with a written statement at each step of what is frozen and who approves it. The version naming is not bureaucracy. It exists because post-production is the only phase where the handoff is repeatedly the same file, slightly changed.

If you want the full arc from brief to publish, that lives in organizing a video production pipeline. This is narrower: the shoot is over, the footage exists, and the question is how to get from a card of camera files to an approved master without two people reviewing different cuts and calling it the same cut.

Why post-production stalls more than the shoot

Three handoffs cause most of the delays, and each one moves a reference point rather than a file.

• Footage to editor. A drive with three naming schemes, no sync check, and a brief that lives in someone's memory.
• Editor to reviewer. An export uploaded somewhere, watched at some point, commented on later, against an unstated version.
• Assembly to finishing. Color and sound begin on a cut that then changes by four seconds.

The fix is dull and consistent: one version number, one file, one card, and an explicit statement of what is frozen. If you can point at a card and answer "which version is the client looking at?" in under five seconds, your workflow is working.

Intake and sync: name it once, verify it once

Set the naming convention before the footage lands and write it into the card, so nobody has to remember it at 11pm. A pattern that survives a folder move, a freelancer handoff, and a search six months later:

client_project_shootdate_camera_reel — for example, brandfilm_2026-10-06_acam_A001.

Sort by shoot date, then camera, then reel. If you are juggling several shoot blocks and several cameras, the fuller folder system is in organizing raw footage from multiple shoots.

Put the sources in the project, not on a laptop

Attach the footage to the board card so it lands in the workspace Drive. Files attached to a card are stored in Drive, which means a draft can be reorganized later without breaking the card link. A local path on an editor's machine is not a shared file, and a reviewer cannot comment on a folder they cannot open. Drag-and-drop onto a card uploads into workspace storage, so the intake step and the storage step can be the same action.

Check sync before the edit starts

Watch the first 30 seconds of every camera against the separate audio recorder. Drifted timecode and a forgotten second recorder are cheap to find on day one and expensive to find after an assembly. If you cut from proxies, keep the camera masters in Drive and the proxies local — and accept the honest tradeoff that this costs one download round-trip per editor.

The editor handoff: write down what v1 is

An editor who receives files without a brief delivers a technically clean cut that misses the point, and you pay for the correction in a revision round. Four things belong on the handoff card:

1. Deliverable spec. Runtime range, aspect ratios, caption format, music, and what is explicitly out of scope.
2. Source list. Which files, which is the primary audio, which are B-roll.
3. Reference. One or two links showing pacing and tone, not five mood boards.
4. v1 definition. State that v1 is an assembly: story in order, temp audio, no color, no mix, placeholder graphics only.

That fourth item is the single most valuable sentence in the brief, because it tells the editor where to stop. Assign the edit to one card, and invite the editor as a guest with the view-all permission left off unless the contract genuinely requires it — a guest without view-all sees only the cards they are assigned to, so your other client work stays invisible. If the editor also needs to upload finished exports into a shared folder, enable Drive for that guest and set their Drive access to Editor; the guest tier does not grant that by default. The permission steps are the same ones in scoping freelance editors to assigned cards.

Where a project has a script and a recorded voiceover, kloudie can turn them into an editing plan, shot list or b-roll brief before the editor opens the timeline — the mechanism is described in turning a recorded voiceover into an editing plan. Audio and video files go into the Brain to be transcribed rather than being attached to a chat message. It writes the plan; it does not cut your footage.

Two review gates, internal first

The expensive mistake in post is showing a client a cut your own team has not cleared. Every client note spent on an unresolved internal question becomes a second round, and rounds cost days rather than hours.

• Gate 1 — internal. The producer or creative lead watches first and fixes structural problems: story order, pacing, a missing shot. Nothing leaves the workspace until this is signed off.
• Gate 2 — client. Send a numbered version, not "the latest file," and say in one line which version you are sending.

Mechanically, open the board card and use the Review action next to the attached media file. Video and documents support timestamped comments and @mentions, so a note lands at 02:41 instead of "somewhere in the middle." The basics are covered in how to use Review.

Then ask for one numbered change list per round. Scattered notes across chat, email and a review tool produce duplicated work; a single list converts cleanly into card comments or subtasks. If your rounds routinely reopen closed notes, the cause is usually upstream in the brief.

Client review calendar estimator

See how much of your delivery window is consumed by client review turnaround before you promise a date.

Calendar days to an approved cut equals the editing days for the first cut, plus each review round multiplied by the days it takes the reviewer to return consolidated notes.

Assumptions: Illustrative calendar arithmetic only. Turnaround is elapsed days between sending a cut and receiving one consolidated note list, counted in calendar days including weekends. It excludes color and sound, and it assumes no structural change after picture lock, which in practice adds re-editing time.

Worked example: Editing days for the first cut: 5 days; Client review rounds: 2 rounds; Days per review turnaround: 2 days. Calendar days to an approved cut: 9 days.

Where it breaks

• A forwarded earlier link. The client watches v2 and gives notes against pacing you already changed. One line — "please review v3, linked in the card" — prevents it.
• A reviewer with no deadline. Review has no turnaround commitment, so it expands.
• Approval given verbally. "Looks good" in a call is not approval of a named version. Ask for it in writing on the card.

Picture lock through master

Picture lock is a commitment, not a mood. Once color and sound start, a frame change creates rework in three places at once. Put it in the card in plain words: picture locked at v3 on a stated date; changes after this point are a new version and a new estimate.

Illustrative staging rather than a required number of rounds. A single social cut can go from v1 to vFINAL in one pass, and forcing three rounds onto it just adds days.

A worked schedule: eight minutes, six days

Assume one camera, one editor, one client contact, an eight-minute finish, and business days. This is calendar arithmetic, not a benchmark.

• Day 1 — intake. Footage uploaded and named, sync checked on the first minute, editor invited as a guest and assigned to one card.
• Days 2–3 — v1. The editor cuts story order only. The producer watches v1 against the brief, not against taste.
• Day 4 — v2 and the internal gate. Pacing applied, internal approval recorded on the card before the client sees anything.
• Day 5 — client gate on v3. Roughly two hours of client review, one hour of editor response, notes collapsed into one numbered list.
• Day 6 — lock and finish. v3-lock confirmed in writing, color and mix as v4, master exported and archived.

Two review rounds at two days of turnaround each consume four of those six days. That ratio is why the calendar, not the editing, usually decides the delivery date — and why the estimator above is worth running before you promise a date rather than after.

Archive, payment, and closing the card

Delivery and payment are two finish lines. A master can be accepted while the invoice sits unpaid, and a card marked done hides that. Keep them as separate fields or separate cards; the per-edit record is set out in tracking each edit from intake to sign-off.

For the archive, put four things in one dated folder named with the client and delivery date: the project file, the graphics, the licensed music with its license note, and the final master. Upload the master as a new version of the same file rather than a new file, so the edit history stays readable if the client asks for a change in three months. Deleting a payout record, incidentally, does nothing to a transfer already in flight — keep delivery and money as separate states and reconcile them deliberately.

Then close the card. If the deliverable is paid and archived, the edit is done. Leaving it open to hold "one more thought" is how a board stops meaning anything within a month.

Honest tradeoff before you add process: a two-person team shipping one video a week does not need six stages. It needs a v1 definition, one internal gate, and a version name on every export. Add the fuller staging when a second editor or a second client reviewer appears — that is the point where version ambiguity starts costing more than the process does. Start by taking your next real delivery date and running it through the estimator: if v1 has no room in the schedule once review turnaround is counted, the problem was never the edit.