Most companies that have tried business intelligence have at least one dashboard nobody looks at. It was launched with some excitement, it has twenty charts and four filters, and three months later the sales manager is back to asking someone for "the usual Excel" every Monday morning.
The tool is rarely the problem. Power BI, Looker Studio and Metabase can all draw a good chart. The dashboard fails earlier, in the weeks before anyone opens the tool, when nobody agreed on what it was for.
Imagine a building materials distributor with three sales teams, an ERP for invoices, a CRM for quotes and an online shop on a separate platform. The general manager asks for "a dashboard that shows how we are doing." That sentence can be built in a hundred ways, and ninety of them end up unused. Here are the five questions we would ask before building any of them.
1. Who opens it, and how often?
A dashboard is a screen for a specific person on a specific day. The general manager who looks once a week before the Monday meeting needs something very different from a regional sales lead who checks every morning which dealers have not ordered this month.
Write down the two or three roles who will use it, and for each one, when they will open it: daily, weekly, at month end. If you cannot name a person and a moment, the chart probably does not belong on the first version.
This also settles a practical question early. Each role should see what concerns them, not everything. A regional lead does not need the company-wide margin; the finance team does not need every rep's visit list. Role-based views are easier to design from the start than to bolt on later.
2. Which decision does each number support?
For every number proposed, ask: if this goes up or down, what will someone do differently? If the answer is "nothing, but it is nice to know," it is a candidate for a monthly report, not for the screen people open every day.
In the distributor example, "total sales this month" is interesting but rarely changes a decision on its own. "Dealers whose orders dropped compared to the same period last year" leads straight to an action: someone calls them. The second number earns its place; the first may belong in a corner as context.
A useful exercise is to limit the first version to the five or six numbers that pass this test. You can always add more. Removing charts from a dashboard people have grown used to is much harder.
3. How exactly is each number calculated?
This is the question that sinks most projects, and it looks the most boring. Ask three departments what "monthly sales" means and you may get three answers: invoiced amount, including or excluding VAT; orders placed, including or excluding cancellations; or cash collected.
If the dashboard shows one of these and the finance report shows another, the first meeting turns into an argument about whose number is right, and the dashboard loses that argument. People trust the spreadsheet they have always used.
So, before building, write a short definition for every number: what it counts, from which system, with which filters, and on which date (order date, invoice date, delivery date). Get management to agree to it once. Keep those definitions in one place, ideally in the reporting data model itself, so that every chart uses the same calculation instead of each report rebuilding it slightly differently.
4. Where does the data live, and how clean is it?
List every source the dashboard needs: the ERP, the CRM, the e-commerce platform, perhaps a spreadsheet that the purchasing team maintains by hand. Then check one thing in each: do they identify customers and products the same way?
It is common for the ERP to have a customer code, the CRM to use the company name, and the online shop to use an email address. Until someone builds a matching table, the dashboard cannot answer even a simple question like "how much did this dealer buy across all channels?"
Two practical rules help here:
- Do not point reports at the live ERP. Heavy queries during working hours slow down the people entering orders. A separate reporting database, loaded on a schedule or with only the changed records, keeps both sides happy.
- Budget time for cleaning. Matching codes, removing duplicates and fixing old records usually takes longer than drawing the charts. It is also the part that makes the numbers believable.
5. How fresh does it need to be, and how will people hear about it?
"Real time" sounds attractive and is rarely needed. A weekly management review is perfectly served by data refreshed overnight. A sales lead following daily orders may want a refresh every hour. Stock levels for a busy online shop may need more. Pick the slowest refresh that still supports the decision; it is cheaper, simpler and easier to keep reliable.
Then think about how the dashboard reaches people who do not open it. Many of the most useful "dashboards" are not screens at all:
- A short report that arrives by email every Monday at 8:00 with the five numbers that matter.
- An alert when a number crosses a threshold you set, for example a dealer with no order in 30 days.
- A link inside that email that opens the full dashboard for anyone who wants to dig deeper.
When the report comes to the reader, the screen behind it becomes the place to answer the follow-up question, which is exactly what a dashboard is good at.
What to build first
Once the five questions are answered, the first version usually turns out smaller than expected: two or three screens, one per role, with a handful of agreed numbers, a nightly refresh and a Monday email. That is a good sign. A small dashboard that people trust grows naturally, because they start asking for the next number themselves.
Choosing the tool is the last step, not the first. If the team already lives in Microsoft tools and wants to edit reports itself, Power BI is a natural fit; teams on Google tools often prefer Looker Studio; Metabase is an open-source option you can run on your own server. If the dashboard is meant for customers or dealers, per-user licences can add up, and a custom panel inside your own application may make more sense.
In short
A dashboard that gets opened answers five questions before it is built: who uses it and when, which decision each number supports, how each number is calculated, where the data comes from and how clean it is, and how fresh it must be and how it reaches people. Most of the work is agreement and data cleaning; the charts are the easy part.
Planning a project like this?
Plan it in 10 steps