Guide · Multi-location dashboards

Multi-site dashboards leadership can trust.

A multi-location dashboard fails quietly: one site's data stops updating, an average hides the site in trouble, a number nobody defined gets argued about in the meeting. Five rules prevent most of it.

The examples labelled observed come from the daily boards at our flagship client, a five-center behavioral health network. Every number in the sample visuals is invented.

Anatomy of a trustworthy viewInvented numbers
01Freshness

Show how old every number is.

Put the time each source was read on the view itself. When a source fails, the view should say so rather than show last week's number as if it were today's.

When a source failsProposed operating model
  1. Source unavailableA scheduled read fails or arrives empty.
  2. Marked staleThe view shows when that site was last read.
  3. Last good keptNobody works from a half-built view.
  4. Owner toldA named person hears about it.
  5. Next run checkedVerified before it is trusted again.
Fig. 2 Observed at the network: the daily boards rebuild each morning, and the manual export still works on any day the API does not.
02Ownership

Give every number a definition and an owner.

Most dashboard arguments are about definitions, not data. Write each one down, name who owns it, and say what the number is not.

A definitions tableIllustrative
NumberDefinitionSourceOwner
Completed vs planWork completed this period against the period's planScheduling systemOperations lead
Break-evenThe volume each site needs to cover its costsObserved: shown only where finance confirmed the assumptionsFinance modelFinance lead
Estimated valueBilled-rate value of delivered work, not collected revenueObserved: the board says so on its faceRates × completed workFinance lead
Data ageTime since each source was last readThe scheduled readNamed at handoff
Fig. 3 When a definition changes, the view should say what changed and when.
03Side by side

Compare sites. Do not only average them.

A network average can look healthy while one site is in trouble. Show each site against its own target, with the average as one more row, not the headline.

The average says fine. One site is not.Invented numbers
Break-even (100%)
Fig. 4 The same layout as the daily census view we built, recreated with invented numbers.
04Exceptions

Route exceptions to a person, and keep detail where it belongs.

A dashboard shows that something needs attention. The detail goes to the person who acts on it, not onto the leadership view.

Two layersObserved
Fig. 5 At the network, the patient-level center view never reaches a leadership board, and leadership boards carry aggregates only. In healthcare, what each view may hold is your privacy lead's decision. This is not legal advice.
05Checklist

Before you publish a dashboard.

  • It answers one named question
  • Every number has a written definition and an owner
  • The time each source was read is on the view
  • Stale data is marked, not hidden
  • Each site is shown against its own target
  • The average is a row, not the headline
  • Exceptions link to a named person
  • Leadership views carry aggregates only

Mistakes that erode trust

  • Showing estimated value as revenue. Say what the number is not.
  • Mixing fresh and stale data silently. One old source poisons the whole view.
  • Too many charts. A view that answers everything answers nothing.
  • Targets nobody confirmed. Show a comparison only where its owner agreed the assumptions.

Related: How to automate a weekly report · Managing multiple locations · The four views we built

06Questions

What owners ask about dashboards.

What should be on a multi-location dashboard?

Only what answers the question the view exists for, with every site side by side, each number defined, and the time each source was read. A short link to the exceptions someone needs to act on is worth more than another chart.

How often should it refresh?

As often as the decision it supports. A daily staffing or census decision needs a morning refresh; a monthly review does not. Whatever the schedule, show when each source was last read.

Do we need Power BI or another tool?

Not necessarily. The rules here apply in any tool, including a spreadsheet. What matters is how the numbers arrive, how they are defined and how stale data is shown.

Can patient or customer detail appear on it?

Not on a leadership view. Leadership boards should carry aggregates; record-level detail stays with the team that acts on it, under the agreements your privacy lead approves. This is not legal advice.

Who maintains the definitions?

A named owner for each number, agreed before launch. When a definition changes, the dashboard should say what changed and when.

Does your dashboard tell you how old its numbers are?

Bring a screenshot of the one leadership uses to a free 20-minute call. We will tell you which of the five rules it breaks, if any.