There is a predictable arc to reporting projects. Somebody asks for visibility, a team builds a dashboard with twenty charts, it is demonstrated to enthusiasm, it is opened daily for two weeks, weekly for a month, and then not at all. Six months later it is still being maintained, still costing money in warehouse queries, and nobody can quite say when they last looked at it. This happens to competent teams with good tools and it is not a technical failure.
It happens because the request was for visibility, and visibility is not a use. A number is only useful if somebody will do something differently depending on its value, and most dashboards are built without anybody having identified what that something is. The twenty charts are each individually defensible and collectively unusable, because a screen that answers twenty questions answers none of them with enough prominence to prompt an action.
Start from the decision, not the data
The question that makes reporting projects succeed is not "what data do we have" but "what decision is being made badly right now, and by whom". It is a harder question and it produces a much smaller dashboard. In our experience the answer is almost always a decision that somebody is currently making from memory, on a recurring schedule — the weekly call about which accounts to chase, the monthly decision about what to reorder — and that person already knows the decision is poorly informed.
Having named the decision, the next question is what would change the answer. Usually it is one or two numbers, not twenty, and frequently the numbers are not the ones the data team expected. The person deciding what to reorder does not primarily want sales figures; they want to know which items will run out before the next delivery, which is a different and more specific quantity that requires knowing the delivery schedule.
That gap — between the number the data makes easy and the number the decision needs — is where most of the value in this work sits, and it is only found by sitting with the person who decides. An hour of that is worth more than a week of dashboard building, and it is the step that gets skipped because it looks like requirements gathering rather than engineering.
An alert beats a chart
If a number only matters when it crosses a threshold, a dashboard is the wrong delivery mechanism, because it requires somebody to remember to look. The right mechanism is a message that arrives when the threshold is crossed, and nothing the rest of the time. This is a substantially cheaper thing to build and it is used indefinitely, whereas the chart is used until the novelty wears off.
We now ask, for every chart requested, whether it would be better as a notification, and the answer is yes more often than not. The resulting deliverable looks much less impressive in a demonstration — a short list of messages rather than a wall of visualisations — and it is what still gets used a year later. That trade is worth making explicitly with whoever commissioned the work, because a demonstration is sometimes part of what they are buying.
Alerts have a failure mode too
The equivalent failure for notifications is volume. An alert that fires daily is a report, an alert that fires hourly is noise, and a channel full of noise trains everybody to ignore the one that matters. So every alert needs a stated expected frequency at design time — "this should fire about twice a month" — and a review when it fires more than that, because the right response to a noisy alert is usually to fix the threshold rather than to tolerate it.
Agree what the words mean
The most expensive problem in reporting is not technical, it is that two people use the same word for different quantities and neither knows. "Active customer" might mean any of three things.
- Logged in this month.
- Holding a subscription.
- Having placed an order in ninety days.
All three are reasonable, they produce numbers that differ by a factor of three, and a meeting where two people quote different figures for the same metric destroys confidence in the whole system.
And it destroys it permanently, which is the part worth emphasising. Once a leadership team has seen two contradictory numbers for the same thing, they stop treating any number from that system as authoritative, and no amount of subsequent correctness repairs that. The dashboard then becomes something people check against their own spreadsheet, which is strictly worse than not having it.
The remedy is unglamorous: a definitions document, one line per metric, stating the exact rule and who owns it, agreed before anything is built and visible from the dashboard itself. Every metric on screen should link to its definition. This takes a couple of days, is the least interesting part of the project, and is the thing that determines whether the output is trusted.
| What is asked for | What is usually needed | Why |
|---|---|---|
| Visibility into the business | One named recurring decision | Visibility is not a use |
| Twenty charts on one screen | Two numbers and a threshold | Twenty answers prompt no action |
| A real-time dashboard | A daily figure, usually | Match the decision’s cadence |
| A chart to check daily | An alert when it matters | Nobody remembers to look |
| A metric by its common name | A written definition and an owner | Two figures end all trust |
Real time is almost never needed
Real-time reporting is requested far more often than it is useful, and it is one of the largest cost multipliers available. Streaming infrastructure, incremental aggregation and the operational burden of a pipeline that must never fall behind are all substantially more expensive than a job that runs once a night. The test is simple: how often is the underlying decision made? If it is made in a weekly meeting, a figure refreshed nightly is six days fresher than it needs to be.
There are genuine real-time cases and they share a shape: an operational decision taken by somebody looking at a screen while something is happening. A dispatcher assigning a vehicle, a support lead watching a queue during an incident, a trading desk. In those cases the latency is the product. In every other case, nightly is right and the difference in cost between them is frequently an order of magnitude.
Put the number where the work is
A separate reporting tool requires a context switch, and a context switch is enough friction to prevent use. The number that changes a decision should appear in the place the decision is made: in the order screen, next to the customer record, in the weekly email that already gets read. Teams consistently underestimate how much this matters, because from a data team’s perspective the number exists either way.
The most-used thing we have built in this category was not a dashboard at all: it was a single figure added to an existing screen that the operations team already had open all day, showing how many of the items in front of them would miss their delivery window. It took two days, it replaced a report that had taken six weeks, and it was still in use two years later because using it required no decision to use it.
This is also the cheapest thing to try first. Before commissioning a reporting project, it is worth asking whether the two or three numbers that matter could be put onto screens that already exist, because if they can then the project is a week rather than a quarter and the adoption problem disappears entirely.
One owner for every number shown
A dashboard with no owner per metric decays within a quarter. Somebody changes how a field is populated, the number moves, and because nobody is responsible for that particular figure it is explained away in a meeting and then quietly distrusted. After two of those the whole screen is treated as indicative, which is a polite way of saying nobody acts on it, and at that point it costs money to maintain and returns nothing.
Ownership here means a named person who would notice if the number were wrong and who is expected to explain a movement. It does not mean the person who built the chart. In practice the owner is whoever acts on the metric, which is also the only person with enough context to tell a real change from a data artefact — and if no such person exists, that is the finding, and the metric should not be on the screen.
The practical form is a line of text next to each number saying who owns it and when it was last verified. It looks bureaucratic and it does two useful things: it makes an unowned metric visibly unowned, and it gives anybody who distrusts a figure somebody to ask instead of a reason to ignore the screen. Dashboards that carry this tend to shrink over their first year, which is the correct direction.
A number without a comparison is noise
Four hundred and twelve is not information. Four hundred and twelve against a normal week of three hundred is information, and against a target of six hundred it is a different piece of information again. A figure shown alone forces every reader to supply their own baseline from memory, which means two people look at the same screen and reach opposite conclusions, both confidently.
The comparison worth showing is whichever one the decision actually uses. For a capacity question that is the limit; for a trend question it is the same period last year, because last week carries the wrong seasonality; for a service question it is the commitment you made to somebody. Picking the wrong comparison is worse than picking none, since it quietly proposes a conclusion the data does not support.
- A target, when somebody committed to one.
- The same period last year, for anything seasonal.
- The limit, for anything that can run out.
- The normal range, so a spike reads as a spike.
A normal range is the most underused of those and often the most useful, because most questions people ask a dashboard are really "is this unusual?". A band showing the middle of the historical distribution answers that at a glance and removes the most common misreading, which is treating ordinary variation as a trend and starting a project about it.
The number has to be trusted first
A dashboard inherits every data quality problem upstream of it and displays them as confident figures. If ten percent of records have a blank region, a regional breakdown is wrong by ten percent and looks exactly as authoritative as a correct one. The display layer cannot fix this and should not hide it: a count of the records it could not classify, shown next to the chart, is the difference between a wrong answer and a qualified one.
Show the freshness, not just the value
The other half of trust is knowing when the number was computed. A stale dashboard is more dangerous than a broken one, because a broken one is obviously broken while a stale one shows plausible figures from before the thing you are investigating happened. A timestamp on every panel, and a visible warning when the pipeline has not run, costs almost nothing and prevents the worst category of mistake.
It is worth testing this deliberately once: stop the pipeline and look at the dashboard. If it looks identical to a healthy one, that is a defect and it is the defect most likely to cause a bad decision, because it fails in the direction of confidence. Everything else on the screen can be slightly wrong and survive; silently frozen data cannot.
Who sees which rows, and why
A dashboard is a reporting surface over data with access rules, and those rules have to survive the aggregation. A branch manager who cannot open another branch’s records should not be able to infer them from a chart, and a total across four branches where they can see three is a subtraction away from being a leak. This is not theoretical; it is the most common way reporting layers undo an access model that the application itself gets right.
The clean approach is to apply the same filter the application applies, at query time, from the viewer’s identity rather than from a parameter in the URL. A dashboard that changes what it shows based on a dropdown the user picked is one step from showing anything to anybody, and that step is usually taken by somebody sharing a link in good faith.
Exports deserve a separate thought, because an export leaves the system entirely and takes its access rules with it only as a memory. If a screen can produce a spreadsheet, that spreadsheet is now wherever somebody emailed it, with no filter and no expiry. That may be perfectly acceptable, and it should be a decision rather than a side effect of a button that seemed convenient.
Measure whether it is opened
The final recommendation is uncomfortable and it is the one that changes behaviour: instrument the dashboard itself, and review the usage after three months. Who opened it, how often, and which charts did they interact with. This is trivial to add and almost nobody does it, which is odd given the entire premise of the project was that measurement improves decisions.
The review should have teeth: charts nobody has interacted with in three months get deleted. This sounds harsh and it is the only mechanism we have found that keeps a reporting surface useful over years, because the default trajectory is purely additive — every request adds a chart, nothing ever removes one, and after two years the useful numbers are buried among forty that are not.
Deleting also has a cost that is worth naming: somebody asked for each of those charts, and removing one can read as a judgement on that request. So the rule has to be set at the start, applied mechanically to everything including the charts the sponsor asked for, and the figures published alongside. A rule that is announced in advance and applied evenly causes far less friction than a decision made case by case.
- Name the recurring decision and the person who makes it.
- Write "when X crosses Y, [person] does Z" before building.
- Ask whether an alert would serve better than a chart.
- Agree one written definition per metric, with an owner.
- Match the refresh rate to the decision, not to ambition.
- Put the figure on a screen people already have open.
- Instrument usage and delete what nobody opens.
The underlying point is that a dashboard is a user interface for a decision, and user interfaces are judged on whether the task gets completed rather than on what they contain. A reporting project that produced two numbers, an alert and a deleted chart list is a better outcome than one that produced a comprehensive analytical surface, and it is a harder thing to present at the end of a quarter — which is most of why it is rarer.
