Time and Activity - Sales Demo Script
Objective. Run an evidence-led Time and Activity demo in a live call: open on the customer's own question, show the paid-hour chain to one real exception, read the utilisation denominator honestly, state the limit out loud, and land a concrete next step.
This is the five-beat demo - question, screen, evidence, interpretation, next step - built for Time and Activity. The arc is one team's paid hour, from attendance to the exception a lead should act on today, with the utilisation denominator named explicitly and the output limit stated before the customer can misread it. Runnable in seven minutes in a live call against the demo lab.
See it in the demo
The story arc
The demo tells one story: 'of the hours you pay this team for, how many were available, how were they used, and where should a lead look today?' You are not touring screens; you are walking the paid hour from presence to action and proving that the app routes finite manager attention rather than adding another dashboard to ignore.
The five beats, each tied to a screen:
- Question - open with the customer's reconciliation pain, not a feature.
- Screen - attendance and hours: scheduled time becoming available hours.
- Evidence - the exception: the specific case that broke an agreed rule.
- Interpretation - utilisation with its denominator named, and the honest ceiling on what it claims.
- Next step - the manager review routine the customer would run, and the baseline they would capture.
Discipline over dazzle: one team, one real exception, one honest limit. That is what survives a buyer who has seen three other tools this quarter.
The screens to show, in order
Run these in sequence, one value point each - do not open screens you will not land a point on:
- Daily operations (https://time-activity.demo.timechamp.io/#/daily) - the entry point. Value point: 'this is yesterday for one team at a glance, instead of three spreadsheets stitched together.'
- Attendance and hours (https://time-activity.demo.timechamp.io/#/attendance) - Value point: 'scheduled time, minus absence and breaks, equals the available hours - and this available-hours figure is what everything downstream divides by.'
- Exception queue (https://time-activity.demo.timechamp.io/#/exceptions) - the heart of the demo. Value point: 'instead of reading every timeline, a lead is routed to the few cases that broke the rules you set - this is where their time goes.'
- Investigate / day timeline (https://time-activity.demo.timechamp.io/#/investigate or https://time-activity.demo.timechamp.io/#/timeline) - Value point: 'one click turns a flag into evidence - present time, available hours, the exception, and the context around it.'
- Utilization (https://time-activity.demo.timechamp.io/#/utilization) - Value point, stated carefully: 'this is how much of the available hours were engaged - a capacity signal, against available hours, not a measure of output.'
The five beats, scripted
Beat 1 - Question (say it before you click). 'Today, when a team lead needs to know how many of yesterday's paid hours were actually available and where to look first, how do they get that - and how long does it take?' Let them answer; that answer is your baseline.
Beat 2 - Screen. Open daily operations, then attendance and hours. Narrate the subtraction out loud: scheduled, minus absence and breaks, equals available hours.
Beat 3 - Evidence. Open the exception queue and pick one real flag - an idle spike, a missing attendance, or overtime outside policy. 'This is one case that fell outside a rule you would set. Let's see what is behind it.' Drill it on investigate or the timeline.
Beat 4 - Interpretation. Show utilisation and name the denominator explicitly: 'this percentage is productive activity over available hours, not scheduled hours, and not a measure of output - that is why it answers a different question from attendance.'
Beat 5 - Next step. 'The value is a lead working this short queue every morning to a logged decision. On a pilot team we would agree your available-hours definition and exception thresholds, then capture three baselines - reconciliation effort, exception review rate, follow-through - so you measure it on your numbers, not mine.'
The limitation to state out loud
Say this before the customer can misread anything - stating the limit is what makes the rest credible:
'Utilisation here is activity-based availability, not completed output. A team can be highly utilised and still produce little of value - that question belongs to Work Output, not this app. And every figure you see depends on coverage: a person with no signal distorts the denominator rather than reading as zero, so before we trust any number we validate coverage and agree what counts as available hours.'
If the surveillance objection is in the room, add: 'this is about the availability and use of paid hours and the exceptions worth a lead's time, not keystroke monitoring - we would agree the privacy boundary and an employee-communication plan during onboarding, and capture-policy specifics we confirm with product for your deployment.' Never promise a utilisation uplift percentage.
The discovery questions this demo answers
Pair the demo with discovery so it lands on a real pain, not a generic tour. The questions this demo is built to answer:
- 'How do your team leads reconcile attendance today, and how many hours a week does it take?' (sizes the reconciliation-effort baseline)
- 'When a manager questions an overtime or attendance pattern, what evidence do they actually have?' (sets up the exception and timeline)
- 'Which exceptions would you want a lead to review every morning?' (makes the exception queue the customer's own, and surfaces the thresholds)
- 'Who would own that morning routine, and where would the resulting action be logged?' (turns the demo into an adoptable routine and a pilot)
If you cannot get answers to these, the demo becomes a feature tour. Lead with the question, show the evidence, name the limit, and close on the routine.
Interpretation check
A good Time and Activity demo opens on the customer's reconciliation question, walks the paid-hour chain to one real exception, names the utilisation denominator (available hours) and its ceiling (activity, not output) out loud, and closes on the manager review routine and a customer-owned baseline - never on a promised uplift.
In the field
KnackGlobal (~6,000 RCM seats): the demo lands because at that scale a lead cannot read thousands of timelines, so the routed exception queue is the obviously indispensable part - and framing utilisation as capacity visibility, with output explicitly handed to Work Output, is exactly what keeps the story credible against a ProHance incumbent.
Practical task
Run the five-beat demo live against the demo lab in seven minutes: open on a discovery question, walk daily operations to attendance to one real exception, drill it, show utilisation with its denominator and ceiling named, state the output and coverage limit out loud, and close on the review routine and three baselines. Record it and note which discovery question each beat answered.
Self-check
What is the first beat of the demo and why does it come before any screen?
The business question - how leads reconcile hours today and where they look first. It comes first because it frames the screens as the answer to the customer's pain and gives you their baseline, rather than touring features.
Which screen is the heart of the demo and what is its one value point?
The exception queue. Its value point is that a lead is routed to the few cases that broke agreed rules instead of reading every timeline - routed attention, which is where the recovered manager time comes from.
When you show utilisation, what two things must you say out loud?
Its denominator (productive activity over available hours, not scheduled hours) and its ceiling (a capacity/engagement signal, not a measure of output - output is a Work Output question).
What is the explicit limitation you state, and why state it unprompted?
That utilisation is activity-based availability not completed output, and that every figure depends on coverage. Stating it unprompted is what makes the demo credible and pre-empts the customer's own misread.
How do you close the demo so it becomes a pilot, not applause?
On the manager review routine - who works the exception queue, how often, where actions are logged - plus agreeing the available-hours denominator and thresholds and capturing the three baselines (reconciliation effort, review rate, follow-through) on the customer's own numbers.
Verified vs demo. All five screens are live in the demo lab at the cited URLs and the paid-hour model is demo-shown. The specific figures are SME-validation-pending, and capture policy, data sources and entitlements for any customer are confirm-with-product - never asserted from the demo in the call.