How to choose a DAM

Every DAM demos well. All of them. They're built to shine on a curated library of forty beautiful images, presented by someone who knows exactly where everything is. The real differences between platforms show up in month four, on your library, with your colleagues.

So choosing a DAM is mostly an exercise in dragging month four forward into the trial. That's what this checklist is for: surfacing the differences before you sign anything.

Before you look at software

Three pieces of homework before you open a single vendor tab. Skipping them is why selections drag on for six months and still land on the wrong tool. (Not yet sure a DAM is even the right category? Read what digital asset management is first.)

Count your library. How many assets, how big in total, what's the largest single file, and how fast it's growing per year. A team producing 40,000 photos a year has a different problem from one producing 400, and pricing models diverge sharply by volume.

Count your people, in three buckets. Administrators who configure things. Members who upload and edit. Viewers who only ever download. Most pricing surprises live in that third bucket, because it's usually the biggest and it's the one teams forget to count.

Write down your last thirty asset requests. Verbatim, straight from the chat log. These are your acceptance tests. If a platform can't answer twenty-five of them during the trial, it won't answer them in production either.

The requirements checklist

Work through these with your own team before any vendor gets a say in them.

Search and retrieval

• Plain-language search that works without knowing the taxonomy
• Filters that combine with search rather than replacing it
• Text inside images and documents indexed and searchable
• People or face recognition, scoped and switchable per area
• Similar-asset lookup from any result
• Search across every format you own, including video and design files
• Results that respect permissions without leaking existence of restricted assets
• Search speed on a library the size of yours, not the demo's

Organising

• Metadata schema you can change yourself, without a support ticket
• Controlled vocabularies with existing-term suggestions on typing
• Required fields enforced at upload
• Bulk editing of metadata across large selections
• Structured upload forms so context is captured at the right moment
• Collections or workspaces that do not become a second folder tree
• Archiving that removes clutter from daily search but keeps assets retrievable
• Duplicate detection on ingest

Sharing and distribution

• Curated, branded galleries rather than raw links
• Expiry dates on shares, with a default
• Download presets, sizes, crops, formats, generated on the fly
• Watermarking where you need it
• External recipients who do not need an account
• Usage tracking: who downloaded what, when
• Public upload links with enforced metadata for inbound work

Governance

• Approval states that visibly gate what is publishable
• Per-asset usage rights and licence expiry, with alerts before expiry
• Permission scopes that a marketing lead can manage without IT
• Audit trail of downloads, edits and shares
• Retirement of superseded assets so they stop circulating
• Version history with a clear current version

Platform and compliance

• Data residency you can name, which region, which sub-processors
• SSO and, at scale, SCIM provisioning
• A signed data processing agreement, and security documentation your IT or legal team can review on request
• A published uptime record, not a promise
• Documented export path for assets and metadata
• Explicit contractual position on AI training against your content
• An API, if you intend to connect a CMS, PIM or website

Not every line here matters to every team, and that's fine. The real exercise is deciding which ten are non-negotiable for yours, before a salesperson decides for you.

Five tests that break demos

A prepared demo is designed to hide the interesting parts. So run these five tests yourself, in a trial, on your own files.

1. The cold-start test

Take a colleague who's never seen the system. Give them three real requests from your list of thirty. Watch. Don't help.

What you're measuring is whether the product works for someone who doesn't know how the library is organised. Which is the entire population you're buying it for. If they need the taxonomy explained first, adoption will stall at the people who built it.

2. The ugly-upload test

Upload 500 of your worst assets. Camera-default filenames, no metadata, mixed formats, a 3GB video, a layered PSD, a raw file, a scanned PDF, three near-duplicates.

Then check: does everything preview without downloading? Does the AI tagging produce anything you'd actually use? Were the duplicates caught? Does the raw file open? This is what your real library looks like, and it's never what the demo library looks like.

3. The stranger test

Share a gallery with a personal email address, then walk around to the receiving end.

