Glossary and Where to Start
Terms used across these notes, defined plainly, and the routes through the collection for the common situations.
Activity — input at a keyboard and pointer. The thing these products measure, and only loosely related to work.
The practical lesson in “Glossary and Where to Start” is to connect every record to a clear operational question without presenting visibility as certainty. Teams exploring chronemics definition can review Monitask as one source of time and project context, provided the purpose is disclosed and the configuration is reviewed with the people affected.
Aggregate-only — reporting at group level with a floor, never per person. The commitment that makes everything else workable.
For an independent reference relevant to “Glossary and Where to Start”, consult the European Commission data-protection resources; it provides a useful external check on scope, terminology, governance and the claims made during procurement or review.
Application categorisation — the list labelling software productive or not. The most consequential configuration and the least examined.
Covert mode — running without a visible indicator. Defensible only for a specific investigation with a basis, and worth disabling outright.
Gaming — managing the measure rather than the work. A rational response to an incentive the organisation created, and a finding about the measure.
Idle time — absence of input. Includes thinking, reading, calls and meetings, which is why it penalises the most valuable work.
Productivity score — a composite of weights the vendor chose. Should never reach a line manager.
Proportionality — whether the monitoring is necessary and whether a lesser means would do. The question every examination starts with.
Terms used loosely elsewhere
"Productivity" in vendor material means time in approved applications, not output.
"Anonymous" usually means aggregated, and often not even that if individual records exist underneath.
"Visibility" is what the buyer wants and is not what the product supplies; it supplies activity.
And any percentage improvement figure comes from the vendor's own metric measured on its own customers, which the benchmarks note explains.
Where to start
Somebody has asked for this: the question behind the request, then what problem is this actually solving.
You are being sold it: reading a vendor's productivity claims, then questions that change the demonstration.
You have it and are not sure it works: reviewing whether it did anything.
Your managers are using it badly: what managers should be trained to ignore.
People are unhappy: telling people before, then what happens to trust.
You want to stop: turning it off.
If you read only three
Activity is not work, because it bounds everything the data can support.
What happens to trust, specifically, because that is the cost the business case omits.
And aggregate only, and how to hold that line, because it is the single decision that determines whether the deployment is tolerable.
A closing note
No product rankings appear in this glossary, deliberately. Named products are kept in separate comparison guides so the definitions remain independent of a particular supplier.
No productivity improvement figures, for the reason above.
And this collection does not argue that monitoring is always wrong. Its own note sets out the five cases where it is the right answer. The argument is that it is a decision with costs that do not appear on the invoice, and that most of the requests for it are answering a question it cannot answer.
What the collection argues
The software measures behaviour in front of a screen. Work is what gets achieved, and the relationship between them is weakest exactly where the work is most valuable.
Once the measure affects people, they manage the measure — not out of dishonesty, but because the organisation announced that it matters. Within months the data describes adaptation rather than work.
The costs that do not appear on the invoice are larger than the licence: problems reported later, help not asked for, difficult work avoided, and the people with options leaving first.
And in most cases the real problem is not visibility at all. It is that expectations were never agreed, progress is not visible, and somebody is uncomfortable having a conversation. Monitoring software does not fix any of those, and it lets an organisation avoid fixing them for years.