Time and Activity: Applications
Objective. Read application usage by productive/non-productive classification and explain why a non-productive label is not proof of no useful work.
This screen shows which applications a team's time went to, grouped by a productive/non-productive classification. It answers 'what tools absorbed the hours?' - and carries the single most sensitive misread in the suite.
See it in the demo
What this screen answers
A manager wants to know where active time actually went at the application level: which tools dominate, and how that time splits across the productive/non-productive classification. It gives texture to a utilisation figure - the 'doing what' behind 'how much'.
The task
Scope to a team and period and read the application mix and its classification split. The task is to spot patterns worth a conversation - a heavy share in an unexpected tool, a classification that looks wrong for this team's work - and to treat the classification as a customer-configurable assumption to validate, not a fixed truth.
How to read it
A non-productive application label is not proof an employee performed no useful work. Classification is a configured rule, and a tool marked non-productive for one team may be essential for another's job - and legitimate work (a browser-based client system, research, communication) can land in the 'non-productive' bucket. The misread is reading the label as a judgement on the person. Read it as 'is our classification right for this work?' first.
Honest limits
The whole screen rests on the classification configuration, which is customer-specific and must be validated with product and the customer before any read. It shows application activity, not the value or outcome of the work done in those applications. Treat it as input to a classification-review and coaching conversation, never as standalone evidence of wasted time.
Interpretation check
A 'non-productive' application label reflects a configurable classification rule, not proof the person did no useful work. Legitimate work can land in that bucket - validate the classification for the team before reading the label as a judgement.
In the field
Employee Monitoring shares this exact guardrail: in a monitoring-wary account, leading with 'validate the classification' rather than 'act on non-productive time' is what keeps the conversation about capacity, not surveillance.
Practical task
On the demo applications view, find one app whose classification looks questionable for the team and write a one-line note proposing it for classification review before any performance read.
Self-check
A manager sees 30% non-productive app time and wants to act on it. What comes first?
Validate the classification. A tool marked non-productive may be essential for this team's work, or legitimate work may land there. The label is a configured rule, not proof of wasted time.
Why is this the most sensitive screen to interpret?
It is easiest to read as a personal judgement. It shows application activity and a configurable classification, not the value or outcome of the work in those apps.
What is the honest first question when a classification looks off?
'Is our classification correct for this team's work?' - a configuration review, not a performance conclusion about the person.
Verified vs demo. Screen is live in the demo at /#/apps; exact controls and figures are SME-validation-pending.