The worst counter was not on the list
A hall owner asks one question of guest feedback: which kitchen are people unhappy with? Our report answered it from the newest 500 answers, so the one kitchen everybody complained about was missing from the list entirely.
Guest feedback in a food hall exists to answer one question, and it is not "how are we doing". A hall is a landlord with six tenants. The question is which counter is the one people are unhappy with — because that is the conversation the hall owner has to have on Monday, and a single score for "the hall" averages it into nothing.
Our report answered that question. It listed every kitchen, worst average first, so the counter you needed to talk to was the top row. It also read the newest 500 answers and worked the whole thing out from those.
What that does
Take a year at a six-kitchen hall. Five kitchens trade all year and people are happy. One traded for the first three months, got slated, and left. Set the report's period to a year — the picker offers exactly that — and here is what the two versions say about the same data:
- The whole year: 3,740 answers, 90 unhappy, six kitchens listed, the bad one at the top.
- The newest 500: 500 answers, none unhappy, five kitchens listed.
The kitchen is not shown badly. It is not shown at all. Every one of its answers is older than the cut-off, so it never enters the calculation, and the list is sorted worst-first — which means the row that falls off the end is precisely the row you opened the screen to find.
A missing row is worse than a wrong number
This is the part worth taking away, because it generalises well past feedback. A wrong number invites suspicion: £685 where you expected £850 makes somebody frown. An absent row invites nothing. A list of five kitchens at a six-kitchen hall reads as complete unless you happen to count. You cannot notice something that is not there.
Any report that groups by something — by kitchen, by staff member, by supplier, by day — inherits this. If the rows it groups came off a capped fetch, whole groups can vanish silently, and the quiet ones vanish first because they have the fewest recent rows. The quiet ones are often the ones with the problem.
The function was telling on itself
There was a clue sitting in the code the whole time. The summary always returns a sentence rather than a bare score — "4.2 out of 5, from 340 answers" — deliberately, because an average of three is a number people quote as though it means something. That sentence is a promise about its own input. Fed a sample, it kept making the promise and the promise became false: "from 500 answers" when there were 3,740.
That is a genuinely useful thing to look for in your own reporting. Where a figure states a fact about what it is made of — across 12 sites, from 340 answers, over 90 days — somebody has to check that whatever feeds it makes the sentence true. Nothing enforces it.
What we changed
The scores are now counted rather than listed: one grouped query, five rows per kitchen however long the period is, so the complete answer is actually cheaper than the sample was. The written comments are still capped at fifty, because that is a reading list and nobody reads more — and the heading now says so: "What they wrote — newest 50 of 89".
More on how we think about halls with several kitchens under one roof is on the ordering page, and a food hall is not one business covers why the tenant/landlord split runs through all of this.