Digital asset management: when you actually need it

Every company starts with a folder. Then the folder gets a subfolder, then someone makes their own copy because they couldn’t find the original, then a freelancer emails a version that never makes it back, and eighteen months later nobody can confidently answer the question “is this the current logo?”

That’s the problem digital asset management solves. A DAM is a system for storing, organising, finding, and distributing your visual and media files, with enough information attached to each one that people can actually find the right version and know whether they’re allowed to use it.

The important word in that sentence is “information,” not “storing.” Storage is cheap and you already have it. What you probably don’t have is a reliable way to find the right asset, know which version is current, and know whether the licence expired. That gap is what a DAM fills, and it’s why “we already use a shared drive” misses the point.

What a DAM actually does

Five jobs, and most teams only think about the first one.

It stores. One place for photography, video, logos, illustrations, documents, templates, whatever else your brand runs on. Nothing surprising here.

It organises. Assets get tagged and described so they can be found by what they are rather than by remembering where someone filed them. This is the part that separates a DAM from a drive.

It controls versions. There’s one current version of the logo, and old ones are archived rather than floating around in six people’s downloads folders. When something is updated, everyone pulling from the system gets the update.

It manages rights. Photography licences expire. Models sign releases with limits. A DAM records when a licence runs out and can stop an expired asset being used, which matters more than most teams realise until they’re on the receiving end of a letter.

It distributes. Assets go out to the people and systems that need them, whether that’s your website, your agency, a retail partner, or a colleague in another region, without anyone emailing a zip file.

Why a shared drive isn’t the same thing

I want to be fair to the shared drive, because for small teams it genuinely is enough, and buying a DAM you don’t need is its own kind of waste.

A drive stores files in folders. Finding something depends on knowing where it was put and what it was called. That works when there are two hundred files and four people who all remember the conventions. It degrades badly as either number grows.

The specific failures show up in a predictable order. Search stops working, because filenames are the only thing to search and nobody names files well. Duplicates multiply, because it’s faster to save a new copy than to find the old one. Versions drift, because there’s no mechanism enforcing which is current. Rights become invisible, because a folder can’t tell you the licence on that stock photo expired last March. And access becomes crude, since folder permissions can’t express “agencies can download web-resolution versions of approved assets only.”

A DAM addresses all five, and the mechanism for four of them is the same thing: information attached to each asset.

Metadata is the whole point

If you remember one thing, remember this, because it’s where DAM projects succeed or fail.

Metadata is the information about an asset rather than the asset itself. What’s in the photo, who shot it, when, which campaign it belongs to, which products appear, which markets it’s cleared for, when the licence expires, whether it’s approved for external use.

That information is what makes a DAM searchable in a useful way. Without it you have an expensive shared drive with a nicer interface. Someone can search for “woman drinking coffee outdoors autumn” and find the right image only if somebody, or something, recorded that those things are true.

Most systems now offer automatic tagging, which recognises objects, scenes, sometimes faces and text, and applies tags without a human. It’s genuinely useful and it’s not sufficient. Automatic tagging can tell you there’s a cup and a person. It can’t tell you the licence expires in June, that this shoot is for the German market only, or that legal rejected the third image in the set. The commercially important metadata is the part a machine can’t infer.

So the practical implication: budget real time for deciding what fields you need and who fills them in. Teams that skip this and rely on automatic tagging end up with a searchable library that can’t answer the questions that actually matter.

How it relates to the systems you already have

DAM sits next to several things it gets confused with, and knowing the boundaries stops you buying twice.

A CMS manages the content on your website: pages, articles, the words and structure. A DAM manages the media those pages use. In practice they connect, so an editor building a page pulls approved images from the DAM rather than uploading a copy. Without that connection you get the same photo uploaded forty times with forty different filenames, which is exactly the duplication problem you bought the DAM to fix.

Cloud storage like Dropbox or Google Drive is the shared drive with better sync. It’s genuinely good at storing and sharing files and it has no real concept of rights, approval states, or structured metadata. Plenty of teams run both, using cloud storage for working files and a DAM for finished approved assets, which is a reasonable arrangement.

Content operations tools and marketing resource management platforms handle the process around content: briefs, reviews, approvals, deadlines. A DAM handles the resulting assets. Some products bundle both, and whether that’s good depends on whether you need both, which many teams don’t.

A product information management system holds the descriptive data for products: specifications, descriptions, prices, variants. A DAM holds the imagery. In commerce they’re close cousins and often integrated, because a product listing needs both halves, and getting them out of sync is a familiar retail headache.

The pattern is that a DAM is deliberately narrow. It does one job properly and connects to things doing adjacent jobs. When you’re evaluating, that connecting matters as much as the features, because an isolated asset library recreates the problem it was meant to solve.

Signs you need one

Work through these honestly. Two or three yeses means it’s worth costing out. One means probably not yet.

