- Start from the decisions each person makes and how often, then choose the few measures that drive those decisions.
- Write a definition sheet for every measure, with the formula, the source, the owner and how often it updates.
- Data is only as fresh as its slowest source: some sources refresh every few hours or less often, and that limit cannot be designed away.
- Test access as a real viewer: in some tools, row-level rules do not apply to everyone who can edit the report.
- Use an off-the-shelf BI tool for internal reporting; build custom when the dashboard lives inside your product or needs actions next to the numbers.
How do you plan a dashboard that people actually use?
Plan it from the decisions people make, not from the data you happen to have. Write down who will use it, which decisions they make, how often they make them and which numbers would change those decisions. Then build the smallest dashboard that answers those questions, with every measure clearly defined and every number traceable to its source.
Dashboards that start from "show us everything" end up with dozens of charts and no clear use. A sales lead checking the pipeline every Monday, an operations manager watching today's backlog and an owner reviewing cash each month need different screens, different measures and different refresh rates.
Which decisions should the dashboard support?
Run a short session with each group of users and ask three questions: what do you decide each day, week or month; what do you look at now to decide it; and what would you do differently if a number moved. The answers turn into a simple table of role, decision, frequency and measure.
- Owner or finance: cash position, revenue against target, overdue invoices.
- Sales: new leads, pipeline by stage, deals won and lost, response time.
- Operations: open orders or jobs, backlog age, stock below reorder level.
- Support: open tickets, time to first reply, repeat issues.
If a chart does not connect to a decision on that table, leave it out of the first version.
How do you define each measure so everyone trusts it?
Most dashboard arguments are really definition arguments. Is an "active customer" someone who bought this month or anyone with an open contract? Does "revenue" include tax, refunds and shipping? Write a definition sheet with one row per measure:
| Field | What to write |
|---|---|
| Name | One name used everywhere, in the dashboard and in meetings |
| Formula | The exact calculation, including what is excluded |
| Source | The system and table or report it comes from |
| Owner | The person who answers "is this number right?" |
| Refresh | How often it updates and when it was last updated |
| Target | What good looks like, if there is a target |
The same sheet doubles as the brief for whoever builds the tool. Our guide to writing a software requirements brief shows how to turn it into a quote-ready document.
Where does the data come from, and is it clean enough?
List every system involved: CRM, accounting, store, booking tool, ERP and the spreadsheets people keep on the side. For each one, note how you can get data out (a direct connector, an API or a scheduled export) and which field links it to the others, such as a customer ID or an order number.
Fix data problems at the source where you can. Duplicate customers in the CRM or free-text product names in the store will show up as wrong totals however good the dashboard is. If your business runs on several disconnected systems, it is worth reading how a custom ERP compares with an ERP suite before you build reports on top of them.
How fresh does the data need to be?
Real-time data is rarely needed and often not possible. Ask how quickly someone would act on a change, then check what each source allows:
- Google Analytics notes that data processing can take 24 to 48 hours, and figures in reports may change during that time.
- Google's Data Studio, formerly Looker Studio, says Google marketing and measurement sources such as Google Ads and Google Analytics refresh every 12 hours, and that rate cannot be changed.
- In Power BI, imported data follows a schedule: up to 8 scheduled refreshes a day on Pro, and up to 48 on Premium per user or Premium and Fabric capacity.
Show the last refresh time on every page. A daily operations screen that is twelve hours behind can do more harm than no screen at all.
Who should see which numbers?
Decide early whether people see everything or only their own region, team, clients or accounts. Row-level rules handle this, but test them carefully. In Power BI, for example, row-level security only restricts users with Viewer permissions; it does not apply to workspace Admins, Members or Contributors. The safe habit is to test every role by signing in as a real user with that role.
If customers will see their own figures, the dashboard becomes part of a customer-facing product, with logins, permissions and support. Our article on client portal features covers what that involves, and our guide to two-factor login and SSO covers how those users should sign in.
Should you use a BI tool or build a custom dashboard?
For internal reporting, an off-the-shelf BI tool such as Power BI, Data Studio or Metabase is usually the right start. You get connectors, charts, sharing and scheduled emails without writing an application.
A custom dashboard makes sense when the numbers live inside your own product for customers, when people need to act next to the numbers (approve, assign, reorder or reply), when permissions follow complex business rules, or when per-user licence costs grow faster than the value. Many businesses run both: a BI tool for management and a few custom software screens inside the operational software for the teams who act every day.
How do you keep a dashboard useful after launch?
Treat the first version as a draft. After a month, check which pages are opened, by whom and how often, and ask each group which number they acted on. Remove charts nobody uses, merge pages that answer the same question and add the one or two measures people keep asking for in meetings.
Review the definition sheet whenever a process changes, such as a new sales stage or a new product line, because the dashboard will quietly drift out of date otherwise. Our analytics and reporting work follows the same routine: a dashboard that stays small and correct is the one people keep opening.
Frequently asked questions
Can we use our spreadsheets as the data source?
Yes, for a first version. Google Sheets connects directly to most dashboard tools. The risk is that anyone can rename a column or paste over a formula and break the report, so lock the source tabs and keep one owner per sheet. When the same sheet feeds several reports, move that data into a proper database.
Do we need a data warehouse?
Not at first. If you have two or three sources and moderate volumes, a BI tool can connect to them directly. A warehouse such as BigQuery, Redshift or a reporting copy of your database starts to pay off when you combine many sources, keep history the source systems do not keep, or reports become slow.
How do we stop the dashboard from showing wrong numbers?
Give each measure an owner, compare key totals with the accounting system every month, and add simple checks that warn when a source stops updating or a total jumps unexpectedly. Show the last refresh time on every page so nobody acts on stale data without knowing it.
How long does a business dashboard take to build?
The charts are usually the quick part. Most of the time goes into agreeing definitions, connecting sources and cleaning data. With clean sources and agreed measures, a first useful version is often a matter of weeks; messy data or many systems take longer. Start with one team and one decision and grow from there.
Should the dashboard send alerts or reports by email?
Yes, for the few numbers that need action. An alert when stock falls below a level or when leads go unanswered gets used far more than a page people must remember to open. Keep scheduled summaries short and link back to the dashboard for detail.
Last updated