Short answer: an owner of several locations needs one screen, opened every morning, that shows seven numbers per location and in total, with yesterday against the same day last week, and a way to click any number to see the detail. The screen is simple. The work is in the permissions behind it and the data feeding it.
The spreadsheet-per-site problem
Most multi-location businesses grow one site at a time, and each site gets its own spreadsheet, its own group chat and its own version of the truth. The owner finds out about a bad week at month end, from a report someone assembled by hand. Managers at each site cannot see each other. Comparison is impossible, so nobody learns from the site that is doing well.
The seven numbers
The exact names depend on the business; the shape does not. For each location and for the group:
- Yesterday's revenue (or bookings, or billable hours), against the same weekday last week.
- Volume: covers served, appointments completed, shifts filled.
- A quality signal: new reviews and average rating, complaints, cancellations.
- Staffing: shifts uncovered today and this week, hours against plan.
- Pipeline: bookings on the books for the next seven days.
- Money owed or at risk: failed payments, overdue invoices, expiring subscriptions.
- One exception list: the things that need a decision today, across all sites.
Seven, not thirty. If a number does not change a decision this week, it belongs in a report, not on the morning screen.
Three rules for the screen
Compare like with like. Yesterday against the same weekday last week, this month to date against last month to date. Raw totals without a comparison just make people feel busy.
Every number is a link. Click revenue, see the transactions. Click uncovered shifts, see which ones and who is eligible. The dashboard is a door, not a poster.
Red means act. Thresholds are set per location (a quiet site has different normal numbers), and a breach shows in colour with the action attached: "2 shifts uncovered tomorrow: send cover requests".
Permissions: who sees what
This is where a multi-location dashboard differs from a single-site one, and where it must be designed from the first database table:
- Owner: everything, every site, with comparison views.
- Area or regional manager: a defined set of sites.
- Site manager: their site only, including staff and costs for it.
- Staff: their own schedule and tasks, nothing financial.
Each record carries its location; each user carries the locations they may see; every query is filtered by that pairing on the server. In Postgres this is row-level security, so even a bug in the app cannot show one site's numbers to another's manager. Clinical Stack applies this per practice and per location, and Spinfluence per restaurant under a multi-location owner.
Where the numbers come from
A dashboard is only as good as its sources. For each of the seven numbers, write down where it comes from (the booking system, the payment provider, the review platform, the rota) and how often it updates. Most businesses find two or three numbers are already in systems that have an export or an API, two or three are in spreadsheets that need to move into the system, and one is in nobody's head yet. That inventory is the first milestone of the build.
Two real examples
Spinfluence gives restaurant owners one view across every location: key metrics, review analytics with keyword breakdowns, reply activity, customers and subscriptions, with per-restaurant metrics one click down and per-location logins for managers (/work/spinfluence). Clinical Stack's admin home shows what needs attention today across locations (coverage gaps, pending requests, alerts) and its reporting drills from the group to each person's shifts (/work/clinical-stack). Different industries, the same seven-number shape.
Build or buy
If one platform already runs all your locations (a single point-of-sale or practice system), use its reporting first. Build your own dashboard when the seven numbers live in three or more systems, when per-location permissions matter, or when the exception list needs actions wired in (send cover requests, chase an invoice). Post 07A has the cost test for deciding whether a build pays for itself.
Running several sites from several spreadsheets?
Tell me how many locations, which systems hold the numbers today, and who should see what. I will reply with the seven numbers I would start with and the permissions model. Form at /contact, or see /solutions/multi-location-dashboards and /services/management-systems-and-dashboards.