Time and Activity - Concepts and Key Terms
Objective. Carry the mental model behind Time and Activity - the decomposition of the paid hour - and define its key terms plainly enough to use them precisely with a customer and never conflate presence, availability, use and output.
Time and Activity is built on one idea: take the hour a customer pays for and break it down honestly into what was present, what was available, how the available time was used, and which cases deserve a look. This module gives the core concept, a plain-language glossary of the terms, how they chain together, and the single concept people most often get wrong.
See it in the demo
The core concept - decomposing the paid hour
The app exists to answer one operational question with evidence: of the hours a customer pays for, how many were actually available to do work, how were they used, and where should a manager look?
The model is a subtraction and then a ratio. Start from scheduled time (what the roster says). Remove absence and late starts to get present time. Account for breaks and idle to arrive at available hours - the time a person was present and able to work. Then express how those available hours were spent as utilisation. Finally, instead of asking a manager to read every person's day, route the few cases that break agreed rules into an exception queue.
Everything else in the app - overtime, capacity leakage, the day timeline, comparisons - is a different cut of this same decomposition. Hold the chain and the screens stop being a list of dashboards and become one honest accounting of the paid hour.
Key terms, defined plainly
- Scheduled time - the hours the roster or schedule says a person should work. The starting point, not a measure of work.
- Attendance / present time - presence against schedule: was the person there, and for how long. Evidence of being present, not of work done.
- Available hours - present time left after breaks and late starts; the hours a person was able to work. This is the denominator utilisation divides by.
- Utilisation - the share of available hours spent on activity classified as productive. A capacity-engagement signal, not output.
- Idle - time with no captured activity signal. Includes genuine inactivity but also calls, meetings and offline work, so it is not proof of waste.
- Break - a policy-defined, legitimate deduction from available time; within policy it is not waste.
- Overtime / after-hours - time beyond the scheduled window, judged against schedule, policy and timezone. A cost, compliance and burnout signal, not proof of extra output.
- Exception - a case that fell outside an agreed rule or threshold; a prompt to investigate, not a verdict.
- Productivity rule / classification - the configurable logic that labels time productive, idle or flagged. The labels are only as sound as these rules.
- Coverage and freshness - how complete and current the signals are; the gate that decides whether any figure is trustworthy.
How the concepts chain together
Read left to right and each term feeds the next:
Scheduled time -> (minus absence and late starts) -> present time / attendance -> (minus breaks and idle) -> available hours -> (productive share of) -> utilisation.
Running alongside this spine: coverage and freshness sit underneath every step, because a gap in signal distorts the whole chain rather than reading as zero. Productivity rules decide how idle and productive are labelled at the available-hours step. Overtime is what sits beyond scheduled time at the top of the chain. Capacity leakage aggregates where available hours drain away across a team. And the exception queue is the routing layer that surfaces the specific points in the chain that broke an agreed rule.
The practical payoff: when a customer points at any single number, you can walk back up the chain to its denominator and its coverage and say exactly what it does and does not claim.
The concept people most often get wrong
Utilisation is not productivity in the business sense. It is the single most common and most damaging confusion in the app. Utilisation measures whether available hours were engaged in activity classified as productive - it says nothing about whether valuable work was completed, at what quality, or at what cost.
A team can be highly utilised and produce little of value; a team can be modestly utilised and produce a great deal. The moment a customer reads utilisation as 'how productive the team is', every decision built on it is suspect, and the honest value of the app - visibility of available time and actionable exceptions - gets replaced by a claim the app cannot support.
The discipline: whenever utilisation comes up, name its denominator (available hours) and name its ceiling (activity, not output), and route the output question to Work Output. Hold that line and the rest of the model stays honest.
Why the labels are configurable, not absolute
A recurring theme across the glossary is that the key labels - productive, idle, exception, overtime, available - are configured, not objective facts. The same minute can be productive for one role and not another; the same hour can be overtime or normal depending on the schedule and timezone; the same gap can be idle or uncaptured work depending on the capture sources.
This is a feature, not a weakness: it is what lets the model fit a specific customer's policy. But it carries an obligation. Read every classified number as 'under the current, agreed rules', agree those rules with the customer before interpreting, and treat demo defaults as a starting point only. Concepts in this app are precise only once the customer's definitions are pinned down; spoken loosely, they invite exactly the disputes the model is meant to end.
Interpretation check
The app decomposes the paid hour: scheduled time, minus absence, equals present time; minus breaks and idle equals available hours; the productive share of available hours is utilisation. Coverage underlies every step, the labels are configurable, and utilisation is engagement of available hours - never output.
In the field
KnackGlobal (~6,000 RCM seats): leaders there care about output per FTE and cost per claim, so the concept discipline matters - utilisation is presented as a capacity signal in the paid-hour chain, never as the productivity proof, which keeps the displacement case grounded in Work Output rather than an activity percentage.
Practical task
Draw the paid-hour decomposition for one demo person-day on the timeline view: label scheduled time, absence, present time, breaks, idle, available hours and the utilisation it produces. Then write one sentence stating which two labels you would have to confirm with the customer before trusting the numbers.
Self-check
Put the core chain in order from scheduled time to utilisation.
Scheduled time, minus absence and late starts, gives present time (attendance); minus breaks and idle gives available hours; the productive share of available hours is utilisation. Coverage and freshness sit under every step.
Define 'available hours' and say why it matters most.
Present time left after breaks and late starts - the hours a person was able to work. It matters because it is the denominator utilisation divides by, so if it is not agreed, every utilisation figure is disputable.
Why is 'idle' not the same as 'wasted time'?
Idle is the absence of a captured activity signal, which includes calls, meetings and offline work, not just genuine inactivity. It is a signal gap to investigate, not proven waste, and the threshold is configurable.
What is the single concept people most often get wrong, and how do you hold the line?
That utilisation equals productivity. Hold the line by always naming its denominator (available hours) and its ceiling (activity, not output), and routing the output question to Work Output.
Why does the app call its labels configurable rather than factual?
Because the same minute, hour or gap can be productive, overtime or idle depending on role, schedule, timezone and capture sources. Configurability lets the model fit the customer's policy, but it means every classified number must be read 'under the agreed rules'.
Verified vs demo. The decomposition model, the term relationships and the configurability of the labels are demo-shown and consistent across the app's workflows. The exact classification rules, thresholds, denominator and capture sources for any customer are configurable and confirm-with-product.