Work Understanding - Evidence-led demo script

The story arc

The arc is a single move from mystery to a testable change:

'You know this process is slow or expensive, but not why.' The customer sees the SLA miss and the backlog, but the time disappears into handoffs, waiting, swivel-chair and rework - so improvement becomes guesswork, and money goes to the wrong step.

'Here is how the work actually flowed - not how a whiteboard says it does.' Show the discovered flow and its variants. The power is that this is observed, not self-reported.

'Here is where the time actually sits.' Separate active handling from waiting; show a friction finding with its evidence.

'Here is the one change we would validate first - and here is how we would prove it.' Land on the improvement workspace and the before/after, not on a savings total.

The arc deliberately ends on an experiment, not a number. The credibility of the whole demo comes from refusing to stack findings into a headline saving and instead showing the disciplined path to a measured result.

The five beats, screen by screen

Run each screen as question -> screen -> evidence -> interpretation -> next step. Single value point per screen in bold.

1. Overview (/#/home) - Question: 'where does the time actually go in this process?' Value point: this app answers why, not just what. Set the frame; do not linger.
2. Workflow discovery (/#/discovery) - Evidence: the discovered flow and a variant. Value point: observed flow, including the paths a map never captured. Interpretation to say: 'this is inferred from real signal - an evidence-based draft to confirm with you, not a drawing.'
3. Step time and waiting (/#/steps) - first drill-down. Evidence: active handling vs waiting. Value point: the days usually sit in waiting, not in the busy step. Interpretation: attacking the longest active step can leave the cycle unchanged.
4. Friction and leakage (/#/friction) - second drill-down and the heart of the demo. Evidence: one friction finding with its backing - step time, where it sits, how often. Value point: a concrete, evidence-backed place time is being lost. Interpretation (the integrity line): 'this is an observed contribution to delay with a confidence - a strong candidate to validate, not proven waste.'
5. Improvement workspace (/#/improve) - Next step: 'here is the experiment we would run - baseline, one change, an owner, re-measure.' Value point: the product closes the loop with a measured before/after, so the saving is a result, not a hope.

The explicit limitation to state out loud

Say this plainly, in the demo, unprompted - it is what makes the rest believable:

'Everything you are seeing is inferred from captured signal, so each finding is an observed contribution with a confidence, not proven cause. The discovered flow is a draft to confirm with you; a conformance figure depends on which reference path we measure against; and I will not add these findings up into a single savings number, because overlapping findings can touch the same time. The real saving comes from a measured before/after on a validated finding, against your own baseline.'

This is not a disclaimer that weakens the demo - it is the differentiator. A customer who has been burned by a consultant's stacked-savings deck or a WFM tool that overclaimed will trust the rep who draws the line themselves. State it once, clearly, around beat 4, and it carries the whole call.

Also resist two live pulls: the pull to total the friction list, and the pull to promise a capture or access capability from the demo - the real detection method, coverage and privacy configuration are confirm with product.

The discovery questions this demo answers

Pair the demo with the discovery it is built to answer, so the screens land on a real problem rather than a feature tour:

• 'When you last tried to speed up this process, how did you decide what to change?' (sets up discovery vs guesswork)
• 'How do you know today where the time actually goes - waiting, rework, or handoffs?' (sets up step time and waiting)
• 'If we showed you the one step holding the most time, could you own a change and measure it?' (sets up the improvement workspace)
• 'Have you ever bought automation or added headcount and seen the cycle time barely move?' (sets up the wrong-target insight)
• 'How would you prove to your own leadership that a change actually worked?' (sets up before/after as the headline, not opportunity)

If a prospect cannot answer the first two, the demo's value is obvious. If they can, the demo shows them evidence for what they only suspected - and a disciplined way to act on it.

Running it live and handling the room

Timing: about seven minutes - overview (30s), discovery (90s), step time (90s), friction (2 min, the anchor), improvement workspace (90s). Two drill-downs (step time, friction); one explicit limitation (beat 4).

If asked 'so how much could we save?' - 'The honest answer is: here is the opportunity we would validate first, and here is the experiment that turns it into a measured saving. I would rather show you one proven before/after than a stacked estimate.' Do not give a stacked total.

If asked 'can a manager see one person's screen?' - describe what is shown at what aggregation, and say the real capture and access configuration is confirmed with product and their security owner. Never overclaim.

If asked 'we already mapped our processes' - 'That was a manual snapshot, stale on arrival and based on how people say they work. This discovers how work actually flowed, including the variants the map missed, and keeps measuring.'

Close on the next step, not the tool: agree one process to run a real finding-and-experiment on, with an owner on their side. That is the pilot from the adoption playbook.