Key Performance Indicators Dashboard: Examples Worth Copying

Searching for key performance indicators dashboard examples returns hundreds of screenshots. Almost all of them are beautiful, almost none of them are copyable, and the reason is the same in every case: the picture shows the layout without showing the decision the layout was built to serve. Copy the layout and what arrives is a screen of numbers nobody looks at by the third week.

The dashboards that survive have a narrower definition. Each one answers a question that somebody has to answer again on a schedule, and the question is specific enough that the answer changes what happens next. That is the part worth copying. The tiles follow from it, and the chart types barely matter.

What follows is a set of examples described by their question rather than their appearance, with the tiles each one needs and the failure each one tends to produce.

A dashboard and a report are not the same artefact

The distinction decides everything downstream. A report explains a period that has finished. It is read once, it can be long, and it can carry caveats in prose. A dashboard supports a decision that is about to be made again. It is read repeatedly, it must fit on one screen, and anything requiring a caveat does not belong on it.

Most failed KPI dashboards are reports that were laid out as dashboards. The symptom is easy to spot: twenty tiles, no target lines, and no obvious action attached to any number moving. Nobody can say what they would do differently if a given tile turned red, which means nobody has a reason to open it.

Three tests filter almost everything. Who opens this, and when? What decision does it feed? What would a bad number cause somebody to do this week? A tile that fails all three is background information, and background information belongs in a monthly document rather than on a screen competing for attention.

Four examples, described by their question

Delivery status for a project team

The question is whether the current commitment will be met, asked at the start of each week. The tiles are: items completed this week against the weekly rate needed to finish on time, items in progress per person, the count of items blocked with how long each has been blocked, and the earliest date by which the remaining scope can land at the current rate.

The trap is percentage complete. It moves smoothly, it feels like progress, and it is usually an estimate of an estimate. Counts of finished items and the age of blocked items are harder to fool, because both come from something that actually happened.

Weekly commercial view for a small team

The question is whether the next two months of revenue are covered. Tiles: new qualified opportunities this week, total value in the pipeline split by stage, deals that have not moved in fourteen days, and revenue closed against the month's target.

The trap is the pipeline total. It grows whether or not anything is progressing, since nothing forces stale opportunities out. The tile that carries the information is the one counting deals that have not moved, which is why it belongs next to the total rather than three screens away.

Support and incoming load

The question is whether the team is keeping up. Tiles: conversations opened against conversations closed this week, the age of the oldest unanswered item, median first response time, and the count of items reopened after being closed.

The trap is average response time, which hides the shape of the distribution. Two hundred requests answered in five minutes and eight abandoned for a week produce a respectable average and eight unhappy people. The oldest unanswered item is the tile that finds those eight.

Capacity and commitments

The question is whether the next month has been oversold. Tiles: committed work per person against available days, days off and holidays already booked, work committed with no owner assigned, and the count of items whose due date has already moved twice.

The trap is utilisation expressed as a percentage. Ninety percent utilisation looks like efficiency and usually means there is no slack left anywhere, so the first sick day becomes a missed deadline.

The same four dashboards, side by side

Dashboard	Question it answers	Read by	Cadence	Tile most often missing
Delivery status	Will the current commitment land on time	The team and whoever depends on it	Weekly, at the start	Age of blocked items
Commercial view	Is the next two months of revenue covered	Whoever owns revenue	Weekly	Deals that have not moved
Support load	Is the team keeping up with incoming work	Support and the manager	Daily	Oldest unanswered item
Capacity	Has next month been oversold	Whoever assigns work	Fortnightly, before commitments	Work committed with no owner

The column that repays the most attention is the last one. In each case the missing tile is the one that makes a comfortable picture uncomfortable, which is precisely why it gets left off.

What the ones that survive have in common

Every number carries its comparison. A tile reading 47 is unreadable. A tile reading 47 against a target of 60, with last week at 52, can be acted on without anybody explaining it. The comparison is what makes a dashboard glanceable, and it is the most common omission in the templates that circulate.

Denominators are visible. A conversion rate of thirty percent means something different on ten opportunities than on four hundred. Dashboards that show rates without the counts behind them generate confident decisions from noise, particularly in small teams where weekly volumes are low enough that a single event moves a percentage several points.

The count of tiles stays in single figures. Six to nine is the working range for a screen that gets read. Beyond that, attention distributes evenly across everything, which is the same as attending to nothing. Extra metrics belong on a second dashboard with its own question and its own audience, not squeezed onto the first.

Time windows match the decision. A weekly decision needs weekly buckets, and a rolling thirty day window on a weekly dashboard smooths away exactly the change that the meeting exists to notice. Cumulative charts since January have the same problem: they always slope upward and therefore never say anything about this week.

And each dashboard has one owner. Not a committee, one person who is responsible for the numbers being current and for retiring tiles that stopped mattering. Dashboards without an owner do not get deleted, they get ignored, which is worse because they keep looking authoritative.

