Approve Once, Publish Everywhere: One Sign-Off for Every Video Cutdown

What should one approval actually cover?

Approve once, publish everywhere, is possible when the sign-off covers the master video and every cutdown made from it. The problem is not that clients change their minds. The problem is that most approvals only name one file, so a vertical cut, a square feed version, or a captioned export quietly sits outside the agreement. A complete approval names the master, each cutdown, the caption file, and the thumbnail, and it records who approved each one and when.

Start by writing a cutdown list before you export anything. For a typical client video, that list might be a 16:9 master for the website, a 9:16 vertical cut for Reels and Shorts, a 1:1 or 4:5 square version for the feed, and a 30 second teaser cut from the same footage. Share that list at the rough cut stage, not at delivery, so the final approval feels like a confirmation, not a new negotiation.

How do you stop a cutdown from reopening the master?

Draw a clear line between a cutdown change and a master change. A cutdown change fixes something only that version shows, such as a caption that is cut off in vertical, a logo that sits too close to the edge in square, or a hook that lands too late in a 30 second teaser. A master change alters the story, the order of scenes, the voiceover, or the music, and it affects every version. Put that distinction in writing before review starts.

Send the versions together, in one review round, with one link per version or one gallery the client can move through. Reviewing versions one at a time, days apart, is how feedback drifts. One round, one deadline, one set of notes, and the versions stay consistent. If notes on the vertical contradict notes on the master, ask which one wins before you touch the timeline.

Build a cutdown checklist the client can actually use

Clients do not need a technical spec sheet. They need a short checklist for each version, in plain language. For every cutdown, ask them to check four things: the opening three seconds, the captions, the branding, and the ending call to action. The opening matters most in short versions, because a hook that works at 90 seconds can feel slow at 30. Captions need a separate check in vertical, where text that fits in 16:9 can crowd the frame.

Keep the checklist identical across versions, and keep feedback attached to the version it belongs to. A note that says fix the caption at 0:12 means nothing if you cannot tell whether it refers to the vertical cut or the master. Timecoded comments pinned to the exact second, and frame annotations drawn on the exact frame, remove that guesswork.

Approve captions, thumbnails, and sound separately

Three items cause more late surprises than any other: captions, thumbnails, and sound. Captions deserve their own approval line because many viewers watch with sound off, and a caption error is a published error, not a small typo. Ask the client to approve the caption text itself, so a spelling fix does not require a fresh round on the whole edit. Thumbnails deserve the same treatment, because the thumbnail is what a viewer judges before pressing play.

Sound needs a check in each version too, not only in the master. Music that sits well under a 90 second story can feel rushed in a 30 second teaser, and a voiceover line cut for length can change the meaning of a sentence. When you send cutdowns, flag every place where sound was trimmed or remixed, so the client reviews those moments deliberately.

Lock the set, then record the approval

Once the client approves, lock the set. That means no new versions from that master without a new approval, and no quiet swaps of a caption file or thumbnail after sign-off. Version history matters here: when a new version uploads to the same review link, earlier rounds should stay intact, so you can prove what was approved and when.

A written approval record protects both sides. It should name the reviewer, the time, the file, and the version, so there is no argument later about whether approval happened or which file it covered. File Approved builds that record into the workflow: clients open one link, leave timecoded comments or frame annotations, and click Approve or Request Revisions, with no client account required, and an approval produces a timestamped certificate recording the reviewer, time, file, and version. The free plan covers 1 active review link with 10 GB of storage, and Pro is $25 per month with unlimited review links and 5 TB of storage.

Treat the approval certificate as the end of the project, not as paperwork. Send the client a short confirmation listing every approved file, and keep that list with the final exports. When the next project starts, reuse the same cutdown list and checklist, so the client already knows how approval works.

Frequently asked questions

Should the client approve the master first, then the cutdowns?

Approve the story in the master first, then approve the cutdowns as a set. Approving cutdowns before the master is locked wastes work, because a story change in the master ripples into every version.

What if the client approves the master but rejects a cutdown?

Fix only that cutdown, and record a fresh approval for that version alone. Do not reopen the master, and do not treat one rejected cutdown as a rejection of the whole set.

How many versions should one approval cover?

As many as you listed before review started, and no more. If the client adds a new platform or length after approval, that is a new deliverable with its own approval.