By Matt Wampler, CEO of ClearCOGS
A server once came to my table after a youth soccer game and whispered, in the most apologetic voice I have ever heard, that they had run out of macaroni and cheese.
In a normal restaurant that is one disappointed table. On a buffet line it is every guest who walks in for the next hour, and every one of them can see the empty pan. Running out is not a private failure in that format. It is on display.
Which makes it strange that buffets are working with less demand information than almost anyone else in the industry.
The register records a guest, not a plate
Here is the structural problem, and it is worth stating plainly because it is easy to miss.
In most restaurants, the point of sale is a complete record of consumption. Somebody ordered the chicken sandwich, so a chicken sandwich was consumed. Multiply that across a few years of transactions and you have an extremely detailed picture of demand, item by item, in fifteen minute increments.
On a buffet, the register records that a guest came in and paid. It does not record that they took two pieces of fried chicken, skipped the green beans, and went back three times for the carved protein. Nobody rings in a plate. The item-level signal that every other restaurant takes for granted simply does not exist.
So the operator is left with a harder question. You know how many people are coming. How much of each of a hundred and fifty items does that translate into?
Usage per hundred, and why it works
The industry’s answer is a ratio. Usage per hundred guests, or per thousand dollars, depending on the brand.
The good operators have invested seriously in this. I have talked to brands that brought in time and motion specialists who spent weeks in their kitchens with stopwatches, timing every task in every recipe, so they know how long it takes to produce a pan of rice from the moment someone reaches for the pan. That work gets turned into build-to levels driven by a guest count forecast, and the result is a production system that runs with very little manual input. Add a limited time offer, set the pars for the new items, and everything else stays as it is.
I want to be clear that this is real engineering and it works. A brand running a disciplined usage-per-hundred system is not operating on guesswork. It is operating on a model.
It is just a model with a specific and now-addressable limitation.
The ratio is the assumption
What a usage-per-hundred system does, in forecasting terms, is generate one accurate forecast at the top, the guest count, and then split it into items using proportions taken from history.
That approach has a name and a well-documented weakness. Forecasters call it top-down disaggregation, and the standard reference text is direct about the tradeoff: a disadvantage is the loss of information due to aggregation, because top-down approaches cannot capture individual series characteristics such as time dynamics and special events. The same text notes that because historical proportions do not account for how those proportions change over time, top-down methods based on them tend to be less accurate at the lower levels of the hierarchy, and it points to using proportions derived from forecasts rather than from history as the fix (Hyndman and Athanasopoulos, Forecasting: Principles and Practice, section 10.4).
Translate that out of the textbook and into a dining room and it says something an operator already suspects.
Eight hundred guests on a Sunday afternoon do not eat like eight hundred guests on a Tuesday. A family crowd works through different pans than a retiree lunch. A cold February weekday moves comfort items. A hot July Saturday moves salad and cold sides. The weekend after a local event brings a different demographic entirely.
A fixed ratio treats all of those as the same eight hundred people. It is right on average and wrong in a pattern, and the pattern is predictable, which is precisely what makes it worth attacking.
What actually changes
The shift is small to describe and significant in practice: stop treating the conversion rate as a constant and start treating it as something you forecast.
The guest count is one prediction. The mix is a second one, and it has its own structure. Day of week. Daypart. Season. Weather. The local calendar. Whether a promoted item is running. Those are the same signals that drive demand anywhere else, and they move the ratio just as surely as they move the door count.
The obvious objection is that you cannot forecast consumption you never recorded. That is less true than it looks.
You do not need a ticket to know what was eaten. You need what was produced, what came back at the end of the service, and how many guests walked through. Those three numbers give you consumption, and the first two already exist in most kitchens in some form, even if they live on a clipboard. A short calibration period, on the order of a week or two capturing production in and product out, is usually enough to establish the relationship. After that the register’s cover counts carry it forward, and the ratios keep updating themselves instead of sitting frozen in a spreadsheet that was last revisited when the menu changed.
That is a meaningfully different proposition than asking managers to log consumption forever. It is a short, bounded measurement exercise that buys you a model which then maintains itself.
Why this stops being optional
Buffet economics have always depended on the arithmetic working across a crowd. Some guests eat more than they paid for, some less, and the average holds.
Commodity pressure attacks that directly, and it does not attack evenly. When protein costs run hard, the exposure concentrates in exactly the items guests load up on, which are usually the items with the shortest holding window and the widest swing between a quiet Tuesday and a busy Sunday. A fixed ratio is least reliable precisely where the money now is.
The operational answer is not to produce less and hope. On a buffet, an empty pan is the most visible thing in the building. The answer is to be right more often about which pan, and how much, and when.
Wider than buffets
None of this is unique to one format. It applies anywhere the register records an entry rather than an item.
Campus and corporate dining on a meal plan. Hotel breakfast included with the room. Catering delivered as trays rather than covers. Open bar events. Family style service where one order feeds a table of unknown appetite. In each case the transaction data tells you how many people, and the operator is left to convert that into production with a rule of thumb that nobody has revisited in a while.
For decades that conversion was the only practical option, because modeling a ratio that moves with weather and daypart and local events was not something a spreadsheet could do. That constraint has lifted. The guest count forecast, which these operations have generally gotten good at, is now only half the problem worth solving. The other half has been sitting there the whole time, treated as a constant because it had to be.
This is the work we spend our days on at ClearCOGS: taking the data a business already produces and turning it into a specific number for each item, before the shift starts, including in formats where the register never recorded what people actually ate.
If you run a buffet or any operation where the point of sale counts guests rather than plates, that conversion is probably the largest unexamined assumption in your production system.
Sources
- Hyndman, Rob J., and Athanasopoulos, George. Forecasting: Principles and Practice, 2nd edition. OTexts, section 10.4, “Top-down approaches.” Open access. otexts.com
