Metric glossary
Objective. Give a shared, plain-English definition of the cross-cutting Time Champ metrics, each with its most common misread, so two people mean the same thing by the same word.
A quick-reference glossary of the terms that appear across the platform and get confused in the field. Each entry is a plain definition plus the misread to avoid. It is deliberately app-logic level: exact formulas are confirm-with-product. Use it to settle a definition dispute fast and to keep a QBR or discovery honest.
See it in the demo
What it is and when to use it
This is a shared vocabulary card for the metrics that cut across applications. Use it when a customer or colleague uses a term loosely, when a QBR number is questioned, or when onboarding yourself to a new application. It is not a formula sheet - the exact calculation of any metric is confirm-with-product and may be configurable per customer. Its value is agreement: most metric disputes are actually definition disputes, and naming the denominator and the misread resolves them faster than any dashboard.
The glossary - copy this
- Attendance % - share of expected time the person was present. Misread: treating it as productivity. Presence is not use of time.
- Utilisation % - share of available/paid hours used on tracked work. Misread: ignoring the denominator (available vs paid vs scheduled hours answer different questions); a high utilisation says nothing about output quality.
- Output / completed work - units of work actually finished. Misread: comparing two teams without aligning work type, complexity, period, tenure and quality.
- Output per paid hour / per FTE - completed (ideally complexity- and quality-adjusted) work over paid time. Misread: using raw counts as if all units were equal.
- Cost per clean unit - cost to produce one unit that meets the quality standard. Misread: quoting cost per unit while ignoring rework and quality.
- Adherence (schedule / work / output) - three separate layers: doing the planned activity; that activity producing work; that work meeting the output standard. Misread: assuming schedule-adherent means productive - someone can be adherent and active yet below the output standard.
- Forecast accuracy / bias - how close predicted demand was to actual, by an agreed method. Misread: reading an overall FTE balance as proof every skill and interval is covered.
- Recoverable value vs billed vs collected cash vs capacity value - four distinct numbers. Misread: adding or blending them; capacity value is not cash.
- Simulated vs executed vs achieved - a what-if, an action taken, and a realised result are not the same. Misread: presenting a simulated improvement as an achieved outcome.
- Coverage (data / agent / sample) - how much of the population the data actually represents. Misread: treating a sample or partial-coverage figure as a census.
How to fill and extend it
When a term comes up, state the plain definition and the denominator or scope, then name the misread before anyone falls into it - that is the move that keeps a conversation honest. For any application-specific metric not on this card, add an entry only after confirming the definition with product or the app's own grounding; do not invent a formula to fill a gap. In a dispute, write down the definition both sides are using - the disagreement almost always lives in the denominator, the exclusions, the time window or the quality adjustment, and surfacing that resolves it.
Honest caveat
These are plain-English, app-logic definitions for shared understanding, not exact formulas - the precise calculation, inclusions and exclusions of any metric are confirm-with-product and are often configurable per customer. Do not present a glossary definition as the customer's actual configured measure without checking. The four-number distinction (recoverable, billed, collected, capacity) and the simulated-vs-executed-vs-achieved distinction are the two that cause the most expensive mistakes - never blur them to make a number look bigger.
Interpretation check
Most metric disputes are definition disputes living in the denominator, exclusions, window or quality adjustment. Attendance is not productivity, utilisation is not output, simulated is not achieved, and recoverable/billed/collected/capacity are four separate numbers that must never be blended.
In the field
KnackGlobal: the headline question 'is the team productive' was kept honest by the glossary - utilisation was reported with its denominator stated, output was complexity- and quality-adjusted before any team comparison, and capacity released was never added to collected cash in the business case.
Practical task
Pick a recent conversation where a metric was disputed or used loosely. Write out the definition each side was using and identify exactly where they diverged (denominator, exclusions, window, or quality adjustment), then state the correct shared reading.
Self-check
Why do attendance % and utilisation % answer different questions?
Attendance is share of expected time present; utilisation is share of available/paid hours used on tracked work. Presence is not use of time, and neither says anything about output quality.
Name the four numbers that must stay separate in a value conversation.
Recoverable value, billed value, collected cash and capacity value. Capacity value is not cash, and overlapping findings cannot be summed.
A customer says 'the schedule adherence is 95%, so the team is productive'. Correct them.
Schedule, work and output adherence are three layers. Someone can be schedule-adherent and active yet below the output standard; 95% adherence does not establish productivity or output.
An application metric is not on the card. Do you define it from memory?
No. Confirm the definition with product or the app's grounding before adding it; do not invent a formula, and note that exact calculations are often configurable per customer.
Verified vs demo. The metrics and their misreads are demo-shown across Time and Activity, Work Output and Value Leakage; exact formulas, inclusions and exclusions are confirm-with-product and often configurable per customer.