A report that sorts worst-first can hide your worst kitchen
A report capped at the newest few hundred rows, sorted worst-first, will drop the exact row you opened it to find. A short tour of how a cap on a summary lies, and why it gets quieter as you grow.
You open the guest-feedback report to find the kitchen people are unhappy with. The report lists kitchens worst score first, so the answer should be at the top. Sometimes the kitchen you are worried about is not on the list at all. That is not good news. It is a bug.
How a cap turns into a lie
A report is built from rows — here, every piece of feedback in the period. If the query fetches the newest few hundred and stops, and the period the date picker allows is a whole year, then a busy hall generates far more feedback than the cap, and the report is built from a sample it treats as the total.
Now add the sort. The rows are ordered newest first to apply the cap, then grouped by kitchen and sorted worst first. A kitchen whose unhappy customers were all a few weeks ago — older than the cap reaches — contributes no rows, so it is absent from the list entirely. The one place it should have appeared, top of a worst-first list, is the one place a missing row is impossible to notice.
“Worst of” and “which are missing” are totals too
A cap on a list somebody scrolls is fine — nobody reads past the first screen. A cap on a total is a lie, and a “worst of”, a “which kitchens have complaints” and a per-kitchen breakdown are all totals wearing a different hat. The tell is that the report looks completely healthy: it shows a number, the number is plausible, and it is quietly too small. It gets worse as the business grows, because the real total climbs away from the cap while the report keeps reporting the cap.
The check
Ask any report that summarises a period how many rows it read, and compare that to how many exist. If a report cannot tell you, be suspicious of it — a summary that does not know its own denominator cannot promise you the answer is complete.