Guide

How to brief a business dashboard

Start with the decisions it supports, not the charts. Then agree what every number means and where it comes from.

By The Solva Group. Published 1 October 2026, updated 3 October 2026.

The Solva Group recommends briefing a business dashboard around decisions before charts. For each number, write down its definition, source system, audience and required freshness. Check the available access before commissioning the build. Then agree how to compare the dashboard with the source and how the screen should show missing or late information.

1. Start with the decisions

List the decisions the dashboard should help with, and who makes them. "Do we need to chase more enquiries this week?" is a decision. "Sales data" is not. If a number would not change what anyone does, it does not belong on the screen.

2. Agree what each number means

Agree the definition of each number before building the dashboard. Does a sale count when the order is signed or when it is delivered? Is the month the calendar month? Write each definition down once, in plain words, and get the people who use the number to agree.

3. Find where each number lives

For every number, name the system that holds it. Some will live in one system. The useful ones often need two or three brought together, which is where most of the work is.

4. Check the access

A dashboard can only show what its source systems allow it to read. Find out what each system lets you export or connect to before promising anyone a number. We confirm each connection before we quote.

5. Decide who sees it, and where

A manager at a desk, a team glancing at a wall screen and an owner on a phone need different views of the same numbers. Say which of those you need.

A worksheet for each number

Write one line like this for every number you want on the screen. If you cannot fill a line in, the number is not ready to build.

  • The number: what it is called on the screen.
  • The decision: what someone does differently when it moves.
  • The definition: exactly what is counted, and over what period.
  • The source: the system that holds it.
  • Who sees it: and on a desk, a phone or a wall screen.
  • Required freshness: how current the number needs to be.
  • Missing or late data: what the screen should show and who needs to know.

Before you trust it

  • Pick a day you know well and check every number against the source system.
  • Make sure the screen shows when each source last updated.
  • Ask what the dashboard does when a source is missing or late. It should say so, not show an old number as if it were new.

A live implementation: dealership reporting

At a Melbourne new-car dealership, the numbers lived in a dealer management system, a sales log, the phone system, the trade-in valuation software and the website lead system. Seeing how the day was going meant logging into each one. Rooftop brings them into one view for sales, service, parts and finance, on the office screens and the showroom TVs.

Quick answers

How many numbers should a dashboard show?

As few as it takes to support the decisions you listed. If everything is on the screen, nothing stands out.

Should we buy a reporting tool or build a dashboard?

Start with the reports your systems already produce. A custom dashboard earns its place when the numbers live in more than one system or someone builds the report by hand every week.

Why do our numbers never match?

Often because two people are using two definitions, or reading two systems at different times. Check the definitions and the refresh times first, then look into whatever still differs.

Where to go next.

Prefer a written workflow plan?

Rather have the plan written for you?

A Workflow Blueprint is a paid, fixed-fee plan for one business workflow, with a written scope and a build quote.

What a Workflow Blueprint includes
See a worked example
Worked example

One number, written down.

The number
"Follow-ups due"
What it counts
Open follow-up tasks whose due date is today or earlier. It excludes completed tasks.
Its purpose
To help a team member choose whom to contact next.
Before building it
Name the source system, agree the timezone and decide what happens if the source cannot be read.

Planning example, not a customer result.

Tell us what you need built.

A rough description is enough.