Use the demo lab
Objective. Navigate the live demo lab - the Enterprise Platform and the per-application demos - to tell an evidence-led story, so you can move from a business question to a real screen, to evidence, to interpretation, to a next step, without ever doing a feature tour.
The demo lab is your proof surface and your practice ground. This teaches how it is laid out, how to prepare a question-first path instead of a click-everything tour, and the discipline of showing a business question, the screen that answers it, the evidence, the honest interpretation and the next step.
See it in the demo
The customer problem (and ours)
A demo is where trust is won or lost in minutes. The default failure mode is the feature tour: the seller clicks through every tab, narrates what each button does, and the customer - who came with a business problem - leaves impressed and unconvinced, unable to say what any of it would change for them. The internal cost is just as real: a new joiner who does not know the lab fumbles live, lands on the wrong screen, or quotes a number they cannot defend, and the deal or the account pays for it. The demo lab exists so you never have to improvise. It is a stable, always-on set of live applications with seeded data, and the skill is using it to answer a specific question with evidence, not to prove the product has many screens.
How the lab is laid out
There are two ways in.
The Enterprise Platform (platform.demo.timechamp.io) hosts the applications in one chrome with shared services - use it to tell the staircase story end to end and to show that these are one platform, not disconnected tools.
Per-application demos each live at their own URL and open on an overview, then drill into the areas that matter:
- Time and Activity: /#/daily, /#/attendance, /#/dashboards
- Employee Monitoring: the timetracker overview dashboard
- Work Output: /#/overview, /#/transactions, /#/people
- Work Understanding: /#/home, /#/explorer, /#/sessions
- Capacity Planning: /#/overview, /#/dashboards, /#/reports
- Scheduling: /#/home, /#/planner, /#/optimize
- Real-Time Adherence: /#/control, /#/coverage, /#/agents
- Intraday Management: /#/tower, /#/forecast, /#/staffing
- RCM Operations: /#/mission (Mission Control)
- Quality and Call QA: /#/command-center
- RCM Insights: /#/ask, /#/discover, /#/dashboards, /#/data
- Value Leakage: /#/overview, /#/capacity, /#/process
Know the two or three screens per app that answer the most common question - not all of them.
The evidence-led path (not a tour)
Build every demo as a five-beat path (the S04 story spine):
- Business question - state the customer's actual question in their words: 'are we over-staffed against real demand?'
- The screen that answers it - go straight there (e.g. Capacity Planning overview, or Intraday control tower). One screen, chosen on purpose.
- The evidence - point to the specific number or finding and qualify it with context (denominator, scope, freshness - F06).
- The interpretation - say what it means and, crucially, one thing it does not prove (S04 requires an explicit limitation). This is where trust is earned.
- The next step - 'the action here would be X, owned by Y, measured by Z.'
Include two drill-downs where the evidence lives (e.g. from Work Output overview into transactions and people). Rehearse the path so you are not hunting live. The goal is that the customer can repeat, afterwards, exactly what question you answered and what they would do about it.
What to say / do
Sales preparation routine before any demo: pick the one or two business questions this customer actually has (from discovery, S02), choose the single app and the two or three screens that answer them, write the five beats, and pre-decide the one honest limitation you will name. Open on the overview, drill to evidence, close on a next step.
CSM use of the lab: it is your training and rehearsal surface for customer enablement (C04) - practise the explain, demonstrate, let-the-learner-do, check-understanding loop here before running it live, and use it to show a customer's own managers what a good review looks like.
Both roles: resist the completeness instinct. If a screen does not advance the question, do not open it. A tight three-screen path that answers one real question beats a twenty-screen tour every time, and it is far easier to deliver without fumbling.
Honest limits of the lab
The lab is seeded demo data, not a customer's production instance. That has two consequences you must respect.
First, never quote a demo figure as if it were a customer result or an industry benchmark. The numbers illustrate the mechanism; they do not prove an outcome (tie to F03 and F09). Say 'here is how this would look with your data' rather than implying the demo value is theirs.
Second, the lab shows product behaviour and shape, not a customer's entitlements, integrations or security posture. A screen appearing in the demo does not mean it is included, integrated or configured for a given customer - route those to F07 and F10 and to a specialist.
And apply the context questions to demo numbers too: when you point at a figure, be ready to say what it is over and how it would be kept fresh in reality. Modelling honesty on demo data is how the customer learns to trust the real numbers later.
Interpretation check
The lab is seeded demo data that proves mechanism and shape, not a customer's outcomes, entitlements or security posture; a figure or a screen in the demo is an illustration, never a customer result or a commitment.
In the field
For an OVO-style contact-centre conversation, a question-first path runs Intraday control tower (is today's plan viable) into RTA live adherence (are agents doing the planned activity and is it producing work), closing on a named corrective action - an evidence-led story that mirrors the live effort-to-outcome POC rather than touring every WFM screen.
Practical task
Pick one business question for a sample customer, build a written five-beat demo path against the real demo URLs (name the exact screens and two drill-downs), and script the one honest limitation you will state in the interpretation beat. Then dry-run it once end to end in the live lab.
Self-check
What are the five beats of an evidence-led demo path, and which beat most earns trust?
Business question, the screen that answers it, the evidence (qualified with context), the interpretation including one honest limitation, and the next step. The explicit limitation in the interpretation beat is what most earns trust.
Why is opening fewer screens usually better, and how do you decide which to open?
A tight path answers one real question clearly and is easy to deliver without fumbling; open only screens that advance the customer's stated question, decided from discovery beforehand, not every tab.
A customer points at a number in the demo and asks 'so we'd save that much?' How do you respond?
Clarify it is seeded demo data illustrating the mechanism, not their result, and reframe to 'here is how this would look with your data' plus the baseline/verification needed - never let the demo figure stand as a promised saving.
Does a screen appearing in the demo mean the customer gets it? What do you do with that question?
No - the demo shows product behaviour, not a customer's entitlements, integration or configuration. Route inclusion/integration questions to packaging facts (F07/F10) and a specialist.
Verified vs demo. Everything in the lab is seeded demo data demonstrating product behaviour and shape; it does not evidence any customer's outcomes, entitlements, integrations or security posture, which need product confirmation.