What Is a Video Deliverable (and Why Versions Matter)
In post-production, “the video” is rarely one file. It’s a sequence of cuts, notes, approvals, and re-exports that have to stay connected. That package — the thing clients review, comment on, and eventually sign off — is the deliverable.
Getting deliverables right is the difference between a clean approval path and a Slack thread full of final_v7_REALLYFINAL.mov.
What a video deliverable actually is
A video deliverable is a specific output you’re producing for review or delivery. Not the whole project. Not the hard drive. One reviewable piece of work with a clear job.
Examples:
- 60-second launch spot
- Hero brand film
- Social cutdowns (15s / 30s / 9:16)
- Color-locked master for broadcast
- Still gallery from a shoot day
Each of those can live in the same project, but they are separate deliverables because they get separate feedback, separate deadlines, and often separate approvals.
If everything is dumped into one “project folder,” notes collide. A comment meant for the vertical cut ends up changing the hero film. Versions get overwritten. Nobody knows which file is current.
Deliverable vs. project vs. file
These three get mixed up constantly:
| Term | Meaning |
|---|---|
| Project | The job container (client, campaign, shoot) |
| Deliverable | A specific output inside that project that people review |
| File / export | One concrete media version of that deliverable |
A project can hold many deliverables. A deliverable can hold many versions. A version is usually one export (or streaming proxy) that people can watch and mark up.
That hierarchy sounds obvious until a deadline hits — then teams revert to naming files in the export dialog and hoping for the best.
Why versions matter more than file names
Versioning is not about pedantry. It’s about answering three questions instantly:
- What is the current cut?
- What changed since last review?
- Which notes apply to which cut?
Without versions tied to a deliverable, feedback ages badly. A note from Monday (“trim the open”) may already be fixed in Tuesday’s export, but the client is still looking at Monday’s link. Or worse: the editor applies Tuesday’s notes to Monday’s timeline because nobody labeled the round.
Good version practice looks like this:
- v1 — first internal or client look
- v2 — after round-one notes
- v3 — near-final / legal / brand check
- Final — approved for delivery (and locked)
You don’t need a fancy numbering scheme. You need one place where versions stack under the same deliverable, and where comments stay attached to that stack.
What belongs on a deliverable (not in email)
A deliverable should carry the context of the review, not just the media:
- Current and past versions
- Timestamped comments and replies
- Approval status (in review / changes requested / approved)
- Who needs to look next
- Due date for the round
When that context lives in email or chat, it decays. People forward the wrong link. Attachments get re-compressed. Decisions disappear into archives.
Review platforms exist for this reason: keep the conversation on the cut, not beside it.
A simple structure that scales
Whether you’re a freelancer or a post house, this structure holds up:
- Workspace — your studio or company
- Project — the client job
- Deliverables — each output that needs its own review path
- Versions — each export under that deliverable
- Comments — notes pinned to time (and optionally to frames)
You can run this with disciplined folders. Most teams don’t — not because they’re careless, but because the work moves faster than the filing system.
That’s where a dedicated review workspace helps. In Posthive, projects hold deliverables, deliverables hold versions, and feedback stays on the version the client actually watched. The model matches how post already thinks, without inventing a new vocabulary.
Common deliverable mistakes
Treating the project as one deliverable.
A campaign with six cutdowns is six review paths. Bundle them only if they truly share one approval.
Overwriting the previous export.
If you can’t show what changed, you can’t defend the cut — or prove a note was addressed.
Mixing internal WIP and client-facing versions.
Keep a clear line between “editor scratch” and “shared for review.” Clients should only see intentional rounds.
Approving in chat.
“Looks good!” in Slack is not an approval trail. Put the decision on the deliverable.
Sending a new link every round with no history.
Each new share should still belong to the same deliverable so the story of the cut stays intact.
How to introduce deliverables on your next job
You don’t need a full tooling overhaul to start:
- Name the outputs before the first export (“Hero 60,” “IG 15,” “Client presentation cut”).
- Create one review destination per output.
- Number versions in that destination only — stop inventing filenames as the source of truth.
- Ask clients to comment on the player, not in email replies.
- Close each round with an explicit status: changes requested or approved.
Do that for one project and the chaos usually drops by half.
The point
A video deliverable isn’t jargon. It’s the unit of review. Versions are how that unit stays honest over time. Get those two ideas solid, and everything else — notifications, Resolve bridges, client links — has somewhere clean to land.
If you want that structure without building it from folders, start a Posthive workspace and put your next cut on a deliverable from day one.