DAM demo red flags

What counts as a DAM demo red flag

A DAM demo red flag is any vendor behaviour that hides how the platform will handle the buyer's own assets, users and integrations. Red flags fall into four groups: control of the script, realism of the data, evidence for capabilities, and transparency on integration and exit. Each group predicts a different implementation risk, so the panel records them separately.

DAMSelection assessment: generic vendor demos carry no selection value. Red flags only become visible when the buyer sets the script, so the scripted demo scenarios come first and the red flag checklist second. Both belong to the test checkpoint of the Selection Route.

Script refusal and scenario drift

Script refusal is the strongest DAM demo red flag, because the script holds the tasks the buyer's teams will run every day. Refusal is rarely explicit. It shows up as a long company introduction, a request to "show the platform first", or a scenario quietly swapped for a feature the vendor prefers.

Watch for four patterns:

• Slides take more than 15 minutes of a two-hour slot before the first scenario starts (DAMSelection rule of thumb).
• A scenario step runs on different data from the data the buyer supplied.
• The presenter switches between several environments to show each step in its best configuration.
• Steps that failed in rehearsal are "covered later" and never return.

The panel chair keeps a printed run sheet and moves the vendor back to the next step. A skipped step scores 0 for that scenario, the DAMSelection definition for "absent or roadmap only". Send scripts and sample assets two weeks ahead, so the vendor cannot cite missing preparation time. The Demo Script Generator builds the run sheet from the scenarios the team selects.

Sample data and staged environments

Demos on vendor sample data hide the ingest, metadata and rendition problems that real files expose. Vendor sample libraries hold small, clean, well-tagged images. Real libraries hold layered design files, 4K video masters, inconsistent filenames and embedded metadata of mixed quality.

Include a representative sample of the buyer's assets in the script. DAMSelection rule of thumb: 200 to 500 files covering every major asset type, including the largest and the messiest. Ask the vendor to ingest a subset live, so the panel sees processing time, rendition quality and which embedded IPTC and XMP fields arrive in the DAM's own fields.

Red flags in this group:

• The vendor pre-loads the buyer's files and refuses any live ingest.
• Embedded metadata is lost or lands in one free-text field.
• The configured fields bear little resemblance to the metadata schema the buyer sent.
• Video or layered files are left out "for time reasons".

DAMSelection assessment: the metadata model decides DAM success, so a demo that ignores the buyer's schema has tested the wrong thing.

Roadmap answers and partner-only configuration

A roadmap answer to a must-have requirement means the capability is absent today, and the panel scores it as absent. The DAMSelection scoring model defines score 0 as "absent or roadmap only". Record the promised release quarter in writing in the evidence log, and leave the score at 0 until the feature ships and the vendor shows it.

Partner-only configuration is the second flag in this group. Some platforms need an implementation partner for tasks a DAM administrator should handle alone: adding a metadata field, changing a workflow step or creating a user role. Ask the presenter to make one such change live. When the answer is that a partner or the services team does it, record the dependency and add the cost to the five-year TCO model.

Sort every capability answer into one of three classes:

1. Available now and shown live: score on the demo evidence.
2. Available now and shown in documentation only: score with the documentation URL and test it in the proof of concept.
3. Planned: score 0 and record the promised date.

API, integration and export vagueness

Vague answers on APIs, rate limits and export predict integration rework and a costly exit. A DAM sits between creative tools, PIM, e-commerce and web channels, so its API sets the ceiling for every integration the buyer will build.

Ask for specifics: the public API documentation URL, rate limits per minute or per day, webhook or event support, and bulk endpoints for metadata updates. A vendor who promises to "check with product" on every API question has given no evidence for the API and extensibility criterion. Name the PIM connector owner too: the vendor, the PIM vendor or a third party.

Export deserves its own live test. Ask for an export of 50 assets with metadata, renditions and version history, and open the file in front of the panel. Fact: the EU Data Act covers SaaS providers. Where no interoperability specifications or harmonised standards exist for the service, its Article 30(5) requires a provider to export all exportable data on request in a structured, commonly used and machine-readable format. Article 2(38) includes metadata in exportable data. A vendor who cannot show an export in a demo will struggle at exit, as the exit strategy guide explains.

DAM vendor demo questions that expose red flags

The most useful DAM demo questions are requests to perform a task live, because a performed task produces evidence and a spoken answer produces none. Ask these during or straight after the scripted scenarios. Each request targets one red flag group.

1. Ingest these 20 files from our sample now and show the extracted metadata.
2. Add a new required field to the image schema and show it on the upload form.
3. Run the same search as a regional marketer with restricted permissions.
4. Expire the licence on one image and show where it disappears: portal, CDN links and connectors.
5. Show the API call that updates metadata on 1,000 assets, with the documented rate limit.
6. Open the audit log entry for the last change you made.
7. Export 50 assets with metadata, renditions and versions, and open the export file.
8. Sync one product image through the PIM connector and name who maintains the connector.
9. Show what an external agency user sees and what that user costs per year.
10. Run AI tagging on our images and state the region where the AI processing runs.
11. Open the screen a DAM manager uses to create a user role.
12. Name every feature shown today that needs a higher tier or an add-on.

Request 12 links the demo to the commercial conversation. DAMSelection assessment: demo environments often run the vendor's top tier, so features shown live can sit outside the tier quoted. Ask for the answer in writing and check it against the quote before pricing negotiation.

How to record and score red flags

Record every DAM demo red flag in the evidence log with a timestamp, the scenario step and the panel member who saw it. The scoring matrix requires evidence for every score, and a red flag is negative evidence.

Use a three-column log: timestamp, observation and affected criterion. Map each flag to one of the 12 DAMSelection criteria. Script refusal on a licence-expiry scenario lowers rights and licence management. Export vagueness lowers API and extensibility. Partner-only configuration lowers administration and total cost profile.

Score red flags through the criteria they affect, so one flag never counts twice. The panel reviews the log within 24 hours of each demo, while memories are fresh. DAMSelection rule of thumb: three or more flags across different groups justify dropping the vendor before the proof of concept.

Red flags on the buyer side

Buyer behaviour can create the same symptoms as vendor red flags, so the panel checks its own preparation before blaming a vendor. Four buyer-side causes recur in selections:

• Scripts sent less than one week before the demo.
• Sample assets that lack metadata or rights information.
• Panel members who join late or score only some vendors.
• Unequal time slots or different scenario orders between vendors.

Fix these with one rule: the same panel, the same slot length, the same assets and the same script for every vendor. A red flag then reflects the platform and the vendor, and the evidence holds up when a dropped vendor asks for feedback.