Does it look like your brand or the vendor's? Can they download the format they need without instructions? Does it work on a phone? Does the link expire, and can you revoke it? Can you see afterwards what they took?

External distribution is the most visible thing your DAM does, and it's the part most often demoed as a screenshot instead of a live link.

4. The exit test

Ask, in writing, for a full export of your trial library: original files plus all metadata, in a documented format.

Two things matter here: whether it's possible, and how long they take to answer. A vendor who can't describe their export path in one email is a vendor whose export path is a support ticket and a quote.

5. The 300-viewer test

Tell them you'll have 300 external viewers next quarter (resellers, press, regional partners) and ask what changes on the invoice.

That one question separates pricing models faster than any feature comparison. What a DAM actually costs breaks down why.

Questions that get real answers

The trick with vendor questions is phrasing them so the interesting answer is also the easy one.

• "Which of the capabilities you've shown are add-ons rather than included?" beats asking what's included.
• "What's the smallest customer you have who does what we want to do?" surfaces whether you're being sold an enterprise platform for a team of six.
• "Who configures a new metadata field, us or you?" decides whether governance stays maintainable.
• "Where is the data stored, and who are your sub-processors?" should be answered immediately, with names.
• "What have you removed from the product in the last two years?" tells you whether the roadmap has direction or just accretion.
• "What does support look like, and what's a realistic first-response time?" deserves a test during the trial: send a real question.
• "What's the renewal uplift, and is it capped?" is for now, not eleven months from now.

How to weight the criteria

Teams over-weight features and under-weight the three things that actually decide outcomes.

Search quality is the product. Everything else is table stakes. A DAM with mediocre search and thirty modules loses to one with excellent search and eight, because every one of those modules is only reachable through search.

Whoever can change the configuration owns the system. If adding a field, a workspace or a permission scope means calling the vendor or filing an IT ticket, the library will drift out of date within a year. Marketing operations has to be able to self-serve.

Total cost includes the people cost. Enterprise platforms often quietly assume a dedicated digital asset manager. That's a real role with a real salary. Not planning to hire one? Buy something that doesn't need one.

Common mistakes

Buying for the org you might become. Multi-brand, multi-region governance is expensive, slow to set up, and (in most teams that buy it) never actually configured. Buy for the next two years.

Letting the RFP write itself from vendor material. If your requirements list reads like one vendor's feature page, congratulations: you've already chosen.

Treating implementation cost as optional. Migration, metadata design and onboarding are the majority of the effort. A cheap licence with a €20,000 implementation isn't a cheap platform.

Running the pilot with the enthusiasts. They'll succeed with anything. Pilot with the sceptic who still emails files.

Skipping the storage-growth conversation. Video grows faster than anyone forecasts. Ask which tier two years of your current growth rate puts you in.

A workable timeline

For a mid-sized marcom team, the whole selection fits in roughly six weeks:

The rollout is a separate project; how to migrate to a DAM covers the four to eight weeks that come after the signature.

Frequently asked questions

What should be on a DAM requirements checklist?

At minimum: search quality tested on your own library, self-service metadata configuration, governed external sharing with expiry dates and tracking, per-asset usage rights, named data residency, a documented export path, and a pricing model that doesn't penalise external viewers.

How long does DAM selection take?

About six weeks for a mid-sized team that does the inventory work up front. Selections that stretch past three months usually stalled because nobody counted the library or wrote down real requirements before looking at products.

Should we run a formal RFP?

Only if procurement requires it. For teams under a few hundred people, a structured trial on your own assets tells you far more than a written response, because the questions that matter are about how the product behaves rather than which features it lists.

What is the most common DAM buying mistake?

Buying for a hypothetical future scale. Enterprise governance features are expensive, slow to configure and usually left switched off. Buy for the next two years, and check that the platform has a credible path beyond that.

How do we compare DAM vendors fairly?

Give each vendor the same thirty real asset requests and the same 500 messy files, and have the same non-expert colleague attempt the same tasks in each trial. Comparing feature matrices compares marketing departments; comparing task completion compares products.