Multi-location dashboards: five costly mistakes

A multi-location operations dashboard usually starts as a good idea and ends as a shared spreadsheet nobody opens after month three. It is a familiar pattern in retail chains, clinic groups, restaurant franchises and B2B distributors running anywhere from eight to eighty sites: the reporting takes longer than the decisions it supports. Most of the waste comes from five repeatable mistakes, and each one has a fix that costs far less than living with it.

Build one dashboard with a location filter, not twelve dashboards

One dashboard on a shared data model, filtered by location, beats a separate copy per branch every time. When each site gets its own file, or its own tab with hard-coded rows, every formula change has to be repeated a dozen times, and it never is. Within a quarter the outlets are measuring different things on different layouts, and the cluster head cannot compare Pune to Indore without opening both files and doing the maths by hand.

The fix is structural, not cosmetic. Keep one table per fact — sales, stock, attendance, service tickets — put a location ID on every row, and let the dashboard filter by it. Permissions then decide who sees what, so a branch manager sees only their site and the regional head sees their cluster. Adding branch thirteen becomes a data entry task rather than a development project.

Pull branch data automatically, not by Excel and WhatsApp

If branch numbers arrive as attachments, you have a monthly report with extra steps, not a dashboard. In our experience most mid-market chains still collect daily sales, stock and attendance from site managers over WhatsApp, then re-key it into a master sheet. That runs 20-40 minutes per branch per week, adds two to five days of lag, and introduces errors nobody can trace back to a source.

Connect the systems you already pay for — POS, Tally or Zoho Books, biometric attendance, Shopify, your CRM — through scheduled exports or APIs. A nightly sync at 2am is enough for most operational decisions; reserve real-time feeds for order routing, where a delay has a direct cost. For the two or three numbers that genuinely live on paper, such as wastage or cash variance, a small internal tool that writes into the same table is usually cheaper than a year of manual re-keying.

Report location P&L, not just a revenue league table

Ranking branches by revenue hides the ones quietly losing money. Revenue is easy to pull from the POS, so it dominates the dashboard, while rent, staff hours, discount depth and shrinkage — the costs that actually differ between sites — stay in a spreadsheet with the accountant. Two outlets can both do ₹18 lakh a month and contribute very differently to the business.

A working location scorecard usually carries these:

• Revenue and gross margin against target, not just month-on-month movement
• Rent and occupancy as a percentage of revenue
• Staff cost per shift, and revenue per staff hour
• Discounts and returns as a percentage of sales
• Stock cover in days, plus wastage or shrinkage where it matters

You do not need all five for every business. You need the two or three that swing hardest between sites, because that gap is the decision. We have walked through this kind of scoring build in our case studies.

Write down one definition per metric

A one-page metric dictionary prevents most arguments in a review meeting. The same word means different things at different branches: "active customer" is 90 days at one site and 30 at another, "same-day dispatch" cuts off at 4pm in one warehouse and 6pm in the next. When the numbers disagree, the meeting becomes a debate about data instead of a decision about the business.

Keep the dictionary short and specific. For each metric, record the name, the formula, the source field, the person who owns it, and how often it refreshes. Store it next to the dashboard rather than in someone's inbox. It is also the artefact auditors and investors ask for, and having it ready saves a week during due diligence.

Design every tile for a decision, with an owner and a threshold

A dashboard nobody acts on is wall decoration. The usual failure is breadth: forty tiles covering everything, opened once a month, exported to PDF for a review. The version that works is narrower — six to eight numbers, each with a target, a trend and a named owner — plus an alert when something crosses a line.

Alerts do most of the work. If stock cover at a store drops below four days, the branch manager should get a WhatsApp message at 9am, not find out at the monthly review. If a site's discount rate crosses 12% for two consecutive weeks, the cluster head should see it that week. Set those thresholds with the people who will receive them, and keep the list short enough that every alert is worth opening.

Where to start

Pick one decision you make every week — stock replenishment, shift staffing, discount approval — and build a single view that supports it properly for two locations. Give it a shared data model, written definitions and one alert. If it survives a month of real use, expand it. Maysan Labs builds these dashboards for multi-location teams in India and the UK, typically over four to six weeks, and the start page is the shortest route if you already have that first decision written down.