People regularly ask “where’s the latest version of X” in chat. Every one of those messages is a small tax, and the fact that it’s being asked means the current system isn’t answering it.

You’ve published the wrong version of something. An old logo, a discontinued product shot, a price that changed. Once is bad luck, twice is a system problem.

Nobody can tell you what you’re licensed to use. If the answer to “can we still use that photography” involves finding an email from 2023, you have a rights problem that’s currently invisible and eventually expensive.

You’re paying to recreate things you already own. Reshooting or redesigning because nobody could find the original is the most measurable cost here, and the easiest business case to build.

Your file volume or team size has jumped. Growth, a merger, new markets, or more channels all break informal systems fast.

External parties need access. Agencies, partners, resellers, or distributors needing files is where the emailing-zip-files pattern really starts hurting, and where controlled access pays for itself.

If most of those are no, keep your drive, tidy it up, and spend the money elsewhere. There’s no prize for owning enterprise software you don’t need.

A readiness worksheet

The signs above are easy to recognise and hard to quantify, which is exactly the problem when you’re trying to justify a purchase.

We’ve put them into a short readiness worksheet: the six signals scored, space to estimate what you currently spend recreating or hunting for assets, an inventory of where your files actually live today, a first-pass metadata schema with the fields that matter for your business, and a section for who owns tagging and approvals. The cost estimate is usually the part that turns a vague frustration into a decision, so it’s worth filling in properly even if the numbers are rough.

How DAM projects fail

Four patterns, and none of them are about the software being bad.

Migrating everything. The instinct is to move the entire back catalogue in, which takes months and fills the system with assets nobody will ever use. Bring in what’s current and genuinely valuable. Archive the rest somewhere cheap. A DAM stuffed with fifteen years of dead files is harder to search than the drive it replaced.

Skipping the metadata schema. Covered above, and it’s the most common failure by a distance. Deciding your fields is unglamorous and it determines whether the thing works.

Nobody owns it. Somebody has to approve assets, maintain tags, retire expired material, and answer questions. If that’s nobody’s actual job, the library decays into the same mess you started with, only now you’re paying a licence for it.

Making it harder than the alternative. If uploading to the DAM takes longer than saving to a drive, people will save to the drive. Adoption is a design problem, not a compliance problem. The system has to be the path of least resistance, which means integrating with the tools people already use rather than being another place to log into.

There’s also a strategic point worth making. A DAM is increasingly part of a bigger content picture rather than a standalone library. If your assets need to flow into a website, an app, and partner systems, a DAM that connects to those cleanly is worth more than one with a slightly better interface. Ask about integrations early, because that’s where the value compounds and where a cheap choice becomes expensive later.

What to look at when comparing options

If you’ve decided you need one, a few things separate a good fit from an expensive regret, and they aren’t the things demos lead with.

Search quality, tested on your own material. Every DAM demos beautifully on a curated set of two hundred assets. Ask to load a realistic slice of your own library and then search for something the way a colleague would actually phrase it. This is the single most revealing test and vendors rarely volunteer it.

How assets get in. If uploading requires a separate login and ten minutes of form-filling, adoption will fail no matter how good the library is. Look for integration with the tools people already work in, and bulk upload that doesn’t punish you.

How assets get out. Can your website pull directly? Can an agency get web-resolution versions without you emailing anything? Can you generate the crops and formats different channels need without going back to a designer? Automatic format handling saves more time than most of the headline features.

Rights and expiry handling. Can it actually stop someone using an expired asset, or does it merely record the date somewhere nobody looks? The difference between those two is the difference between managing risk and documenting it.

Permissions granularity. “Agencies can download approved web-resolution assets for the UK market” is a normal requirement and a surprising number of systems can’t express it.

And the practical one people forget: what happens when you leave. Can you export your assets with their metadata intact? Metadata you spent a year building is worth a great deal, and a system that hands it back as a mess has quietly locked you in.

The stuff worth remembering

A DAM stores, organises, versions, rights-manages, and distributes your media files. Storage is the least interesting part.
Metadata is what makes it work. Automatic tagging helps with what’s in an image and can’t tell you about licences, approvals, or market restrictions.
A shared drive is fine for small teams and small libraries. It fails predictably as files and people multiply.
The clearest signals you need one: repeated “where’s the latest version” questions, publishing the wrong asset, invisible licence status, and recreating things you already own.
Don’t migrate everything. Bring in what’s current and archive the rest.
Someone has to own it. Without that, you’ve bought a more expensive version of the mess.
If it’s harder to use than the drive, people will use the drive. Adoption is a design problem.

Not sure whether you’ve outgrown your current setup?

A DAM makes more sense alongside a content hub, a clear content lifecycle, and a habit of structuring content for every channel.

The useful starting point is counting how often people ask where something is, and what you spent last year recreating things you already owned. If you’d like a second opinion on whether a DAM is worth it for you, or whether better conventions on your existing drive would do the job, get in touch and we’ll work through it with you.