Short answer
The DAM manager in a DAM selection owns the metadata schema, taxonomy, migration and daily administration. The DAM manager leads Checkpoint 1: Map, Checkpoint 2: Define and Checkpoint 5: Test, and completes a draft metadata schema before the first vendor demo. The DAM manager carries the heaviest workload on the team during Checkpoints 1, 2 and 5.
What the DAM manager owns in a DAM selection
The DAM manager owns four outcomes in a DAM selection: findable assets, a taxonomy users understand, a migration that preserves value, and manageable administration.
Metadata schema
A metadata schema is the set of fields, data types and controlled vocabularies that describe every asset in a DAM. DAMSelection assessment: the metadata model decides DAM success, so the DAM manager designs it before the first demo. The metadata schema guide covers the method.
Taxonomy
A taxonomy is a hierarchical classification that groups assets into categories and subcategories. DAM taxonomies work best as several independent facets. The DAM manager defines the facets users filter on, such as brand, asset type, product line and region.
Migration
The DAM manager owns what moves, what gets cleaned and what stays behind. The role decides which legacy fields map to the new schema, which duplicates get merged and which assets get archived. The migration plan guide sets the sequence.
Daily administration
The DAM manager runs the system after go-live. Configuration of fields, permissions, workflows and vocabularies should sit with the DAM manager, without a vendor services ticket for each change. The selection tests that independence.
Checkpoints the DAM manager leads
The DAM manager leads three checkpoints and scores four criteria at Checkpoint 6.
| Checkpoint | DAM manager role | Output |
|---|---|---|
| 1 Map | Lead | Content audit: asset counts, types, growth, duplicates and users |
| 2 Define | Lead | Requirements with priorities, draft metadata schema, scenario list |
| 3 Justify | Contributor | Baselines for search time and duplicate production |
| 4 Shortlist | Reviewer | Check of schema and vocabulary limits per vendor |
| 5 Test | Lead | Sample asset set, demo logistics and librarian scenarios |
| 6 Score | Scorer | Scores for metadata and taxonomy, search and AI discovery, ingestion, administration |
| 7 Sign | Reviewer | Migration scope, export format and onboarding plan |
The content audit at Checkpoint 1 sets every scale input that follows. Asset count, growth rate, share of video and number of user groups feed the five-year cost model and the shortlist filters.
Draft metadata schema before the first demo
The DAM manager brings a draft schema and about 200 sample assets to the first demo, a DAMSelection rule of thumb. Most asset types work with six to ten mandatory fields and a larger set of optional fields. The draft does not need to be final. The draft gives vendors something concrete to configure and gives the team a fair basis to compare.
The table shows the format of a draft schema. The fields are a worked example for a product brand.
| Field | Data type | Vocabulary | Required |
|---|---|---|---|
| Brand | Single select | Controlled list of brands | Yes |
| Asset type | Single select | Photo, video, logo, document, artwork | Yes |
| Product SKU | Text, repeatable | Validated against the PIM | For product assets |
| Channel | Multi select | Web, app, print, marketplace, social | Yes |
| Rights expiry | Date | None | For licensed assets |
| Region | Multi select | Controlled list of markets | Yes |
| Alt text | Text | None | For web assets |
A controlled vocabulary is a fixed list of approved values for a metadata field. The Metadata Model Builder produces a draft schema in this format.
Demo requests the DAM manager makes
The DAM manager asks vendors to configure, ingest and administer live, on the buyer's sample assets. Each request belongs in the scripted demo.
- Configure a new metadata field with a controlled vocabulary, live, without vendor engineering.
- Bulk edit metadata on 500 assets in one action and show the audit trail.
- Show auto-tagging constrained to our controlled vocabulary, and how users correct wrong tags.
- Ingest our sample files and show which embedded IPTC and XMP fields the DAM reads and writes back on download.
- Show duplicate detection on a set that contains known duplicates.
- Show version control and check-in and check-out on a layered design file.
- Show a rights expiry date triggering removal from search, portal and shared links.
- Import a metadata mapping file from our legacy system and show the error report.
- Show the administration screens for permissions, workflows and vocabularies.
The DAM manager scores administration effort by counting clicks and screens for each configuration task.
Administration tasks the DAM manager times
The DAM manager times six administration tasks in every demo, because daily configuration effort decides the long-term cost of running the DAM.
| Task | What the DAM manager records |
|---|---|
| Add a metadata field with a vocabulary | Screens, clicks and whether a vendor engineer is needed |
| Change a value in a controlled vocabulary | Effect on assets that already carry the old value |
| Create a user group with restricted permissions | Steps, and whether permissions follow metadata or folders |
| Add a step to an approval workflow | Whether a business user can make the change |
| Set an expiry rule on a rights field | Where the rule applies: search, portal, links, integrations |
| Export the schema and vocabularies | File format and completeness |
The same administrator runs each task on every vendor. Equal conditions make the counts comparable at Checkpoint 6.
Documents the DAM manager uses
The DAM manager works from five documents during the selection.
| Document | Purpose | DAMSelection resource |
|---|---|---|
| Content audit | Scale inputs and current-state problems | Content audit guide |
| Draft metadata schema | Basis for configuration in demos | Metadata Model Builder |
| Taxonomy and facet list | Basis for search scenarios | Taxonomy design guide |
| Metadata mapping sheet | Legacy field to new field mapping | Metadata mapping guide |
| Sample asset set | Test data for every scenario | Internal document |
DAMSelection rule of thumb: the sample set contains about 200 assets for demos and 2,000 to 10,000 for the proof of concept. The set includes duplicates, expired licences, large video and messy legacy metadata.
Risks the DAM manager catches
The DAM manager catches five risks that other seats rarely see.
- Vendor-designed schema: a schema copied from the vendor template fits the demo and misses the business. The DAM manager brings the draft schema.
- Folder thinking: a migration that copies folder structures recreates old search problems. The DAM manager tests faceted search on the sample set.
- Unmapped legacy fields: fields without a target lose value at cutover. The DAM manager maps every field before signature.
- AI tag noise: free AI tags outside the vocabulary clutter search and filters. The DAM manager tests auto-tagging against the controlled vocabulary.
- Services dependency: configuration that needs vendor professional services slows every change. The DAM manager tests self-service administration.
The DAM manager also checks staffing. A DAM without a named owner after go-live loses metadata quality quickly, a DAMSelection assessment.
How the DAM manager works with the other seats
The DAM manager supplies the data foundation that every other seat relies on.
- With the IT architect: agree which fields the PIM, CMS and commerce platform read and write.
- With the brand manager: agree brand, campaign, region and rights fields.
- With the CMO: supply search time and duplicate baselines for the business case.
- With procurement and legal: confirm export formats that include all metadata and relationships.
The DAM manager also prepares the hand-off to DAM governance, which keeps the schema and vocabularies under change control. The DAM selection roles overview shows how the seats divide the checkpoints.
DAM manager checklist
The DAM manager checklist covers eight steps before scoring closes.
- Complete the content audit with counts, types, growth and duplicates.
- Draft the metadata schema with six to ten mandatory fields per asset type and their vocabularies.
- Define the facets for search.
- Assemble a sample set of about 200 assets with known problems.
- Script the configuration, ingest, search and administration scenarios.
- Count configuration effort per vendor during demos.
- Map every legacy field to a target field or a decision to drop it.
- Confirm the export format and the onboarding plan before signature.
Frequently asked
What does a DAM manager do during a DAM selection?
A DAM manager runs the content audit, drafts the metadata schema, prepares sample assets, scripts the librarian scenarios and scores metadata, search, ingestion and administration. The DAM manager leads three of the seven checkpoints and carries the largest share of the selection workload.
When should the metadata schema be designed?
The metadata schema should be designed before the first vendor demo, in Checkpoint 2: Define. A draft with six to ten mandatory fields per asset type is enough, a DAMSelection rule of thumb. The draft lets every vendor configure the same model and makes demos comparable.
How many sample assets should vendors get for a demo?
Vendors should get about 200 sample assets for a scripted DAM demo and 2,000 to 10,000 for a proof of concept, a DAMSelection rule of thumb. The set should include duplicates, expired licences, large video files and inconsistent legacy metadata.
Should a DAM manager trust AI auto-tagging?
A DAM manager should accept AI auto-tagging when the tags map to the controlled vocabulary and users can correct them. Free tags outside the vocabulary add noise to search and filters. The demo should test auto-tagging on the buyer's own assets.
Who maintains the DAM taxonomy after go-live?
The DAM manager maintains the DAM taxonomy after go-live, under a governance model that controls changes to fields and vocabularies. Changes go through a request, review and release cycle, so integrations that read the fields keep working.