What a site league table usually measures
Sort eleven sites by monthly takings and you will get a ranking. The question is what the ranking is a ranking of.
In most estates the answer is: floor area, footfall of the street outside, opening hours, how long the site has been trading, and — for at least one site — a reporting convention nobody has looked at since it opened. Management quality is in there somewhere, well down the list of contributing factors.
This matters because rankings are acted on. Somebody drives to the bottom site and has a conversation, and if the site is at the bottom because it is small and open six days a week, that conversation is unfair and useless in roughly equal measure.
The purpose of this guide is to remove, one at a time, every reason a site might be at the bottom that has nothing to do with how it is run. What survives is a much shorter list and a much better use of a day.
What this guide is not
Not group consolidation
This is locations inside one business. Separate legal entities with their own statutory books are a different exercise with different rules.
Not cost allocation
Splitting head office overhead across sites is a policy question. Here we compare what each site does on its own numbers.
Not a substitute for going there
The output is a shortlist. Nothing in a spreadsheet explains why a site is behind; that lives in the building.
Not a staffing tool
Rota data, headcount and staffed hours come from systems that are not document-shaped. Where this guide uses them, you supply them.
Three decisions to make once
What is the comparison for?
Deciding where to invest and finding a site in trouble need different tables. A single table trying to do both does neither.
Who sees it?
A table that goes to site managers should be one they can check. A table that goes only to the board can be blunter, and usually should not be.
What happens to the bottom site?
If the answer is 'a conversation', the table must be defensible. If the answer is 'nothing', do not build it.
1 · Gather one complete period
One period, every site, no exceptions. A comparison missing two sites is not a comparison of the estate — and the missing two are disproportionately likely to be the interesting ones, because a site that does not send its report is already telling you something.
Take whatever each site actually produces rather than what you wish they produced. Daily summaries, weekly reports, Z-report bundles, photographs of printed tallies. The formats will not match, and at this stage that does not matter.
Pick a completed period, not the current one. Half a month of data invites the same mistake this guide is about — comparing sites on different amounts of time.
2 · Read them into one table
Every site's figures into the same columns: site, period start and end, takings, transaction count, tender split, refunds, and the source file and page for each row.
The source reference is not bureaucracy. It is what lets a disputed number be settled in a minute rather than becoming an argument — and the first time a site manager challenges a figure, that minute decides whether anyone trusts the table again.
Do not standardise anything yet. Read it as reported, faithfully, including the site whose total is obviously computed on a different basis. Corrections applied at reading time become invisible; corrections applied as a recorded adjustment stay visible.
Up to 100 files go through in one pass, which for most operators is a month across every site. The mechanics are on multi-site sales reconciliation.
3 · Write down what each site means
This is the step everybody skips, and it is the one that decides whether the rest of the work is worth anything.
For each site, answer four questions and write the answers down somewhere permanent: Is the sales figure gross or net of refunds? Does it include delivery platform orders? Do staff meals and comped items pass through as sales? When does the trading week end?
For most operators this is an afternoon of phone calls, and it produces no chart at all — which is exactly why it does not happen. But it typically turns up two or three differences that have been quietly distorting comparisons for years.
Write it against the site, not in an email
The answers belong on the site record, so they travel with every figure that site produces. Left in an inbox, the same four questions get asked again next year by somebody else, and answered slightly differently.
The reason this matters more than it sounds is on location rollup: a definition mismatch produces numbers that are plausible, stable and consistently wrong, which is the hardest error to notice.
4 · Count trading days
One extra column, and it removes the largest single distortion in most monthly comparisons.
Sites do not all open the same number of days. Some close Sundays, some close Mondays, some shut for two weeks in August, one lost three days to a burst pipe. In a month, that is easily a ten percent swing — larger than most of the performance differences anyone is looking for.
Divide by trading days and a great deal of apparent variation disappears. A site turning over less in total but more per day is not underperforming; it is open less.
Count actual trading days rather than scheduled ones. A site that was supposed to open and did not is a different fact from a site that never opens on that day, and only one of them is a performance question.
5 · Flag partial periods
A site that opened on the nineteenth, one closed a fortnight for a refit, one trading reduced hours while the road outside was dug up. All three will sit at the bottom of an unadjusted table.
The instinct is to annualise or pro-rate them into comparability. Resist it for the first pass. A new site is not a smaller version of a mature site — it has no regulars yet, and scaling its nine days up to a month produces a number that describes nothing real.
Mark them partial and take them out of the ranking. Report them separately, against their own expectations rather than against the estate.
This costs one column and saves the most avoidable kind of management error: a visit to a healthy new site because a table put it last.
6 · Pick a denominator deliberately
Absolute takings rank sites by size. To rank them by anything else you need a denominator, and every denominator is blind to something.
| Per | Shows | Hides | From documents? |
|---|---|---|---|
| Trading day | Whether hours explain the gap | Size entirely | Yes |
| Transaction | How much each customer spends | How many came | Yes |
| Staffed hour | Whether labour is working | Demand outside its control | No |
| Square metre | Whether the space earns | Trade not tied to space | No |
Use two, not one, and look at where they disagree. A site strong per transaction and weak per trading day is busy but under-visited; the reverse is well-visited but under-selling. Those are different problems with different answers, and a single ranked column cannot tell them apart.
The last column is a practical constraint worth respecting. Staffed hours and floor area do not come off a sales report — if you want to use them, they have to come from somewhere else and be maintained, and a stale square-metre figure is worse than none.
7 · Compare each site to itself first
The most reliable comparison in multi-site reporting is not between sites. It is between a site and its own previous year.
Every structural difference this guide has been fighting — size, location, hours, price band, definition — cancels automatically, because both numbers come from the same site under the same conventions. What is left is movement, which is what you actually wanted to know.
It is unpopular because it produces no league table. Nobody is top. But it answers the question that matters operationally: is this site getting better or worse?
Do the cross-site ranking afterwards, and treat it as the second opinion rather than the headline. A site declining against itself while sitting third in the estate is a more urgent finding than the small site that has always been last and is up four percent.
8 · Shortlist, then go and look
After seven steps you have a handful of sites whose numbers are not explained by structure. Two or three, typically, out of eleven.
That is the output. Not an answer — a shortlist. And the correct next action is not another column but a visit, because the explanation for a genuine outlier is almost never in the data: a competitor opened, the good manager left, the bus stop moved, the sign is broken.
Go with the numbers rather than at the site with them. “You are last” produces defensiveness; “you are down nine percent on your own last year and I cannot see why” produces information, usually within ten minutes.
And write down what you find, against the site. Half the time the explanation turns out to be structural after all, and next quarter's table should already know it.
A worked example
Five sites, one month, invented figures. Ranked on takings alone, the order is obvious and useless.
| Site | Takings | Days | Per day | vs own LY |
|---|---|---|---|---|
| A | 84,200 | 30 | 2,807 | +3% |
| B | 71,900 | 26 | 2,765 | +1% |
| C | 68,400 | 30 | 2,280 | −9% |
| D | 52,100 | 22 | 2,368 | +4% |
| E | 19,800 | 9 | 2,200 | new |
On takings, site E is last by a mile and site D is fourth. Both readings are wrong. E opened on the twenty-second and traded nine days; D closed for a week's refit.
Per trading day the estate is remarkably tight — 2,200 to 2,807, and the gap between best and worst is smaller than the gap that raw takings suggested between second and third.
The finding is site C. It is third on takings, open every day, and down nine percent against its own last year while everyone else is up. It would never appear in a takings ranking as a problem, and it is the only site on this list worth a visit this month.
That is the entire argument of this guide in one table: the ranking that gets produced points at E and D, and the ranking that is worth having points at C.
How often to do this
Monthly for the comparison, weekly for exceptions. They answer different questions and confusing them wastes a lot of effort.
A weekly ranking is mostly weather, local events and which week contained a bank holiday. It moves constantly, none of the movement means anything, and people learn to ignore it — which is a shame, because they then also ignore the week something real happens.
What is worth doing weekly is the exception list from reconciliation: sites whose reported takings and banked money disagree. That is a completeness question, it has a right answer, and it goes stale within a fortnight.
Quarterly is where the estate-level judgements belong — investment, refit, closure — because a quarter is long enough that a single bad month stops driving the conclusion.
Publishing the table
How the comparison is circulated determines whether it survives, and this part gets almost no thought compared to the arithmetic.
Send it to the sites, not just upwards. A manager who sees their own figure will challenge it when it is wrong, and a challenged figure that gets corrected makes the table stronger. A table that only goes upwards accumulates errors silently until somebody acts on one.
Show the normalisation, not just the result. Trading days and the partial-period flags should be visible columns. Half of all disputes end the moment someone can see that their twenty-two days were accounted for.
Never send a ranking with a decision already attached. A table that arrives alongside a conclusion is treated as an accusation and gets argued with rather than read. The same table sent as a question gets answered.
And keep it short. A monthly pack with forty columns is not more rigorous than one with eight; it is just less likely to be opened, and it hides the two numbers that mattered.
Which numbers are worth putting in the table
A multi-site pack tends to grow. Somebody asks for a column, it gets added, and nothing is ever removed — until the monthly report has thirty columns and gets skimmed.
The useful test for any column is not “is this interesting” but “what would I do differently depending on its value”. Most columns fail it.
| Column | Decision it changes | Keep? |
|---|---|---|
| Takings per trading day | Whether this site is worth a visit | Yes |
| Movement against own last year | Whether something has changed here | Yes |
| Transaction count | Whether it is footfall or spend | Yes |
| Average transaction value | The same question, other side | Yes |
| Absolute monthly takings | Nothing — it is size | Context only |
| Rank position | Nothing — it moves for other sites' reasons | No |
| Percentage of estate total | Nothing at site level | No |
Rank position deserves special mention because it is the most seductive column on any multi-site report and one of the least useful. A site can fall two places without changing at all, purely because two other sites improved — and a manager who is told they dropped to seventh will spend energy on something that did not happen to them.
Four columns, plus context. Anyone who wants the thirtieth column should be asked what they would do differently, and the answer is surprisingly often that they would just like to see it.
Seasonality, and why sites do not share it
Every trading business has a shape across the year. The mistake in multi-site work is assuming that shape is the same at every site, and it frequently is not.
A city-centre unit serving office workers empties out in August and at Christmas. A unit on a coastal road does the opposite. A site next to a university has a shape driven entirely by term dates. Comparing them in July compares seasons rather than sites.
This is another argument for own-history comparison, and a strong one: a site against its own July carries its own seasonality automatically, with no need to model anything.
When you have to compare across sites anyway
Sometimes you must — a new site with no history, or an estate-level decision. Two things help. Compare a rolling twelve months rather than a month, which averages the seasonality out. And group sites into types before ranking, so the city-centre units are ranked against each other rather than against the coastal ones.
Grouping is unfashionable because it produces several small tables instead of one satisfying list. It is also the only way a mixed estate gets a fair comparison, and the effort is one extra field on each site.
What to do when one site refuses to fit
Most estates have a site that will not sit comfortably in any comparison: the airport unit, the concession inside somebody else's store, the seasonal kiosk, the one that trades four hours a day.
The temptation is to normalise harder — find a denominator clever enough to make it comparable. This usually fails, and it fails in a particular way: the clever denominator makes the odd site comparable and quietly distorts everything else.
The better answer is to stop trying. A site that is structurally unlike the rest of the estate should be reported on its own terms, against its own history and its own expectations, and left out of the ranking.
That feels like an admission of defeat and is actually the accurate treatment. Forcing a genuinely different business into a comparison produces a number that is wrong in a direction nobody can predict, which is worse than no number.
The test for whether a site belongs in the ranking is simple: could a manager move between this site and the others and apply the same playbook? If not, it is a different business wearing the same signage.
Seven mistakes
Ranking on absolute takings. It ranks the estate by size, which nobody needed a report to learn.
Skipping the definitions. The cheapest step to skip and the one that invalidates everything downstream.
Averaging partial periods into the table. A healthy new site ends up last and gets a visit it did not earn.
Using scheduled trading days instead of actual ones. A site that failed to open looks the same as one that never opens that day.
Ranking weekly. Mostly weather, and it teaches people to ignore the report.
Publishing only upwards. Errors never get challenged, so they compound until one is acted on.
Adding columns instead of visiting. After normalisation the answer is in the building, not in the data.
Who owns the comparison
A multi-site comparison with no named owner has a predictable life. It gets built by whoever asked for it, runs for four or five months, and then stops when that person is busy — and nobody notices for a quarter.
Ownership here means three specific things, and they are worth separating because they often belong to different people.
Somebody produces it on a fixed date, whether or not anyone asked. If it depends on being requested, it will eventually not be requested.
Somebody acts on the shortlist. Usually operations rather than finance, and the handover has to be explicit — a table sent to a distribution list is a table sent to nobody.
Somebody maintains the definitions. The dullest of the three and the one that decays fastest. Site conventions change quietly, and a comparison built on a two-year-old understanding of what each site means is back where it started.
The failure mode worth watching for is a comparison that keeps being produced after everyone stopped acting on it. That is more expensive than not having one, because it consumes effort and creates a false sense that the estate is being watched.
Checklist
One period, every site, none missing
All reports read into the same columns
Source file and page on every row
Each site's definition of sales written down
Trading days counted, actual not scheduled
Partial periods flagged and out of the ranking
Two denominators chosen deliberately
Each site compared to its own previous year
Normalisation visible in the published table
Table sent to sites as well as upwards
Shortlist of two or three, not a ranking of eleven
Findings written back against the site
The last one is what turns this from a monthly ritual into something that improves. An explanation discovered on a visit and written against the site means next quarter's table starts already knowing it.