Metrics worth tracking — and the ones that just look smart

Someone builds a dashboard. Four tiles: revenue to date, jobs closed, new customers, average turnaround. It looks tidy, and for a fortnight the management team checks it daily.

By month three nobody opens it. One number has not moved in six weeks: whoever filled it in every Monday picked up something more urgent, and nobody noticed — itself the answer to whether it was needed.

The dashboard was not badly built. It showed what was easy to count instead of what anyone reacted to.

A good metric has its response decided in advance#

The test fits in one question, put to a named person about a specific number: what will you do on Monday if this drops by a fifth?

If the answer is "we'd have to look into that", it is not a metric. It is a chart.

A good answer is dull and specific: "I'll go through the jobs that have waited longest and assign them by hand."

So every number needs three things: a name, a response and a threshold — who looks, what they do, at what value they start. A number that cannot fill all three is decoration: costly to maintain and quiet, because nobody reports when it stops working.

Outcome and process are two different jobs#

Outcome metrics describe results: revenue, margin, customers lost. Two properties make them poor material for a daily dashboard. They arrive late — by the time revenue dips, the cause has been running a long while. And nobody moves them directly: you cannot "improve revenue" on a Monday, but you can assign the backlog, call the customer who waited longest, or chase a week-old quote.

Process metrics measure those steps: how many jobs wait to be assigned and since when, how many came back for rework after sign-off.

The division is simple: outcome metrics for judgement once a quarter, process metrics for reacting this week. A daily dashboard is mostly the second kind.

"How much we did" does not tell you whether it is going well#

The most common metric in a small company is a counter: a hundred and forty jobs closed, thirty quotes sent, two hundred calls taken. They are the easiest thing to compute, so they reach the dashboard first.

But a counter carries no judgement. Is a hundred and forty a lot? It depends how many came in, how many stayed open, and how long the oldest waited. An activity counter also rises when things go badly: more service call-outs might mean sales are up, or that installation started making mistakes — the only distinction that matters, and the one a counter cannot make.

Two figures turn a counter into a metric: backlog and age — how many items are open, and how long the oldest waited. The first gives scale, the second says whether the queue is moving.

What manual collection really costs#

A dashboard is often assembled once a week by retyping data from a few places into one spreadsheet. The visible cost is hours; the less visible is lag — Monday's figure comes from Friday's data and you act on it on Wednesday.

The third cost is the serious one. A hand-collected metric dies quietly: no error, just the last value held, and nothing saying the data is six weeks old.

Hence the rule: a metric that is not a by-product of work you already do rarely survives a quarter.

To measure the time from report to assignment, both must be events with a timestamp, not something agreed on the phone. That is work on how you record the state of a job — the same work required before letting a model near your data. The rule from running projects without a project tool holds here too: a status should point at the next step, not supply a colour.

A metric with no owner is a chart#

The owner of a metric is not whoever assembles the report. It is the person whose work looks different depending on what the number says.

The exercise takes fifteen minutes. Beside every number, write a sentence in the form "when this passes X, [name] does Y". Any number where you cannot finish the sentence comes off — remove the tile, not the data.

Outcome metrics have owners too, usually the business owner. Fine, as long as the response stays specific: "if service margin drops below the threshold, we review the price list."

Repeat the pass every quarter. It usually takes out a good share of the tiles; a workable size is one number per person who reacts to it, plus a few shared outcome figures. Twenty tiles read like wallpaper.

When an AI pilot stalls, a number with no owner loses once and loudly, at the review meeting where it can be told either way. A dashboard has no review meeting, so nothing loses out loud — people just stop looking. Which is why a standing metric leans on the response, not the date: a date closes a decision, a response keeps the number alive. If you measure nothing today, start where you would start a first process worth improving: repeatable, measurable in hours, with a named owner.

A model can only summarise what is in the data#

The reflex when a dashboard serves nobody: put AI on top, so numbers arrive as a sentence, not a table.

Something real does go away. A plain question — what slipped this week and who is it sitting with — replaces opening three views, and the retyping goes too.

Nothing underneath goes away. A model is only as good as the data it has: if the assignment date was never recorded, that time cannot be computed at all. And a model rarely says "that is not in the data" — it gives you a figure from whatever it found, in the same confident tone as everything else.

And a summary has one weakness a table does not: empty cells show a gap, a smooth sentence shows nothing.

Summary#

Dashboards do not die of poor construction. They die because they show numbers nobody reacts to, and because some depend on manual work the first busy week ends for good.

The criterion fits in a sentence: every number should let you write down a name, a response and a threshold. Build the daily view from process metrics, keep outcome metrics for the quarter, pair counters with backlog and age. Add the model summary last — it reproduces the data quality it finds.

The wider context is in the guide on AI adoption for companies with no IT department.