Do you actually need a dashboard, a report, or neither?

Data dashboards are among the most frequently commissioned and least frequently used things in software. Almost every company has one that somebody built, everybody praised, and nobody has opened in two months. The reason is usually not technical: "we want a dashboard" means at least three different things, and typically only one of them gets built.

In short

• "We want a dashboard" usually means one of three things: we do not trust the numbers, preparing them takes too long, or we cannot tell what they mean.
• If the problem is trust, a dashboard does not solve it — it shows the same untrusted number faster.
• If the question is asked on a schedule, a report is cheaper and usually enough. Dashboards are for unpredictable questions.
• A dashboard with no decision behind it is decoration: the first question is what somebody will do differently after seeing it.
• If two sources disagree, settle the source of record before building any visualisation.

Three different problems in one request

First: we do not trust the numbers. This is the most common version and the hardest to admit. The numbers exist, but each department has its own variant and they disagree in the meeting. That is a data quality and source-of-record problem. A dashboard only accelerates it: the contradiction arrives sooner, in a nicer typeface.

Second: preparing them takes too long. The numbers are correct, but somebody spends hours each month assembling them by hand. That is an automation problem rather than a visualisation one. Often the right answer is a report that produces itself, not an interactive dashboard.

Third: we cannot tell what the numbers mean. The data exists and is correct, but the trend or the cause is not visible in it. Only this version is genuinely a dashboard problem, and only for it is a dashboard worth building.

The question that rules out most requests

What will somebody do differently after seeing it? Not "things will be clearer" — a specific action. If there is no answer, the dashboard will be opened for a week and then forgotten. If there is one, that action tells you which figures are needed, and there are usually far fewer of them than planned.

The question has a second benefit: it reveals who the real user is. A dashboard for a manager and a dashboard for an operations team are two different products, and merging them into one usually produces neither.

What to prepare before any project

• Write down three questions you want answered. Not metrics — questions.
• For each, note where the data needed to answer it lives today.
• Check whether two sources agree. If they do not, that is more important work than the dashboard.
• Establish how often the question is asked. Once a month means a report, not a dashboard.
• Name the person who will use it. If there is nobody, there is no project yet.

When a dashboard genuinely pays off

There are cases where it is obviously useful. When decisions are made frequently and quickly — stock, capacity, queue management. When the questions are not known in advance, so a fixed report cannot capture them. When several people use the same data and each assembles it differently. And when the cost is already visible: somebody spends days a month producing what could appear on its own.

Illustrative scenario, not a description of a client project

Imagine a company commissioning a sales dashboard. It gets built, joins shop and accounting data, and looks excellent. In the first meeting somebody notices the sales total disagrees with the accounting total — because one system counts the order date and the other the payment date. The dashboard became the venue for an argument rather than a decision tool. The real work was agreeing which date counts as the sale. This is an example of how we weigh scope, not a promise about an outcome.

If the conclusion after reading this is "a monthly report is enough for us", that is a good outcome rather than a lost project. A dashboard nobody opens costs twice: once to build and once to maintain.