How to stop clients commenting on the wrong video version

Why it keeps happening

Clients review old exports because you sent them files. Once a file leaves your machine it has its own life: forwarded, downloaded, bookmarked, scrolled back to. Three weeks later someone opens the wrong one and leaves perfectly reasonable notes on a cut you abandoned.

Renaming files harder doesn't fix it. v3_FINAL_client2_REALfinal.mp4 is a symptom, not a solution.

Send a link, not a file

The fix is structural: give each piece of work one address, and make new cuts versions behind that address. The link a client bookmarked in week one still opens the current cut in week six.

• One project link per deliverable, shared once
• Every new export uploaded as a version of that same asset
• Old versions kept and reachable, but not the default view

Keep old notes attached to old cuts

Versioning only helps if the feedback moves with it. If comments from v2 float onto v3, your change list is polluted with notes that were already handled. In FNSHD comments, annotations and decisions belong to the version they were left on, and v3 starts clean.

Compare rather than remember

When a client asks whether something changed, put the two versions side by side instead of trusting anyone's memory. It's also the fastest way to confirm a note was actually addressed before you invite another round.

Make the current version obvious

Ambiguity invites mistakes. When you upload a revision, say what changed in one line, and say which notes it answers. Reviewers who know what they're looking at stop re-raising resolved points.

Approval belongs to a version too

The worst version mix-up is an approval on the wrong cut. Approving v2 must not imply v3 is approved — decisions should reset with each revision, so what you delivered is provably what was signed off. See how the proofing loop works for the full sequence.