Time and Activity: Idle and breaks
Objective. Read idle time and breaks for a team against policy and explain why idle is an activity-signal gap, not proof of time wasted.
This screen aggregates idle time and breaks - the main reasons present time is less than available time. It answers 'where are available hours going to inactivity, and does it fit break policy?' with a label that needs careful handling.
See it in the demo
What this screen answers
Idle and break time is the bridge between present time and available hours. The screen answers: across this team and period, how much time is idle or on break, and is break-taking within the agreed policy? It is where unreviewed capacity loss often hides.
The task
Scope to a team and period and read idle and break volumes against the agreed thresholds, looking for sustained patterns rather than isolated moments. The task is to size inactivity and separate expected, policy-compliant breaks from idle that genuinely warrants a question - then route the real cases to a timeline drill or a conversation.
How to read it
Idle is the absence of captured activity signal, not proof of time wasted. Thinking, a phone call, a meeting, offline reading or an uncaptured system all register as idle. Breaks within policy are legitimate availability deductions, not waste. The misread is summing idle plus breaks and calling it 'lost time' - some of it is normal, some is uncaptured work, and only part may be genuinely recoverable. The idle threshold itself is configured and shapes what you see.
Honest limits
What counts as idle depends on the configured threshold and capture sources, and what counts as an allowed break depends on the customer's policy - confirm both with product before reading the numbers. This screen quantifies inactivity signals; it does not explain cause or prove any of it is recoverable. Pair it with capacity and the timeline before treating idle as an opportunity figure.
Interpretation check
Idle time is missing activity signal, not proof of wasted time, and policy-compliant breaks are not waste. Do not sum idle and breaks into a 'lost hours' figure - much is normal or uncaptured work, and the idle threshold is configurable.
In the field
KnackGlobal: idle looks like easy capacity to reclaim, but presenting it honestly - some is uncaptured work, breaks are legitimate - is what keeps the account's trust while still surfacing the recoverable slice.
Practical task
On the demo idle/breaks view, pick one team and write a one-line read that separates policy-compliant break time from idle worth investigating, and notes the idle threshold as a value to confirm.
Self-check
A customer adds idle plus break time and calls it recoverable waste. What is wrong?
Breaks within policy are legitimate, and idle is absence of captured signal - which includes calls, meetings and offline work. Only part may be genuinely recoverable; the sum overstates it.
What two settings shape what this screen even shows?
The configured idle threshold and capture sources, and the customer's break policy. Both must be confirmed with product before reading the figures.
How should a notable idle pattern be handled?
Route it to a timeline drill or a neutral conversation to find the cause. The screen sizes inactivity signals; it does not explain them.
Verified vs demo. Screen is live in the demo at /#/idle; exact controls and figures are SME-validation-pending.