Why does a dashboard across branches show numbers that don't add up?
Because the same word means different things in different branches. "Stock checked" at your Andheri outlet means someone counted every SKU on the shelf. "Stock checked" at your Pune outlet means the shift supervisor glanced at the shelf and said it looked fine. Both show up as a green tick on your dashboard. Only one of them is true.
This is the trap most owners fall into when they scale past two or three locations. Business is growing, you can't be everywhere, so you buy a dashboard — a reporting tool, an app, something that promises "one view of all branches." You roll it out, wait for the numbers to settle, and then notice something is off. Branch A reports zero customer complaints for three months straight. Branch B reports twelve in one month. Either Branch A is running a miracle operation, or Branch A's staff aren't logging complaints the way Branch B's staff are.
A dashboard cannot tell you which one it is. It just adds up whatever each branch typed in. If the inputs mean different things, the sum is decoration, not information.
What's actually broken — the branches or the report?
Neither, really. What's broken is that the process was never written down the same way in each location. It lived in each branch manager's head, and heads don't copy-paste. One manager learned "closing" from the previous manager at that outlet. Another was trained by someone from a different chain entirely before joining you. A third just worked it out on their own three years ago, and it stuck.
Think about a dairy and frozen foods distributor running cold stores in Nashik, Indore and Siliguri. All three are supposed to log the cold-store temperature every four hours. In Nashik, the storekeeper writes the reading on a paper register and photographs it at the end of shift. In Indore, the reading gets typed into a WhatsApp group, no photo. In Siliguri, it only gets logged when the area manager happens to visit. On paper, all three cold stores are "compliant." In reality, you have one with proof, one with a claim, and one with nothing. A head-office dashboard that just counts "logs submitted" shows three green boxes and hides the one that matters.
This is standardisation, not visibility. You don't have a shortage of data. You have three versions of the same process pretending to be one process.
What does a standardised process actually look like?
It means the same task, wherever it happens, has the same steps, the same owner role, the same proof, and the same consequence for a miss. Not the same person — the same shape.
Take the closing stock check across an eleven-outlet retail chain. A standardised version looks like this: the shift supervisor counts physical stock against the register between 9:00 and 9:15 pm. A photo of the counted register is the required proof — not a text saying "done." If the photo isn't in by 9:20, the area manager gets an alert automatically. That's the whole definition: action, owner, proof, escalation. Every outlet runs the same four things, whether it's the flagship store in Bandra or the two-person counter in a tier-2 town.
We've written before about why this exact structure — action, owner, proof, escalation — is what separates an SOP that gets followed from one that gets filed and forgotten. The same logic scales from one branch to twenty. A process description with no owner and no proof is a suggestion, not a process, whether it lives in one outlet or eleven.
Once every branch is running the same defined steps, a dashboard finally has something honest to add up. Before that, it's just averaging noise.
What should stay different between branches, and what shouldn't?
Not everything needs to be identical, and pretending otherwise is its own mistake. Store size, staff strength, opening hours, footfall — these genuinely differ between a hill-station outlet and a metro flagship. A ten-person warehouse and a two-person godown will never run at the same pace.
What has to stay identical is the shape of the process: who owns each step, what proof closes it, and what happens when it's missed. Nashik can run three people on the cold-store floor and Siliguri can run with one — that's a resourcing difference, not a process difference. The temperature log for both still needs a named owner, a photo of the reading, and an alert if it's late. Local reality is allowed to change the inputs. It should never change the definition of done.
Get that shape right once, and differences in size, hours or headcount stop mattering to the dashboard. Get it wrong, and no software averages away the gap — it just reports the gap faster.
Where do most owners try to fix this, and why it doesn't work?
Most owners fix the report before they fix the process. They add more columns to the spreadsheet, more fields to the WhatsApp update, more detail to the weekly call. This makes the report longer, not more true. If Branch A and Branch B still define "complaint logged" differently, adding a column for "complaint severity" just gives you two inconsistent numbers instead of one.
The fix has to happen upstream of the report — in the process itself, before it produces any number at all. This is the same gap we've covered when looking at who actually builds the MIS report each morning: a report is only as reliable as the process feeding it, and no amount of formatting fixes a feed that isn't standard to begin with.
What to do this week
Pick one process that runs at every branch — closing stock, shift handover, complaint logging, whatever touches money or customers most often. Call three branch managers and ask them, separately, to describe exactly how they do it, step by step, right now. Don't tell them what the "correct" version is first. Write down all three answers side by side.
You will find gaps — one branch checks something the others skip, one has no proof step at all, one escalates to a person who left the company two years ago. Pick the best version of each step, write it down once as the standard, and give it to all three branches with a proof requirement attached. Do not touch the dashboard until this is done. The dashboard was never the problem. It was just showing you, accurately, that you didn't have one process — you had three.