Operations KPI Dashboard: What to Track and How to Lay It Out

Use one test for every candidate metric: if this number turned red, would someone know what to do about it, and would that person be in the room? If the answer is no, the metric is trivia. It might belong in a report someone can pull on request, but it doesn't belong on the page you look at every week.

Two kinds of metrics tend to sneak in and cause trouble. The first is the vanity total, such as lifetime orders shipped, which only ever goes up and never prompts a decision. The second is the metric with no owner, such as "customer satisfaction" shown on the operations page when support and delivery each think the other one is responsible for it. Give every number a single named owner, or cut it.

Also decide early whether the dashboard is for steering or for auditing. A steering dashboard is short, current and opinionated. An audit view is long and historical. Trying to make one page do both is how you end up with forty tiles.

Four blocks cover most operations teams, whether you ship products, deliver projects or run field crews. Put them in the same order every time so people learn where to look:

• Flow: how much work is entering and leaving. Examples are jobs started and completed per week, and the size and age of the backlog. A backlog that grows for three weeks in a row is an early warning that no other block will show you.
• Speed: how long work takes. Cycle time from order to delivery, and on-time delivery rate against the date you promised the customer, not against your internal target.
• Quality: how often work has to be redone. Rework or redo rate, returns, and customer-reported defects per hundred jobs.
• Cost and capacity: what the work costs and whether people can absorb more. Cost per unit of work, overtime hours, and utilization of your scarcest resource (a machine, a crew, a specialist).

Keep two or three metrics per block. If a block has more than four, you're probably tracking activity instead of outcomes.

A number on a dashboard is only useful if two people would calculate it the same way. Before a metric goes on the page, fill in one row of a spec sheet with these fields, in this order:

1. Name, in plain words ("On-time delivery," not "OTD-2").
2. Definition and formula, including what counts and what doesn't (does a customer-requested delay count as late?).
3. Data source, meaning the exact system or sheet the number is pulled from.
4. Owner, one person.
5. Refresh cadence: daily, weekly or monthly.
6. Green, yellow and red thresholds, chosen before you see the data.
7. Action when red: the first thing the owner does, written down.

Item seven is the one people skip, and it's the one that turns a dashboard into a management tool. If you want a fuller walkthrough of the definition step, metric definitions covers how to keep a shared dictionary so the same word means the same thing everywhere.

Say you run a company that installs commercial flooring with four crews. Your flow block shows jobs completed per week and the count of signed jobs not yet scheduled. Your speed block shows days from signature to install and the share of installs finished on the promised date. Quality shows callbacks per hundred jobs. Cost and capacity shows overtime hours per crew and material waste as a share of material ordered.

Now set thresholds. For example, you might decide that on-time installs below 85% is red, because that's the point where your customers' general contractors start calling. You decide that unscheduled signed jobs older than ten days is red, because the sales team then knows to stop promising dates. Each red has an owner and a first step: the scheduler reshuffles crews, or the sales lead pauses new bookings.

That's eight metrics, one screen, and every one of them tied to a decision.

Pick the tool based on where the data already lives and who will maintain the page, not on which one has the nicest charts.

A spreadsheet is the right start if you have fewer than a dozen metrics and one person can update them weekly. It's cheap, everyone understands it, and it forces you to decide what matters before you automate anything. A BI tool makes sense once your numbers come from several databases and someone needs them refreshed without copy and paste. If you're weighing options there, Metabase vs Tableau vs Looker Studio compares the usual candidates.

If most of your work already lives in a work management platform, building the dashboard there avoids an integration project: the tasks, statuses and owners are already in one place. Keep the dashboard to the four blocks even then, and review it in a fixed meeting. The executive dashboard cadence guide covers which metrics deserve a daily glance and which only need a monthly look.