Where the numbers come from decides whether it lasts

The most reliable predictor of a dashboard still being used in six months is not its design. It is whether the numbers arrive without somebody assembling them.

Dashboards built on manual entry have a predictable life. The first month is accurate, the second is a week behind, and by the third the person maintaining it has concluded, correctly, that nobody noticed the gap. Any tile that needs a human to copy a figure across from another system is on a timer.

This is the argument for taking KPIs from wherever the work already happens. Delivery tiles should come from the board the team moves cards on, because then they are a by product of working rather than an extra task. Commercial tiles should come from wherever deals are recorded. When the board, the discussion and the schedule are spread across three applications, the counts have to be reassembled by hand every week, and that is the actual reason the dashboard dies. Teams in that position often find the consolidation worth more than the reporting layer, and a look at how the boards fit together is a better first step than a new dashboard tool.

One caution about automation: automatic does not mean correct. A tile reading from a board where half the team forgets to move cards produces confident, wrong numbers, and confident wrong numbers are harder to catch than an obviously stale spreadsheet. Before trusting an automated tile, check that the underlying field is one people actually maintain.

Metrics that look useful and are not

Four appear on most templates and earn their place on very few dashboards.

Percentage complete, as above, is an opinion formatted as data. Counts of finished items are dull and honest.

Hours logged measures reporting compliance at least as much as it measures effort. It is worth tracking where hours are billed, and misleading almost everywhere else.

Velocity compared between teams is not a comparison of anything, since estimation scales are local. Compared against the same team's own recent history it is informative, and the moment it becomes a target it stops being informative, because estimates inflate to meet it.

Task counts without size are the quietest of the four. Forty small items and four large ones look identical on a tile, and a team optimising against that tile will start choosing small items. Any count that becomes a target changes which work people pick up.

Building the first version without turning it into a project

A KPI dashboard does not need a tool selection exercise. The expensive part is deciding what belongs on it, and that decision is cheaper to make badly on paper and then correct.

Begin with the meeting rather than the metrics. Find the recurring conversation where somebody has to decide something, the Monday planning slot or the fortnightly commitments review, and write down the three questions that conversation keeps having to answer from memory. Those questions are the dashboard. If no such meeting exists, the dashboard has no reader, and building it first will not create one.

For each question, write the tile as a sentence before drawing it: items finished last week against the rate needed, oldest blocked item and its age, commitments for next month against days available. Sentences expose tiles that cannot be measured, which is much easier to notice in prose than in a chart.

Then run it manually for two or three weeks. Filling in six numbers by hand takes ten minutes, and those weeks reveal which tiles get discussed and which get skipped. Automating a tile before knowing whether anyone reacts to it is the most common way to spend a fortnight building something nobody opens.

Only after that should the tiles be wired to their sources. By then the list will have shrunk, usually by about half, and the remaining tiles will be the ones somebody asks about when they are missing. A dashboard that was missed while it was broken is one worth automating.

What to change first

Take the dashboard currently open in a tab, and for each tile write down what somebody would do this week if the number were bad. Delete every tile with no answer, then add the comparison, the target or last week's figure, to whatever is left. If most of what remains cannot be produced without copying numbers between tools, the reporting is not the problem, and putting the boards and the conversation in one place is the change that makes the numbers maintainable. Pinateca is free for up to five people and ten boards.

Q1. How many KPIs should one dashboard show?

Six to nine tiles is the practical range for a screen that continues to be read. The limit is attention rather than space: beyond roughly nine numbers, nothing stands out and the screen becomes wallpaper. If more metrics genuinely matter, split them into a second dashboard with a different question and a different audience rather than extending the first.

Q2. What is the difference between a KPI dashboard and a report?

A dashboard supports a decision that recurs, so it fits one screen, carries comparisons, and is read repeatedly. A report explains a period that has ended, can run to several pages, and is read once. The most common failure is a report laid out in tiles, which shows many numbers while attaching no action to any of them.

Q3. Should a KPI dashboard be built in a spreadsheet or in a tool?

A spreadsheet is the fastest way to find out which tiles are worth keeping, and the slowest way to maintain them once that is settled. If the numbers can be pulled from the systems where the work already happens, they survive; if a person has to copy figures across each week, accuracy usually lapses within two or three months.

Q4. Which KPIs suit a team of five to fifteen people?

Ones that can be counted from things that actually occurred: items finished this week, age of the oldest blocked item, commitments made against days available, and whatever single number represents money coming in. Rates and percentages are unstable at small volumes, because one event can move a percentage by several points and prompt a reaction to noise.

Q5. How often should a dashboard be reviewed and pruned?

Look at the tiles themselves once a quarter, separately from reading the numbers. Ask of each one whether a decision was actually taken because of it during the quarter, and remove the ones where nothing was. Dashboards rarely fail by being wrong; they fail by accumulating tiles that were relevant when they were added and nobody removes.