Eight months after the job, an email arrives: "Hi, can you resend the final video? We can't find it."
Your options are a dead download link, a folder called final containing final_v2_ACTUAL_use-this.mp4, or an archive drive you'd have to go and find.
None of this is about craft. It's about half an hour of convention that pays back for years.
Name files so they survive the client's desktop
The moment a file leaves your machine it stops being organised by your project folders. It becomes a lone item in someone's Downloads, and the name is the only context it carries.
A workable pattern:
ClientName_ProjectName_Deliverable_Ratio_Duration_v3.mp4
Northshore_WorkshopFilm_Master_16x9_60s_v3.mp4
Northshore_WorkshopFilm_Cutdown_9x16_15s_v3.mp4Four rules behind it:
Client first. Files get filed by client at the other end, and alphabetical sorting does the work for free.
Ratio and duration in the name. The two things someone needs to know before opening it. A social manager looking for the vertical cut can find it without playing anything.
Version numbers, always, including v1. The absence of a number is what produces final_final.
No spaces, no special characters. They break on some systems, get escaped ugly in URLs, and cause trouble in automated pipelines.
Deliver what the destination needs
The commonest delivery mistake is sending one master and calling it done.
| Destination | What it needs |
|---|---|
| Feed (Instagram, TikTok) | Vertical or square, hard-coded captions, works sound-off |
| YouTube | 16:9 master, highest quality you can send |
| Website | Compressed, and a poster frame |
| Paid social | Whatever the placement requires (usually its own set) |
| Their archive | The highest-quality master, once |
Captions. Decide whether they're burned in or supplied as a separate .srt. Burned-in is right for feed placements where nobody has sound on; a separate file is right for YouTube, where the platform can use it. Sending only burned-in captions when they needed an .srt means a re-export.
A poster frame. One still, chosen deliberately. Otherwise their CMS picks a frame of someone mid-blink.
The thumbnail, if it's in scope, as a separate image at the right dimensions, not a frame grab they have to extract. It should have been on the shot list.
All of this belongs in the brief as named deliverables, so it's quoted rather than absorbed.
Say how long the link lives
Every delivery method expires eventually. The problem isn't expiry. It's silent expiry.
State it in the delivery message:
"These links are live for 90 days. After that, ask and I'll restore from archive. There's a small fee for retrieval, and I keep masters for two years."
You've now done three things: told them to download it properly, made your archive policy explicit before it's tested, and turned "can you resend" from an imposition into a defined service.
Whatever your actual policy, have one and say it once. Freelancers who keep everything forever for free are running an unpaid storage business.
Raw footage is a separate deliverable
Assume the client does not get rushes unless you've agreed they do, and put that in writing at quote stage.
If they do get them, agree what state: raw camera files as-is, or organised, labelled and synced? Organising rushes is real work and should be quoted as such. "We assumed we'd get the footage" is one of the most common and most avoidable disputes in this business.
Same conversation as usage rights: the thing to avoid is an unstated assumption, not a particular answer.
The delivery message itself
Not a bare link. Four lines:
- What's attached, listed by deliverable
- Where each one is meant to go: "the 9x16 is the Instagram cut"
- How long the link is live
- The usage granted, in plain words
That last one matters because the person downloading the files is frequently not the person who read the contract.
Version control that doesn't collapse
Never overwrite. v2 does not replace v1. Both exist. When someone says "actually the previous one was better", you need it to still be there.
Never send the same version number twice. A small fix after v3 went out makes v4, not "v3 updated". The moment two files called v3 exist in two inboxes, every conversation about them is ambiguous.
Keep an approval record. Which version was signed off, by whom, on what date. This is the fact most likely to be disputed at the point money is involved.
Where Acumin fits
A Delivery Room is built around this: versioned cuts in one place, notes anchored to timecodes on the version they were written against, and the invoice attached to the same record. Nobody has to work out whether the note about 1:12 was about v2 or v3, because it's stored against the version.
Because the room persists with the booking, "which version was approved" is a lookup rather than an archaeology exercise through email.
You can run all of it with a cloud folder and a naming convention. The convention is what's actually load-bearing.
How to use this tomorrow
Take your last delivery and rename the files to the pattern above.
Then read the message you sent with them. If it doesn't say how long the link lives, that's the line to add to your template. It's the one that prevents next year's email.
Related: Managing expectations across a project covers the five moments before this one. Pricing usage rights is what the "usage granted" line in your delivery message should reflect.