A creative asset management system has four parts, and only one of them is software. There is a rule for how material gets in, a convention for how it gets named and who owns it, a place it lives, and a way to get it back out. Buying a tool gives you the place it lives, plus part of the getting it back. The other parts are recurring human work, and a system falls apart at whichever part nobody owns. That is why two teams can buy the same platform and end up with completely different results a year later.
Intake decides everything downstream
The moment material enters the system is the only moment when someone knows what it is. The shooter knows which take was good. The editor knows why version four exists. A week later that knowledge is gone, and no amount of software recovers it.
So the first design decision is where intake happens and who does it. Options in rough order of reliability: the person who created the material describes it at the moment of handoff, a coordinator does it in a weekly pass, or nobody does it and you rely on machine-generated description. Each is defensible. Choosing none of them is the common outcome, and it is the one that produces a drive full of files named after camera serial numbers.
Naming conventions are a promise about the future
A convention encodes what mattered when you wrote it. Campaign name, quarter, client, format. Two reorganizations later, the thing people search by is a product line that did not exist when the convention was written, and the convention is now overhead with no payoff. Good conventions are short, contain a date, contain something that will never be renamed, and stop there. Long conventions with eight segments look rigorous and get abandoned within a quarter because nobody can type them from memory.
Somebody has to own it, by name
Job postings for coordinator roles on content teams describe this work plainly: keep a project tracker, a media library, and several stakeholders moving in sync. That is a real role with a real salary line, which tells you how much labor the maintenance actually is. A system that assumes the labor is free is a system with a hidden headcount requirement. Either fund the role, or reduce the system until it survives without one.
Retrieval is the part people test last
Teams evaluate storage, permissions, and price, then discover after rollout that the search only works on text somebody typed. For documents that is fine, because the words are in the file. For video the words are in the audio and the content is in the pictures, so search quality equals tagging quality, which equals whatever your busiest colleague managed to write during a launch week.
This is the part where indexing at ingest changes the math. Vivu indexes each piece of material once, at the point it enters a Vivu project, so getting something back does not depend on anyone having described it correctly at the time. The system still needs a rule for intake and an owner for rights and approvals, and those stay human.
If you are earlier than this and still deciding what the library should contain at all, the question of what goes in comes before the question of how it is described. If you are further along and the tagging burden is the specific thing breaking, machine tagging is worth evaluating on its own, including what it gets wrong.
When a system is overkill
If two people make everything and both remember everything, you do not have an asset management problem, you have a backup problem, and those are different purchases. The threshold is not library size. It is handoffs. The first time someone who was not there needs to find something, the cost of having no system becomes visible, and until then it is genuinely invisible.
There is also a category of material that deserves no system at all: raw footage from shoots that will never be revisited, screen recordings, one-off social cuts with a two-week life. Deciding out loud that this material is disposable is part of the design. Systems that try to keep everything get abandoned faster than systems that keep less.
How to tell whether you have a system or a folder
Run one test. Pick something made a year ago by someone who has since left, and ask a person who was not involved to find it. Watch what they do. If they search by a word and get it, the system works. If they open folders by date and start guessing, then what you have is storage, and the folder discipline underneath it is where the next fix belongs, before any new software gets bought.
FAQ
What is the difference between a creative asset management system and creative asset management software?
The software is a product you buy. The system is the software plus the rules and the people around it: who describes new material, what it gets named, who decides when something is retired, and how anyone outside the team requests a file. You can have the software and not have a system, which is the usual failure, and you can have a working system on plain cloud storage.
If you are writing a budget, budget for both. The maintenance side is usually a fraction of someone's role rather than a full hire, but it has to sit on a specific person's job description.
How long does it take to set one up?
Setting up the tool takes days. Getting the back catalogue into a state where people can find things takes as long as someone spends describing it, which is why most teams should not do the whole back catalogue. A workable sequence is to start the intake rules on everything new from today, then backfill only the material somebody actually asks for.
Who should own the system, marketing or production?
Whoever gets blamed when an asset cannot be found. In practice that is usually an operations or coordinator role sitting inside the content team, close enough to the work to know what things are and senior enough to enforce the intake rule on freelancers. Splitting ownership between two departments is the arrangement that reliably fails, because the intake step is exactly the step each side assumes the other is doing.
How do we keep freelancers from breaking the conventions?
Put the naming rule and the delivery location in the contract or the brief, and make the final payment depend on delivery in that form. Freelancers follow conventions when the convention is part of the deliverable and ignore them when it is a suggestion in a Slack message. Keep the rule short enough to fit in two lines of a brief, because anything longer will be approximated.