Video asset management fails quietly: nothing breaks, and six months later nobody can find the approved master, remember which version shipped, or say who signed off. The ten practices below are the operating discipline that prevents that slow rot - they work on any platform that supports projects, versions, fields, and review links, which is to say any serious video workspace (Frooty's own mechanics are noted where they apply).
1. Ingest once, into the system of record
Every copy of media that exists outside your system of record is a future version-conflict. Upload masters once, to the platform where review and approval happen, and treat the NLE's media pool as the working copy - not the library. Resumable chunked uploads exist precisely so the "it's too big to upload again" excuse disappears.
2. One project per deliverable, not per week
Projects should mirror deliverables - "Acme brand film", "March podcast batch" - not time windows ("March uploads"). Time-window projects scatter one deliverable's versions across months and make the approval history unfindable exactly when someone asks for it.
3. Name for sorting, describe for finding
Filenames carry sort order (date or number prefixes); fields carry meaning. "01-brandfilm-v3.mp4" sorts; the fields - status, client, publish date - are what find it later. If your team's only metadata is the filename, every search is a guessing game. The naming conventions themselves are in how to organize video project files.
4. Fields over filenames, always
Five fields answer most questions six months out: status (draft / in review / approved), owner, client or show, due/publish date, and a one-line description. In Frooty these are custom fields on the asset - filterable, visible in list views - which means "show me everything approved for Acme that hasn't shipped" is a filter, not an archaeology project.
5. Versions, never duplicates
A new cut is a new version of the same video, stacked with the previous one - comments from earlier rounds stay attached, and side-by-side compare shows what changed. A duplicate file forks the history: two videos, two comment threads, two truths. This is the single highest-leverage habit in the list; the mechanics are in the versioning guide.
6. Review inside the library, not around it
If feedback lives in email and chat while the video lives in the platform, you have two systems of record and neither is one. Review links with frame-accurate comments keep the notes attached to the exact frame and the exact version - which is what makes resolved threads auditable months later.
7. Approvals are events, not vibes
"Silence for three days" is not approval - it is an unrecorded state. The round ends when someone with authority marks the version approved, in the tool, where the record lives. Teams that adopt this stop relitigating "but I thought v4 was final" forever; the approval-chain mechanics are in the approval workflow guide.
8. Protect everything pre-release
Every stream that exists before public release gets a watermark and download-off; sensitive cuts get a password and an expiry. This costs nothing and has saved careers. The reasoning - and the failure stories behind it - are in why watermark video reviews.
9. Archive with metadata intact
When a project ends, the deliverable's value halves if its history is lost. Keep the project (versions, comments, approvals, fields) even after the master is delivered or moved to cold storage - the comment history is the institutional memory of why each decision was made, and next year's revision starts from it instead of from zero.
10. Run the 30-second stranger test quarterly
Once a quarter, pick a finished project and ask: could a competent stranger - a new hire, a freelancer - find the approved master, understand its history, and answer "who signed off?" in thirty seconds? Every "no" points at a broken practice above: missing fields, duplicate files, approvals that live in chat. The full review-hygiene checklist version of this is in the video review checklist.
The payback
These ten habits compound: fields make search instant, versions make history honest, approvals make sign-off provable, and archives make next year's work faster. Teams running them also survive audits and client disputes that teams running on chat threads simply lose - "who approved this?" has a timestamped answer. For the pricing angle of running a library this way - flat-rate vs per-seat - see video review tools with unlimited reviewers.
FAQ
What is the first practice to adopt if we can only do one?
Versions instead of duplicates. It is the habit that every other habit depends on: once versions stack with their history, fields have something to describe and approvals have something to attach to.
How much metadata is too much?
When people stop filling it in. Five required fields that are always accurate beat twenty that are sometimes filled; add a field only when a real question needed it twice.
Should raw footage live in the same system as cuts?
Working footage lives wherever the edit happens; the system of record holds cuts, versions, and approvals. Ingesting every raw card into the review platform bloats storage without adding review value - archive raw footage in bulk storage, cuts in the library.
Do these practices change for a solo editor?
The review-facing ones matter less; the library ones matter the same. A solo editor's future self is the "stranger" in the thirty-second test - and they are the one who benefits when fields and versions are honest.