Data & decisions / A practical guide
When do your spreadsheets need a dashboard?
Build a dashboard when a recurring decision needs a dependable shared view. Start by agreeing what the numbers mean and who will act on them.
Start with the decision your team keeps making
Spreadsheets are often a sensible tool for exploration, planning, and small shared lists. Needing a dashboard does not mean they have failed. The signal is usually a recurring question that takes too long to answer: which jobs need attention, where work is waiting, or whether this week differs meaningfully from last week.
Write the decision in a sentence before choosing software. For example: every Monday, the operations lead assigns help to the teams with overdue work. Now the dashboard has an audience, a cadence, and an action. A beautiful page of totals without those three things can become another report nobody opens.
Look for a reporting problem, not just a large file
A dashboard becomes useful when the same analysis is recreated frequently, several people need a consistent view, or information must be combined from multiple sources. File size alone is not a useful decision rule. A small workbook can cause confusion if everyone calculates the same metric differently.
Sometimes the right first change is a cleaner input form, agreed column names, or a single source of truth. A dashboard cannot repair missing records by displaying them more elegantly.
| What is happening | A useful next step |
|---|---|
| One person explores a new question occasionally | Keep a flexible spreadsheet and document the calculation. |
| A weekly report is rebuilt from the same exports | Standardise the data preparation and create a reusable view. |
| Teams disagree about what counts as completed | Agree the metric definition before building charts. |
| People need to update or approve records | Consider a workflow tool; a read-only dashboard may not solve it. |
Give each metric a small written contract
For every headline number, record its name, calculation, source, reporting period, exclusions, owner, and intended action. Be specific about time zones and which date a record belongs to. Created date, completion date, and payment date answer different questions even when they refer to the same job.
Consider an illustrative on-time completion metric: completed jobs with a completion timestamp on or before their agreed deadline, divided by all jobs completed in the selected week. Decide how cancelled jobs, reopened work, and missing deadlines are treated. Also show jobs still overdue; a completion-only ratio can look healthy while unfinished work accumulates.
- Definition: state exactly what the number includes and excludes.
- Grain: specify whether a row represents a job, customer, item, or event.
- Comparison: use equivalent periods and explain incomplete weeks.
- Accountability: name who can resolve a disputed definition or source record.
Make freshness and gaps visible
A page can load now while showing yesterday's information. Google's Data Studio documentation explains that reports may reuse cached results within a data source's freshness interval; refreshing the report display does not necessarily fetch new underlying data. The same practical question applies to any reporting setup: how old is the information used for this decision?
Track the source's last successful update as well as the dashboard's refresh. State the expected cadence, show a warning when it is missed, and tell users who owns the connection. Distinguish a genuine zero from missing data. If one location did not submit its records, the overall total should not quietly imply complete coverage.
Reconcile a small dashboard before expanding it
Start with three to five measures that support the chosen decision. Add a useful comparison and a way to inspect the records behind a surprising result. Check totals against an agreed source for several periods. Test empty dates, duplicate records, late arrivals, changed statuses, and a user who should see only part of the data.
During a short pilot, observe the actual meeting or workflow where the view is used. Ask what decision changed, what information was missing, and which chart caused confusion. Keep a list of follow-up questions instead of adding every requested visual immediately. A focused dashboard should reduce the explanation needed in the meeting.
Budget for the work behind the screen
The ongoing effort is usually in the definitions, source connections, permissions, and changes to the business. Assign a business owner for meaning and a technical owner for reliability. Document who updates the dashboard when a source column changes or a team adopts a new process.
Review whether people still use the view and act on it. Retire redundant charts. Add new measures when they answer a real decision, with the same definition and validation discipline. The goal is a shared view people can explain and trust, even when the person who built it is not in the room.