Launch week is good. Attendance at training is high, the login numbers are strong, the executive sponsor sends a note. Everything is working.
Month four, uploads have flatlined. Month six, the brand team has a folder again. Nothing broke. Nobody complained. The system simply stopped being where the work happened.
Short answer: DAM rollouts fail because the DAM is a cost to contributors and a benefit to consumers, and nobody funds the contribution side. Uploading and describing an asset takes real minutes and delivers value to someone else, later. Unless that cost is removed, paid for, or made unavoidable, contribution decays to zero and the library ages out. Everything else people call an adoption problem is downstream of this.
The asymmetry, precisely
Two populations, opposite incentives.
Consumers get immediate value. They find something in thirty seconds that used to take fifteen minutes. They need no persuading and they will use the system happily forever.
Contributors pay the whole cost. Uploading, categorising, filling in rights fields, attaching approval evidence. It takes minutes per asset, it produces no benefit to the contributor, and the beneficiary is an anonymous colleague at an unspecified future date.
Every metric that looks like adoption failure follows from this. Login counts stay high because consumers keep coming. Upload counts fall because contributors stop paying. And because consumption looks healthy on the dashboard, the decay is invisible for two quarters.
The four failure mechanisms
1. Contribution is unfunded. Nobody’s objectives include cataloguing. The studio manager is measured on output, the agency is paid for deliverables, the campaign lead is measured on the campaign. Describing assets is the thing everyone does last and therefore does not do.
2. The system is not where the work is. If contributing requires opening a second application, the fraction of people who do it is much smaller than you would guess. This is not laziness, it is context switching cost, and it is why the embedded picker pattern in integration patterns is an adoption intervention rather than a technical one.
3. Search does not work well enough, early enough. Consumers give it two or three chances. If the first searches fail because the library is thin or the metadata is sparse, they revert to asking a colleague and never come back. Adoption is won or lost in the first month of consumer experience, which is why launching with a small well-described library beats launching with a large badly-described one.
4. Nobody owns it. The programme had a project manager. The project ended. The role did not become a job, so schema drift, vocabulary sprawl and permission decay accumulate with nobody watching, and the governance framework becomes a document about a system nobody is running.
The operating model
Four roles. They do not each need a person, but each needs a named owner with allocated time.
Platform owner. Accountable for the system: roadmap, vendor relationship, integrations, budget. Usually part of a marketing operations or digital function. Roughly 0.3 to 0.5 FTE at mid enterprise scale.
Librarian. Owns the schema, the vocabularies and data quality. Reviews the metrics, approves vocabulary changes, fixes what is broken. This is the role most often left unfilled and the one whose absence is most visible after eighteen months. Between 0.5 and 1.0 FTE depending on ingest volume.
Contributors. The studios, agencies and campaign teams who put material in. The critical design question is not who they are but whether contributing is in their brief and their contract.
Consumers. Everyone else. Need nothing from you except that search works.
The two that get missed are librarian and the contractual half of contributor. If your agency contracts do not specify that assets are delivered into the DAM with completed metadata, they will be delivered by email in a zip file, and you will pay someone internally to do the cataloguing that the agency was better positioned to do.
Change your agency statement of work at the next renewal. It is the highest-leverage single intervention available and it costs nothing.
Removing the contribution cost
Since contribution is the bottleneck, most of your effort should go into making it cheaper rather than into persuading people it matters.
Automate every field you can. Dimensions, format, colour, detected subject, extracted text. None of these should ever be typed. Machine analysis on ingest, such as automatic asset analysis, populates the descriptive layer so humans only supply the business context that machines cannot know. This alone can halve the fields on the form.
Set defaults from context. If the upload comes from the German product studio integration, market and business unit are known. Do not ask. Server-side upload presets let you bind those rules to the ingest path rather than to the person.
Cut the form. Six required fields, not twenty. The reasoning is in the metadata schema an enterprise actually needs, and the adoption argument is simply that every field is a cost multiplied by every asset.
Ingest where the work already happens. Watched folders, direct connectors from the studio’s tools, automated delivery from the agency’s system. The best upload is the one nobody performed.
Catalogue at the point of highest knowledge. The person who commissioned the shoot knows what it is for. Two months later, nobody does. Capturing metadata from the brief at commissioning time, before the asset exists, is unusual and it works remarkably well.
How do you tell if adoption is actually failing?
Not from login counts. Four measures that tell the truth:
- Contribution rate. New assets per month against your estimate of assets created per month. The gap is your shadow library, and it is the single most important number in the whole programme.
- Metadata completeness on new assets. Falling completeness means people are gaming the form, which means the form is too long or the fields are unclear.
- Zero-result search rate. Rising means the library is not keeping up with what people need, which is the consumer-side symptom of a contribution problem.
- Proportion of published placements referencing the DAM. If your CMS can tell you how many images on the live site come from the DAM versus uploaded locally, that number is the closest thing to ground truth you will get. It is usually sobering.
Review these monthly for the first year. Not because you will act every month, but because the decay is gradual and only visible as a trend.
What actually works, in order
Make the DAM the only path. Not a policy, an architecture. If the CMS can only place images that come from the DAM, the shadow library has nowhere to go. This is uncomfortable and it is the single most effective intervention available. Introduce it after search is good, never before.
Fund the librarian. A funded 0.6 FTE beats a policy document and an all-hands presentation, every time.
Launch small and well described. A thousand assets that are findable creates advocates. Fifty thousand that are not creates a reputation that takes two years to shake off. This is also why migration should leave most of the library behind.
Fix agency and studio contracts. Metadata is a deliverable. Write it in.
Publish the numbers. Monthly, to the sponsor, including the bad ones. A programme that reports honestly gets support when it needs it. One that reports only launch metrics gets quietly defunded at the next budget round.
None of this is about training. Training is necessary and it is not the constraint. The constraint is that somebody has to pay the contribution cost, and until you decide who, the answer will be nobody.
The taxonomy discipline that keeps search working is in designing a taxonomy people actually use, the state model behind it is in the asset lifecycle, the funding argument belongs in the business case, and the foundation is in what enterprise DAM actually is.
Leave a Reply