A script, not a tour
Assemble the nine-beat script — each beat with what is on screen, the one line to say, the risk, and the fallback — and review it like code.
- Build a demo as a nine-beat script rather than a feature tour
- Give every beat a line, a risk, and a fallback
- Treat the script as a reviewable file that traces to findings and criteria
A tour shows features in the order the menu lists them. A script tells a story in the order a person can follow. Yours is nine beats and about thirty-five minutes, and it starts where the customer already lives — a morning brief in M365 Copilot — before it ever opens Dynamics. Each beat carries four things: what is on screen, the one line you say, the risk, and the fallback if the risk lands. Here is the whole board:
B1 Cold open
S1- Morning brief in M365 Copilot surfaces the consultant's overnight email about Meridian; pivot into Dynamics.
- “This is where the seller already lives — mail and Teams, not a new portal.”
- The brief pulls nothing relevant.
- A pre-captured brief screenshot from the rehearsal folder.
B2 Client 360
S1- Meridian record: mandates, coverage, service history, and meeting notes in one pane.
- “One record. Everything the last five people learned about Meridian is here.”
- A related grid is empty because data did not load.
- The understudy screenshot of the fully loaded record.
B3 Pipeline review with Copilot
S2- The $400M global-equity win-back at Meridian; Copilot summarizes what changed this week.
- “The pipeline is data now, not a quarterly slide someone rebuilt by hand.”
- Copilot summary is generic.
- Read the change log directly from the opportunity timeline.
B4 Relationship intelligence
S1- Who-knows-whom via consultant coverage.
- “"Who here knows Meridian's CIO" used to take days. It is one hop now.”
- Coverage graph is sparse.
- The coverage table with the analyst and rating columns.
B5 RFP agent
S3- New DDQ intake → drafted answers with provenance → SME review queue.
- “Weeks of re-answering the same questions become a first draft in hours, every line sourced.”
- The agent drafts without citations.
- A pre-run draft in the review queue with provenance shown.
B6 Onboarding
S4- Aldgate Re board; the KYC chase agent's reminder fires; state advances.
- “The board shows the funding date and exactly what is blocking it.”
- The trigger does not fire on cue.
- Advance the stage manually; show the agent run history.
B7 Service
S5- Tier-1 inquiry deflected with a grounded answer; a complex case routed with context.
- “The safe questions self-serve; the hard ones arrive with the context already attached.”
- The grounded answer is wrong or unsupported.
- Show the citation panel and the guardrail that withholds an ungrounded answer.
B8 Governance interlude
S6- For Sarah: agent identity, permissions, audit trail.
- “Every agent you just saw has an identity, a permission boundary, and a log.”
- Security asks a question the demo tenant cannot answer.
- The governance slide with Entra Agent ID and the audit-log excerpt.
B9 Close
S1 · S2 · S3 · S4 · S5 · S6- The S1–S6 traceability table; leave-behind commitment.
- “Here is every success criterion you set, and the beat that met it.”
- Running long; the close gets rushed.
- The one-page traceability table as a printed leave-behind.
Delivery-day pre-flight
Everything below runs at 7 a.m., not in the room.
- Tenant health — sign in on both browser profiles; confirm no forced password reset.
- Data freshness — run the story-account timeline query; confirm Meridian and Aldgate Re look right.
- Agent warm-up — trigger one RFP draft and one KYC chase so the first live run is not the first run.
- Fallback deck on local disk — the understudy screenshots, exported, offline.
- Second browser profile — a clean, logged-in fallback if the primary session wedges.
- Network fallback — a phone hotspot configured and tested.
- S1One client 360.
- S2One mandate lifecycle with stage-appropriate AI.
- S3RFP first-draft from weeks to hours, with provenance.
- S4Onboarding orchestration with visible state and automated document chase.
- S5Tier-1 service deflection safely grounded in client data.
- S6Every capability shown has a governance answer.
Read down the criteria column. Every beat proves a success criterion the client set in discovery, and the close is nothing but the traceability table made visible. Demo craft in one sentence: start where they live, never apologize for a preview label — name it — and let the last beat be their own words handed back.
The demo-director assembles the script from the findings and the entity model, giving each beat its line, risk, and fallback. Because it is a file, it is reviewed like code — you can diff a change to beat five, comment on the risk in beat seven, and see the whole arc in one place. When the script is agreed, the director hands it to the understudy to walk in a real browser, which is the next lesson.
Why the fallback is part of the beat
Amateurs script the happy path and improvise the failure. Professionals script the failure too. Every beat names what could go wrong on stage and exactly what you do when it does — usually cut to the rehearsal screenshot of that same beat, working. Writing the fallback while you write the beat forces you to admit the risk while you can still design around it, instead of discovering it at minute twenty in front of Security.
In the field
Take one workload and write its beat with all four fields — on screen, the line, the risk, the fallback. Say the line out loud. If it needs a second sentence to make sense, the beat is doing too much; split it.
- 05-agents/demo-script.md — the nine-beat script