Implementation worksheet · 5 min read
A Lifecycle Marketing Platform Demo Script with Failure Cases
Bring a written script to every platform demo: your fixed lifecycle brief, four build requests you watch performed live, and five failure cases you explicitly ask to see — a journey hitting a missing event, a send exceeding a frequency cap, a segment computed on late data, an experiment stopped early, and a user withdrawing consent mid-journey. How a platform behaves in failure is the product; the happy path is the brochure.
An unscripted demo is a guided tour of whatever the vendor rehearsed. The script converts it into an inspection — same stops for every vendor, including the rooms they'd rather not show.
Put it into practice
1. Send the script ahead
Vendors prepare either way; sending the script means the good ones prepare your scenario instead of their showreel. A vendor who ignores the script has answered a question too.
2. Watch builds, not slides
Each build request performed live in the product: create the journey branch, set the cap, define the segment. Narrated screenshots of any step get noted as 'not demonstrated'.
3. Run the five failure cases
Missing event, cap collision, late data, early-stopped experiment, mid-journey consent withdrawal. You're listening for concrete mechanics — queues, fallbacks, audit entries — versus reassurance vocabulary.
4. Log answers verbatim
One column per vendor, the actual words. 'That's handled automatically' with no mechanism named is a finding, and it repeats across vendors suspiciously often.
5. Debrief within a day
Score against the script while memory is fresh, and mark every 'follow-up answer coming' — the follow-up rate is itself a support-quality signal.
Demo script log
Copy this structure into your review document and record your observed result for each row.
| Script item | Shown live? | Mechanism named | Notes |
|---|---|---|---|
| Journey with missing event | |||
| Frequency cap collision | |||
| Late/duplicate event data | |||
| Experiment stopped early | |||
| Consent withdrawn mid-journey |
A failure worth checking
The rehearsal capture: letting the vendor 'circle back' on every failure case and closing the demo on the happy path. The follow-up email that arrives is written by solutions engineering, not the product. If a failure case can't be shown live in a demo environment, assume it isn't handled the way the answer will claim.
Common questions
Isn't demanding failure cases adversarial?
It's the fastest sorter of vendor quality: strong platforms enjoy showing their failure handling because it's real engineering. Discomfort with the question is data about the answer.
What if we've already seen standard demos?
Request a second, scripted session with your brief — framing it as final-stage diligence. Any serious vendor at decision stage says yes within a day.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.