Scripted DAM demo scenarios

Why scripted demos decide DAM selections

Scripted DAM demos decide selections because they test each vendor on the buyer's own work. DAMSelection assessment: generic vendor demos carry no selection value, because each vendor shows its strongest features on data prepared for the purpose.

A scripted demo removes three distortions at once:

• Different content: every vendor works with the same sample assets and metadata.
• Different tasks: every vendor performs the same steps in the same order.
• Different judgement: the panel scores against pass criteria written before the first demo.

Scripted demos sit in checkpoint 5, Test, of the Selection Route. They follow the RFP and come before the proof of concept, which the final one or two vendors run with real users.

Anatomy of a scripted scenario

A scripted DAM scenario has seven parts, and a scenario missing one of them cannot be scored fairly. The table lists each part and what it contains.

Each scenario follows one real task from start to finish. A task that crosses teams reveals more than a feature tour. A product shoot that ends on a marketplace tests upload, metadata, linking and delivery in one flow.

How to write a scenario in seven steps

Writing a DAM demo scenario takes about half a day per scenario once requirements and user stories exist. Follow seven steps.

1. Pick a task that groups several must-have requirements from the requirements checklist.
2. Name the user and the business outcome, using a user story.
3. Prepare starting data from real assets, including a few deliberate exceptions.
4. Write the steps as outcomes the vendor must reach, in the order the user would work.
5. Write three to six pass criteria that a panel member can check without interpretation.
6. Set a timebox: the Demo Script Generator allows 25 minutes per scenario, with a 60-minute minimum per session.
7. Assign a weight that reflects business value, and publish it to the panel before the first demo.

Deliberate exceptions matter most. A data file with a few broken links or a missing mandatory value shows how the DAM handles errors, which a clean dataset never reveals.

Writing pass criteria that score

A DAM pass criterion is an observable result with a threshold, which two panel members would score the same way. Criteria phrased as qualities, such as "intuitive" or "flexible", produce scores that reflect taste.

Use an example score definition so every panel member applies the same scale.

Worked example: a fully written scenario

The worked example writes out one complete DAM demo scenario from the DAMSelection scenario library, ready to copy and adapt. All figures are example values for a mid-sized manufacturer.

Scenario 1: Onboard a product shoot

User: e-commerce content specialist.

Context: a seasonal shoot delivered 200 images for 40 products. The images must reach three marketplaces within one working day of approval. Today the team renames, resizes and links files by hand.

Starting data sent two weeks ahead:

• 200 product images named by the photographer's convention: shoot code plus frame number.
• A PIM export file with SKU, GTIN, product name, colour and the frame numbers per SKU.
• Five images whose frame numbers appear in no SKU row, included on purpose.
• The buyer's draft metadata schema with eight mandatory fields and their controlled vocabularies.
• Rendition specifications for three marketplaces: pixel size, file format and background per marketplace.

Steps the vendor performs live:

1. Upload all 200 images in one batch.
2. Apply shared metadata in bulk: brand, season, shoot, usage rights and permitted channels.
3. Link each image to its SKU from the PIM export, without linking images one by one.
4. Show the list of images that matched no SKU.
5. Generate renditions for the three marketplaces from the master files.
6. Name the renditions by GTIN and view, following the buyer's naming rule.
7. Show the complete asset set for one SKU as the PIM or a storefront would request it through the API.

Pass criteria, each scored 0 to 5:

• All 195 matchable images linked to the correct SKU.
• The five unmatched images listed as exceptions, with none linked wrongly.
• No image reaches approved status while a mandatory field is empty.
• Ten renditions picked at random by the panel match their marketplace specification.
• Rendition file names follow the naming rule.
• Scenario completed within 30 minutes.

Evidence: timestamps per step, the exported link list, and screenshots of the exception list and two renditions.

Weight: 20% of the total demo score.

Statements the vendor must add after the scenario: how linking runs in production, whether scheduled, event-driven or manual. The vendor also states the AI credits consumed if any step used AI.

The GS1 Product Image Specification, release 4.4 ratified in April 2024, defines GTIN-based file naming and image types. Buyers who supply retailers can take the naming rule for step 6 from it.

Choosing four to six scenarios

A DAM demo script holds four to six scenarios chosen from the organisation's top priorities, plus one export scenario. The DAMSelection scenario library holds 12 scenarios; the table maps them to typical priorities.

DAMSelection assessment: always include the metadata schema scenario. The metadata model decides DAM success, and configuring the buyer's schema shows whether administrators can run the DAM without vendor services.

Include "Export everything" in every script. It tests the exit before the contract, while the buyer still holds negotiating power.

The sample asset pack

The DAM sample asset pack is the set of real files and data every vendor receives, and its quality decides how much the demo reveals. Send the same pack to every vendor under a non-disclosure agreement.

• 200 to 500 real assets covering every major type: product images, lifestyle images, video, layered design files and documents.
• The draft metadata schema and controlled vocabularies.
• A PIM or product data export for product-linked scenarios.
• Rights data for licensed assets, including at least one licence that expires during the demo week.
• Deliberate exceptions: duplicates, missing values and unmatched identifiers.
• Files at realistic sizes, including at least one large video.
• Embedded IPTC and XMP metadata in some files, to show whether the DAM reads it on ingest and keeps it in renditions.

Remove personal data the vendor does not need, or confirm a data processing agreement first.

Running the demo day

A DAM demo day runs on fixed rules that the script states in advance, so every vendor plays the same game. DAMSelection rule of thumb: send scripts and assets two weeks ahead and allow two to three hours per vendor.

The written RFP answers cover architecture, security and commercials in depth, so the demo keeps those questions short.

Rules to state in the script:

• The vendor performs every step live in the system.
• Pre-built sample data is not accepted; the vendor uses the buyer's pack.
• Roadmap features score 0.
• The same panel attends every demo and scores every scenario.
• The session is recorded for scoring, with the vendor's consent.

Scoring the demo

DAM demo scoring happens within 24 hours of each demo, with each panel member scoring alone before the panel calibrates. Independent scores first prevent the loudest voice from setting the result.

Record every score in the scoring matrix with its evidence: a timestamp, a file or a screenshot. Note any behaviour from the list of demo red flags, such as refusing a step or deferring to the roadmap. The two highest-scoring vendors move to the proof of concept.

Generate your script

The Demo Script Generator builds a DAM demo script from the 12 DAMSelection scenarios, with context, steps and pass criteria for each. Select the scenarios that match your priorities, add your organisation name and export the script as a text file.

Adapt every generated scenario to your data before sending it. Replace generic counts with your own, add deliberate exceptions and set weights. The generated script is a starting point; your sample asset pack turns it into a test.