Time and Activity - Common Misinterpretations
Objective. Hold the full catalogue of the ways Time and Activity metrics get misread, so a CSM or Sales rep can correct a wrong reading in one line and never let a customer build a decision on a distorted figure.
Almost every dispute in this app is a misread, not a bug. The same figure answers a narrower question than people assume, or depends on a denominator, a rule or a coverage level that was never agreed. This is the quick-reference: each misread stated as the wrong reading, why it is wrong, and the correct reading - grouped by theme and drawn from the app's own interpretation guardrails.
See it in the demo
Presence, availability and use are three different things
Misread: 'attendance was 98%, so 98% of hours were available for work.' Why wrong: attendance is presence against schedule; available hours come after breaks and late starts and are usually lower. Correct: attendance is the gate into available hours, not the hours themselves - and available hours is the denominator utilisation later divides by.
Misread: 'utilisation was 78%, so the team was productive.' Why wrong: utilisation is productive activity over available hours, not useful output. A team can be 78% utilised and produce little of value. Correct: utilisation is a capacity-engagement signal; the output question belongs to Work Output.
Misread: treating a single utilisation percentage as the whole story. Why wrong: a high percentage on very low available hours is a different situation from the same percentage on a full day. Correct: always pair the percentage with its base size and trend.
The denominator decides the number
Misread: comparing two utilisation figures without checking their base. Why wrong: the denominator can be available hours or scheduled hours, and the same activity gives very different percentages depending on which is configured. Correct: confirm both figures use the same, agreed denominator before comparing them.
Misread: assuming the demo's denominator is the customer's. Why wrong: the available-hours definition is customer-specific and must be agreed. Correct: identify and agree the denominator on the attendance and data-sources views before reading anything downstream.
Misread: reading two users' different figures for 'the team' as a data error. Why wrong: access scope changes the population each person sees - a manager restricted to their org has a different denominator than an admin. Correct: reconcile the scope before reconciling the numbers; both can be honestly right.
Idle, breaks and overtime are signals, not verdicts
Misread: summing idle plus breaks and calling it 'lost time' or 'recoverable waste.' Why wrong: idle is the absence of a captured activity signal - thinking, a call, a meeting, offline reading and uncaptured systems all read as idle - and policy-compliant breaks are legitimate. Correct: only part may be genuinely recoverable; size it honestly and confirm the idle threshold, which is configurable.
Misread: 'this agent does the most overtime, so they contribute the most.' Why wrong: overtime is hours beyond schedule, not output; it may mean the same work took longer or load is uneven. Correct: sustained overtime is more likely an understaffing or scheduling signal, and contribution is a Work Output question.
Misread: treating all after-hours activity as a breach. Why wrong: in flexible or multi-timezone teams, activity outside a standard window can be legitimate. Correct: the flag depends on the configured schedule, policy and timezone - confirm those first.
Classifications and exceptions are rules, not facts
Misread: 'the app says 20% non-productive, so a fifth of the team's time was wasted.' Why wrong: 'non-productive' is a classification under the configured rules, not proof no useful work was done; the same minute can be productive for one role and not another. Correct: read it as 'under the current, agreed rule set' and check the rules before reacting.
Misread: treating the exception queue as a list of people who did wrong. Why wrong: an exception is a case that fell outside an agreed threshold - a prompt to investigate, not a verdict - and coverage gaps cause false positives. Correct: work it as a check-list against rules the customer set, deciding cause and fault only after the drill.
Misread: treating a single flag as a finding. Why wrong: a flag is a reason to look; a missing data source can masquerade as a behaviour. Correct: check coverage and denominator before acting.
Capacity is not cash, and coverage is not completeness
Misread: multiplying leaked or idle hours by an hourly rate and presenting it as guaranteed savings. Why wrong: this converts a capacity opportunity straight into cash. Correct: recovered capacity, billed value and collected cash must stay separate - freed hours are only money if redeployed to work that is billed and collected, which is a Value Leakage, owner-driven exercise.
Misread: 'a missing source will just read as zero.' Why wrong: it skews the denominator instead; a person with no signal distorts the available-hours base rather than showing as fully idle. Correct: incomplete coverage over- or under-states figures - read every metric as 'for the covered population, as of this freshness.'
Misread: quoting a confident figure without stating its coverage. Why wrong: the same number means different things at 70% and 98% coverage. Correct: name the coverage and freshness alongside the figure, every time.
Interpretation check
Most Time and Activity disputes are misreads: presence is not availability, utilisation is not output, idle is not proven waste, overtime is not contribution, a classification is not a fact, an exception is not a verdict, capacity is not cash, and a figure without its coverage and denominator is not a claim you can defend.
In the field
KnackGlobal (~6,000 RCM seats): in a ProHance-displacement fight, a single overstated savings claim built on 'idle hours times a rate' would hand the incumbent an easy credibility attack. Keeping capacity separate from cash, and stating coverage with every figure, is what makes the capacity-visibility story survive scrutiny.
Practical task
Build a one-page misread cheat-sheet for a specific customer: pick the five misreads most likely in their context, and for each write the wrong reading you expect to hear, the one-line correction, and the screen you would open to show it. Use it to pre-empt disputes in the next review.
Self-check
Correct in one line: 'utilisation was 78%, so the team was productive.'
78% is productive activity over available hours, not useful output - a team can be 78% utilised and produce little of value; output is a Work Output question. Also confirm the denominator is available, not scheduled, hours.
A customer sums idle and break time and calls it recoverable waste. What is the correct reading?
Breaks within policy are legitimate and idle is absence of captured signal (calls, meetings, offline work all read as idle). Only part may be recoverable, and the idle threshold is configurable; the sum overstates the opportunity.
Two managers quote different utilisation figures for 'the same team.' Data bug or expected?
Expected. Access scope changes the population and denominator each person sees. Reconcile the scope before the numbers; both can be honestly correct.
A customer multiplies leaked hours by a rate and presents it as savings. Why is that wrong?
It converts a capacity opportunity straight into cash. Recovered capacity, billed value and collected cash must stay separate; freed hours become money only if redeployed to billed, collected work.
A red idle flag appears for one agent. Why is treating it as a finding a misread?
A flag is a prompt to investigate, not a conclusion. A missing or partial data source can read as idle, so check coverage and the denominator before acting; cause is decided on the drill, not by the flag.
Verified vs demo. The metric model and every guardrail above are demo-shown and drawn from the app's workflow interpretation checks. The exact denominator, thresholds, classifications and coverage for any customer are configurable and must be confirmed with product against that customer's policy.