Before building a dashboard: seven questions for your team

The purpose of the first meeting

A new reporting project often starts with charts: where the sales graph should sit, how many pages to build and which filters to add. Those decisions matter, but first the team needs a shared description of the job the report should do.

The first meeting can produce a single-page brief. It should explain who needs the report, which question it answers and how the team will check the answer. These seven questions give that discussion a useful structure.

1. Who will use the report?

“Management” is too broad. A sales director might compare branches, while a branch manager needs the products behind a shortfall. Finance may look at the same period through payments and returns.

Name the first user and a specific moment in their work. For example, the sales director checks last week's performance in a Monday meeting. That situation is a better starting point for the first page than collecting every department's requests into one long list.

2. Which decision should it support?

“See the data” does not yet describe a decision. A more useful aim is to identify a branch that needs further review, or a product whose stock position needs checking.

Imagine that a measure changes. Who responds, and what happens next? If that is unclear, refine the business question before adding more visuals. Include the information needed for that first decision and keep other requests in a separate backlog.

3. What does each measure mean?

One word can hide several rules. Does “sales” mean orders, invoices or money received? Are returns deducted? Are cancelled orders included? Does the reporting period follow the order date or payment date?

Give each main measure a short definition and a worked example. Suppose an invoice is issued in September and paid in October. Which month should include it in this particular report? Both views may be useful, but they need distinct labels. Agreeing on these rules early saves repeated arguments about totals later.

4. Where does the data come from, and who understands it?

Write more than “Excel and our business software.” List the specific source, the information needed, the person who understands it and how it connects to other sources. Do product codes match between stock and sales tables?

Record known gaps: missing identifiers, inconsistent names, duplicate records or workbooks whose structure changes regularly. These are questions to investigate, not problems that a new dashboard automatically solves. Allow time to prepare the data as well as present it.

5. How recent does the information need to be?

Yesterday's results may be enough for a morning meeting. Checking stock during the day may require a different cadence. Agree on a concrete requirement: how current the data must be and how users will see when the report last updated.

Interactive Power BI filters do not by themselves mean that the underlying data changes every second. Refresh behavior depends on the connection and configuration. Start with the business need, then choose the appropriate setup. Check the current Microsoft refresh guidance during implementation; the link is at the end of this article.

6. Who should see which information?

Some people may need only their own branch, while others need a view across the business. List the user groups and the information each should be allowed to see.

Distinguish public demonstration material from internal business reports from the beginning. A public portfolio example is not permission to expose internal data. Review access requirements alongside the report design rather than adding them at the end.

7. How will you know it is ready?

Choose a reporting period and several concrete cases. Reconcile totals against the agreed source, check a return and a cancellation, then try the filters people will use most often. One correct overall total does not prove that every breakdown is correct.

Name the person responsible for checking the results and agree on acceptance criteria. A useful final exercise is to let the intended user answer the original work question without assistance. Record where they struggle: the issue may be the data, a label or the page structure.

A short brief for the first meeting

Copy these seven prompts into a working document and complete them with your team at the first meeting.

• User and work situation:
• Main question and next action:
• Three main measures and their definitions:
• Sources, owners and known limitations:
• Required refresh timing:
• User groups and access:
• Validation period, examples and reviewer:

The next step

This brief makes the scope of a first version easier to agree. If an answer is missing, name the person who will resolve it and when. An unverified assumption should remain visible as an open question.

Next, read what belongs on the first page of a sales dashboard in the related articles below. If you already have a reporting problem in mind, tell us about it. These questions make a useful starting point for that conversation.