A productivity report shows coding 41%, communication 18%, browsing 12%, design 6%. Somebody adds them up, gets 77, and asks where the rest went.

It is a fair question and the answer is usually four different things at once, only one of which is a problem.

The four causes

Idle time inside a clocked-in session

The largest chunk, almost always. Somebody is clocked in, in a meeting, on a call, reading something printed. The machine records no keyboard or mouse activity, so no application gets credit for the time.

That time is real work and it is correctly tracked as time. It just has no application attached to it, so it cannot appear in a breakdown of applications.

This is why a productivity percentage should never be presented as “how much of the day was useful”. It is the proportion of machine-active time, and the gap between that and the clocked day is mostly meetings.

Applications that match no rule

Somewhere there is a map from application name to category — editors and terminals to coding, mail and chat to communication, and so on. Anything not in the map falls into “other”.

This is the one you can actually fix, and the fix is a mapping entry, not code.

Rounding each category separately

Four categories each rounded to a whole percent will not sum to exactly 100. You get 99 or 101 and somebody notices.

Either present one decimal place, or round the largest category last so it absorbs the remainder. Do not fabricate the difference into an existing category — the number stops matching the underlying data and someone will eventually check.

Sampling gaps

Activity is sampled, not continuously recorded. Between two samples the user may have switched applications twice. The time is attributed to whatever was sampled, and a little is always slightly misattributed.

Small, unavoidable, and not worth engineering around. Worth knowing when someone asks why a two-minute visit to a site does not appear.

“Other” is a signal, not noise

The temptation is to hide the uncategorised bucket because it looks untidy. Do the opposite — it is the most informative number in the report.

Under about ten per cent: normal. Leave it alone.

Twenty to forty per cent: your mapping is missing something the team uses every day. Usually a tool that did not exist when the map was written.

A sudden jump: somebody adopted a new editor, browser or client. The jump is the signal; the cause is one row in the breakdown.

This happens more than you would think. New editors and AI coding tools appear constantly, and a map written a year ago will quietly classify a developer’s entire day as “other” because their editor is not in it. Their productivity score collapses and they have done nothing differently.

That is the real cost of a stale mapping: not an untidy chart, but a number about a person that is wrong.

Fixing the map, and the history

Adding a mapping entry fixes tomorrow. It does not fix the months already recorded as “other”, and those months are what a person’s trend line is drawn from.

So a mapping change usually wants a backfill — reclassify existing rows where the application matches the new rule. A one-off command, straightforward, and easy to forget.

Two things worth doing when you backfill: count the affected rows before you change anything, so the scale is known, and log that the backfill happened. A productivity chart that changes shape for three months in the past, with no record of why, is the kind of thing that gets someone accused of fiddling the numbers.

Matching application names

Match on a normalised, lowercased name and prefer a contained substring over an exact match. The same application reports itself differently across platforms and versions, and an exact-match map needs a new entry every release.

Keep the map in configuration rather than scattered through code, so adding an entry is a one-line change somebody can make without a deploy.

What to tell people the number means

This matters as much as the arithmetic.

If staff believe the percentage is “how much of your day was productive”, then every meeting looks like idleness and the number becomes something to game. People learn to keep an editor focused while on a call.

Say what it actually is: the proportion of time the machine was in use, broken down by what it was in use for, with meetings and calls deliberately excluded because the machine cannot see them. Stated that way it is a useful description of the day. Stated the other way it is a score, and scores get managed.