Solution Demo Script: [Solution name] for [Client name]
Script for a live solution demonstration in a sale, a tender shortlist or a steering review:
objectives, audience map, storyline tied to win themes, personas and demo data, environment and
logistics checklist, timed agenda, scene-by-scene clicks with talk track and proof points,
coverage of the client's requirements, rules for buyer-scripted demonstrations, Q&A and
objection preparation, fallback plan, rehearsal and go or no-go, roles, and the follow-up and
debrief. There is no formal standard for demo scripts; the structure follows common pre-sales
practice, and the buyer-scripted rules are consistent with the supplier evaluation activities
of an acquirer as described in ISO/IEC/IEEE 41062:2024 (software acquisition). Replace every [bracketed] value and every row
marked Example; the worked example demonstrates an account-based ticketing back office to a
regional transit authority.
Document control
| Field | Value |
|---|
| Document ID | [DS-001] |
| Version | [0.1] |
| Status | [Draft / Rehearsed / Approved for delivery / Delivered] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@bid-manager], [@account-executive], [@product-specialist] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Commercial in confidence] |
| Opportunity | [Opportunity name and CRM ID] |
| Demo event | [Discovery demo / Shortlist demo / Executive demo / PoC readout] |
| Date, time, duration and place | YYYY-MM-DD, [hh:mm], [minutes], [on site / remote / hybrid] |
| Buyer script reference | [Buyer script ID and version, or "none: our own storyline"] |
Approvals
| Role | Name | Decision | Date |
|---|
| Bid manager | [@name] | [Approve / Approve with changes] | YYYY-MM-DD |
| Account executive | [@name] | [Decision] | YYYY-MM-DD |
| Solution architect | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft of storyline and scenes |
| 0.2 | YYYY-MM-DD | [@name] | Example: After rehearsal 1: scene D-03 cut to 6 minutes, fallback video recorded |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved for shortlist demonstration |
Contents
1. Objectives and context
1.1 Demo objectives
| ID | Objective | How we will know it was met |
|---|
| OBJ-01 (Example) | The fare policy team believes they can change fares without a vendor release | They ask to try the fare simulator themselves, or say so in the debrief |
| OBJ-02 (Example) | The evaluation panel sees fare capping working with real validator tap data | Panel confirms scenario D-02 against their checklist |
| OBJ-03 (Example) | The CIO is reassured that rider data stays in the country | No open data residency question at the end |
| OBJ-04 (Example) | Agreement to a two-week proof of concept on the authority's own validators | Date and scope agreed before we leave |
| OBJ-05 (Example) | The customer service manager sees a disputed charge resolved in one call | Manager's click count for the refund is within their expectation, or they say so |
| OBJ-06 (Example) | Finance sees daily apportionment posted to the ERP | CIO or finance attendee confirms the posting matches their chart of accounts |
| [OBJ-NN] | [Objective] | [Evidence] |
1.2 Context
| Item | Value |
|---|
| Stage in the buying process | Example: Shortlist demonstration after written RFP responses; 3 bidders |
| What the client already knows | Example: Our written response; scored 3 of 5 on fare flexibility because the panel could not picture the simulator |
| Known competitor positioning | Example: Competitor A shows a polished rider app; Competitor B claims lower price |
| What we must not do | Example: Show roadmap features as available; show the rider app at length (not scored) |
2. Audience map
| Attendee | Role | Scores or influences | Cares about | Watch for | Scene for them |
|---|
| [Name] (Example) | Head of fares and revenue | Scores fare flexibility (criterion T1) | Changing fares quickly and safely | Will ask about multi-operator revenue split | D-04, D-06 |
| [Name] (Example) | Customer service manager | Scores usability | Handling disputed charges by phone | Will time how many clicks a refund takes | D-03 |
| [Name] (Example) | CIO | Influences, final recommendation | Data residency, integration with ERP | Will ask who supports at 3 a.m. | D-05, D-06 |
| [Name] (Example) | Procurement lead | Runs the process | Equal treatment, timing | Will stop overruns | All |
| [Name] | [Role] | [Scores] | [Cares about] | [Watch for] | [Scene] |
3. Storyline and win themes
3.1 Storyline
[Write the storyline in three to five sentences.] Example: We follow one weekday in the
authority's network. Ana, a commuter, taps her bank card on a bus and a tram and is capped
automatically. In the afternoon she disputes a charge and the contact centre resolves it in one
call. Meanwhile the fares team prepares next month's fare change, tests it against last month's
real journeys and publishes it without a vendor release. At the end of the day the finance team
sees revenue apportioned to each operator and posted to the ERP.
3.2 Win themes carried by the demo
Use the same IDs as the RFP Technical Response (business/rfp-technical-response).
| Win theme | Message in one sentence | Proven in scenes | Proof shown |
|---|
| WT-001 (Example) | Go-live before the smartcard contract ends | D-01, D-06 | Release plan slide; reference client running the same release |
| WT-002 (Example) | Rider data stays in the country | D-05 | Live view of the two in-country regions and key management screen |
| WT-003 (Example) | Fare changes in days, tested on real journeys | D-04 | Simulator replays last month's taps against the new rule |
| [WT-NNN] | [Message] | [Scenes] | [Proof] |
4. Personas and demo data
4.1 Personas
| Persona | Represents | Used in scenes | Login or device |
|---|
| Ana, commuter (Example) | Rider with a contactless bank card | D-01, D-02, D-03 | Test card ending 4242 on validator emulator |
| Ben, contact centre agent (Example) | Customer service staff | D-03 | agent.ben in demo tenant |
| Chloe, fares analyst (Example) | Fares and revenue team | D-04 | fares.chloe |
| David, finance controller (Example) | Finance | D-06 | finance.david |
| [Persona] | [Role] | [Scenes] | [Login] |
4.2 Demo data
| Data set | Content | Source | Lawful to use | Reset method |
|---|
| Network and fares (Example) | The authority's published zones, routes and fare tables | Public website, loaded by us | Yes, public | Script reset-fares.sh |
| Journey history (Example) | 30 days of synthetic taps shaped like the authority's published ridership | Generated | Yes, synthetic | Reload snapshot |
| Rider accounts (Example) | 50 fictitious riders | Generated | Yes, fictitious | Reload snapshot |
| [Data set] | [Content] | [Source] | [Yes / No: reason] | [Method] |
Never use real personal data from another client in a demo. If the client offers their own data,
agree in writing how it will be handled and deleted.
5. Environment and logistics checklist
| Check | Owner | Day before | One hour before |
|---|
| Demo tenant reachable from the venue network or a mobile hotspot | @demo-engineer | [ ] | [ ] |
| All persona logins work; MFA devices charged and present | @demo-engineer | [ ] | [ ] |
| Data reset to the starting snapshot | @demo-engineer | [ ] | [ ] |
| Feature flags set; nothing unreleased visible | @product-specialist | [ ] | [ ] |
| Validator emulator and test cards working | @demo-engineer | [ ] | [ ] |
| Presenter laptop: updates paused, notifications off, browser profile clean, zoom at 125 percent | @demo-engineer | [ ] | [ ] |
| Second laptop with the same setup ready (fallback) | @demo-engineer | [ ] | [ ] |
| Recorded fallback videos for D-02 and D-04 on local disk | @demo-engineer | [ ] | [ ] |
| Display adapters, clicker, power, spare cables | @demo-engineer | [ ] | [ ] |
| Remote session: meeting link tested, screen share at the right resolution, recording consent asked | @bid-manager | [ ] | [ ] |
| Printed leave-behind and agenda | @bid-manager | [ ] | [ ] |
6. Agenda and timing
| Time | Block | Presenter | Minutes | Cut if late |
|---|
| 00:00 | Introductions and objectives check with the client | @account-executive | 5 | No |
| 00:05 | D-01 The network in one view | @solution-architect | 5 | Shorten to 2 |
| 00:10 | D-02 Fare capping across bus and tram | @product-specialist | 12 | No |
| 00:22 | D-03 Disputed charge resolved in one call | @product-specialist | 10 | Shorten to 6 |
| 00:32 | D-04 Fare change tested on real journeys | @product-specialist | 15 | No |
| 00:47 | D-05 Data residency and security | @solution-architect | 8 | No |
| 00:55 | D-06 Revenue apportionment and ERP posting | @solution-architect | 8 | Shorten to 4 |
| 01:03 | Questions | All | 12 | No |
| 01:15 | Summary and next steps | @account-executive | 5 | No |
| 01:20 | End (hard stop) | | 80 total | |
7. Scene-by-scene script
7.1 Scene template
| Field | Content |
|---|
| Scene ID and title | [D-NN] [Title] |
| Purpose | [Which objective, win theme and requirement IDs it proves] |
| Starting state | [Screen, persona logged in, data state] |
| Click path | [Numbered steps] |
| Talk track | [Key sentences, in the client's words] |
| Proof point | [What the audience sees that confirms the claim] |
| So what | [One sentence of value for this audience] |
| Transition | [Bridge sentence to the next scene] |
| Fallback | [Video, screenshot or alternative path] |
7.2 D-02 Fare capping across bus and tram (Example)
| Field | Content |
|---|
| Purpose | OBJ-02; WT-003 indirectly; answers FR-012, FR-013 and FR-019 |
| Starting state | Ana's account with no journeys today; validator emulator showing bus route 12 |
| Talk track opening | "Ana does not know what a fare cap is. She just taps. Let us see what the system does for her." |
| Step | Action | What the audience sees | Talk track |
|---|
| 1 | Tap test card on the bus validator emulator | Green tick, fare EUR 2.40 shown in the account view | "Each tap is priced as it arrives, using the published fare table." |
| 2 | Tap the same card on the tram validator twice | Two more journeys priced | "Same card, different operator, one account." |
| 3 | Tap a fourth time | Journey priced at zero; account shows "Capped today" | "The daily cap is reached; every further journey today is free. Ana did nothing." |
| 4 | Inject a late offline tap from the morning | Journeys re-priced in device-time order; total unchanged | "Offline taps arrive late on real networks. The result is the same whatever the arrival order." |
| 5 | Open the audit trail for the day | Each pricing decision with the rule that applied | "Your revenue team can explain every charge to a rider or an auditor." |
| Field | Content |
|---|
| Proof point | Panel sees the cap applied and the audit trail with rule references |
| So what | "Capping works across operators and survives offline validators, which was the main delivery risk in your RFP." |
| Transition | "Of course, some riders will still dispute a charge. Let us see Ben handle that." |
| Fallback | Recorded video V-D02 (3 minutes); screenshots of steps 3 and 5 in the backup deck |
7.3 D-04 Fare change tested on real journeys (Example)
| Field | Content |
|---|
| Purpose | OBJ-01; WT-003; answers FR-024 and FR-025 |
| Starting state | Chloe logged in to the fares workspace; draft fare change "Off-peak discount" prepared but not published |
| Step | Action | What the audience sees | Talk track |
|---|
| 1 | Open the draft rule | Rule written as configuration with effective date | "This is the change your team asked for in the RFP: an off-peak discount, defined by your staff." |
| 2 | Run the simulator on last month's journeys | Progress bar, then revenue and rider impact summary | "Before anyone is charged, we replay a month of journeys against the new rule." |
| 3 | Drill into riders who pay more | List of affected journeys | "You see who wins and who loses before you publish." |
| 4 | Submit for approval; approve as second user | Four-eyes approval recorded | "No single person can change fares." |
| 5 | Show the publication schedule | Rule goes live at the effective date on all validators | "From idea to live in days, without a release from us." |
| Field | Content |
|---|
| Proof point | Simulator result and approval record |
| So what | "Fare policy becomes your decision on your timetable." |
| Transition | "All of this runs on rider data. The CIO asked where that data lives." |
| Fallback | Video V-D04; pre-computed simulator result snapshot if the run is slow |
7.4 Scene index
| Scene | Title | Objective | Win theme | Requirement IDs | Minutes |
|---|
| D-01 (Example) | The network in one view | OBJ-02 | WT-001 | FR-010 | 5 |
| D-02 (Example) | Fare capping across bus and tram | OBJ-02 | WT-003 | FR-012, FR-013, FR-019 | 12 |
| D-03 (Example) | Disputed charge resolved in one call | OBJ-05 | None | FR-031, FR-034, FR-041 | 10 |
| D-04 (Example) | Fare change tested on real journeys | OBJ-01 | WT-003 | FR-024, FR-025 | 15 |
| D-05 (Example) | Data residency and security | OBJ-03 | WT-002 | SEC-003, SEC-007 | 8 |
| D-06 (Example) | Revenue apportionment and ERP posting | OBJ-06 | WT-001 | FR-064; interface INT-003 (apportionment feed to the ERP) | 8 |
Write the remaining scenes (D-01, D-03, D-05, D-06) with the same structure as 7.2 and 7.3.
8. Coverage matrix: requirements, win themes and proof
| Requirement or criterion | Compliance status in our response | Scene | Shown live or explained | Evidence left behind |
|---|
| FR-012 Daily fare cap (Example) | C | D-02 | Live | Video V-D02 |
| FR-019 Late offline taps (Example) | C | D-02 | Live | Audit trail export |
| FR-024 Fare rules as configuration (Example) | C | D-04 | Live | Simulator report |
| FR-041 Online refund with approval workflow (Example) | PC: two-step approval now, multi-level approval in release 2 | D-03 | Live, with the partial status said aloud | Refund approval screenshot, release 2 note |
| FR-064 Revenue apportionment between operators (Example) | C (custom extension) | D-06 | Live | Apportionment report and ERP posting file |
| SEC-003 Personal data in the country (Example) | C | D-05 | Live | Region view screenshot |
| SEC-007 Customer-managed encryption keys (Example) | ALT: keys in an in-country cloud HSM under the authority's control (DEV-003) | D-05 | Explained with architecture slide | Architecture diagram, deviation DEV-003 |
| Criterion T1 Solution fit (Example) | Not applicable | D-02, D-04 | Live | Leave-behind summary |
| [ID] | [C / PC / NC / ALT] | [Scene] | [Live / Explained] | [Evidence] |
Keep the statuses identical to the RFP Compliance Matrix (business/rfp-compliance-matrix).
9. Buyer-scripted demonstration rules
| Rule | How we comply |
|---|
| Follow the buyer's scenario order and IDs | Example: Our scenes renumbered to match buyer scenarios BS-1 to BS-6; mapping below |
| Use the buyer's data where provided | Example: Buyer's fare table loaded and checked two days before |
| Respect time boxes per scenario | Example: Timekeeper shows a card at 2 minutes remaining |
| Show only generally available features unless the script allows roadmap items | Example: Feature flags checked; roadmap only in the Q&A if asked |
| Answer the scenario as written, then add value briefly | Example: One sentence of added value per scenario, no more |
| Do not contact evaluators outside the session | Example: All follow-up through the procurement lead |
| Buyer scenario | Our scene | Owner | Notes |
|---|
| BS-1 Configure network and fares (Example) | D-01 and D-04 step 1 | @product-specialist | Buyer asks for configuration live; no pre-built rule |
| BS-2 Fare capping (Example) | D-02 | @product-specialist | |
| [BS-N] | [D-NN] | [@owner] | [Notes] |
10. Questions and objection preparation
| ID | Expected question or objection | Short answer | Proof | Who answers |
|---|
| QA-01 (Example) | "What happens if the cloud region fails during the morning peak?" | Validators keep accepting taps offline; the second in-country region takes over; taps are priced when it is back | DR test report summary | @solution-architect |
| QA-02 (Example) | "Competitor B is cheaper." | Explain total cost over the contract, including fare changes we do not charge for | TCO summary slide | @account-executive |
| QA-03 (Example) | "Can our own staff build reports?" | Yes, through the reporting workspace; show one report in 2 minutes if time allows | Live or screenshot | @product-specialist |
| QA-04 (Example) | "Can we use our on-site HSM?" | Our response offers an in-country cloud HSM under your control instead (deviation DEV-003); show the key management screen | Deviation DEV-003, key management screen | @solution-architect |
| [QA-NN] | [Question] | [Answer] | [Proof] | [@owner] |
Rules: never show or promise a feature that is not in the written response; if you do not know,
say so and commit to a written answer through the procurement lead.
11. Risks and fallback plan
| ID | Risk | Trigger to switch | Fallback | Time to switch |
|---|
| FB-01 (Example) | Venue network blocks the demo tenant | Tenant not reachable at the one-hour check | Mobile hotspot on the second laptop | 2 minutes |
| FB-02 (Example) | Validator emulator fails | No response after one retry | Recorded video V-D02, presenter narrates | 30 seconds |
| FB-03 (Example) | Simulator run slower than 90 seconds | Progress bar not finished at 90 seconds | Open the pre-computed result snapshot | 15 seconds |
| FB-04 (Example) | Unexpected defect on screen | Any error message | Acknowledge, move to the backup path or video, log for follow-up | Immediate |
| FB-05 (Example) | Key presenter unavailable | Illness or travel delay | Named understudy rehearsed on the same script | Before the event |
Say what happened honestly when you switch. Evaluators forgive a failure handled calmly; they do
not forgive pretending.
12. Rehearsal plan and readiness
| Rehearsal | Date | Participants | Focus | Outcome |
|---|
| R-1 Content run (Example) | YYYY-MM-DD | Demo team | Storyline, timings, scene order | Timings recorded; D-03 shortened |
| R-2 Dress rehearsal (Example) | YYYY-MM-DD | Demo team plus red team of three colleagues playing the panel | Questions, objections, fallbacks triggered on purpose | FB-02 tested; two new questions added |
| [R-N] | YYYY-MM-DD | [Participants] | [Focus] | [Outcome] |
| Go or no-go criterion | Status |
|---|
| Every scene runs end to end on the delivery laptop within its time box | [ ] |
| All fallbacks tested at least once | [ ] |
| Coverage matrix matches the compliance matrix | [ ] |
| Every presenter has rehearsed their scenes and answers | [ ] |
| Logistics checklist complete for the day before | [ ] |
13. Roles and responsibilities
| Role | Name | Responsibilities |
|---|
| Lead presenter and storyteller | [@account-executive] | Opens, frames objectives, closes, owns next steps |
| Solution architect | [@solution-architect] | Architecture, security and integration scenes; technical questions |
| Product specialist (driver) | [@product-specialist] | Runs the product in scenes D-02 to D-04 |
| Demo engineer | [@demo-engineer] | Environment, data resets, fallbacks, second laptop |
| Timekeeper and observer | [@bid-manager] | Keeps time, notes reactions and questions verbatim, signals cuts |
14. Follow-up and debrief
14.1 Follow-up actions
| ID | Commitment or question | Owner | Channel | Due |
|---|
| FU-01 (Example) | Send DR test report summary (QA-01) | @solution-architect | Procurement portal | YYYY-MM-DD |
| FU-02 (Example) | Confirm proof of concept scope and dates (OBJ-04) | @account-executive | Procurement lead | YYYY-MM-DD |
| [FU-NN] | [Commitment] | [@owner] | [Channel] | YYYY-MM-DD |
14.2 Debrief
| Question | Notes |
|---|
| Which objectives were met (section 1.1)? | [OBJ-01 met / partly / not met, with evidence] |
| Which scenes landed and which did not? | [Notes] |
| Which questions surprised us? | [Add to section 10 for next time] |
| What did the panel say or do that signals their scores? | [Observations] |
| What changes in our proposal, price or proof of concept plan? | [Actions] |
Feed the results into the Opportunity Qualification (business/opportunity-qualification) and,
if a proof of concept follows, into its plan (architecture/proof-of-concept).
15. Glossary and references
15.1 Glossary
| Term | Meaning |
|---|
| Storyline | The narrative that links all scenes from the client's problem to their desired result |
| Scene | One self-contained part of the demo that proves a specific point |
| Talk track | What the presenter says during a scene |
| Proof point | Something the audience can see or check that confirms a claim |
| Win theme | A client-centred reason to choose this bid, backed by proof |
| Buyer-scripted demo | A demonstration where the buyer sets the scenarios, data and timing for all bidders |
| Fallback | Prepared alternative used when a live step fails |
15.2 References
| Reference | Version or date | Use |
|---|
| ISO/IEC/IEEE 41062, Software engineering: Life cycle processes: Software acquisition | 2024 (Edition 2) | Acquirer's view of supplier evaluation behind buyer-scripted demos |
| Client RFP and buyer demo script | [Version, date] | Scenarios, requirement IDs and rules |
| Our RFP technical response and compliance matrix | [Version] | Win themes and compliance statuses |
| [Product release notes] | [Release] | Confirms features shown are generally available |
Standard and licence note
Based on common solution pre-sales demonstration practice; no formal standard governs demo
scripts. The buyer-scripted demonstration rules are consistent with the acquirer's supplier
evaluation activities described in ISO/IEC/IEEE 41062:2024 (software acquisition), referenced by name only.
All text, structure and the worked example are original. Check the buyer's own instructions,
which always take precedence, and the current official version of any standard cited. Template
licence: MIT.