Every grocery chain that takes catering orders on paper learns the same lesson the same way. Here is what changes when you move to a rules-based capacity model.
The single highest-demand catering day of the year, in almost every European market, is the day before New Year's Eve. The same is true for Christmas Eve, Easter, and confirmation weekend in the Nordics — but New Year's Eve is the worst, because it concentrates demand into a window of 6–8 hours per store.
A typical 50-store chain will field something like:
If demand exceeds capacity at any single store, three things happen, in this order: customers are disappointed, store staff burn out fixing it, and the chain quietly stops promoting catering for next year. We have watched this loop repeat at chain after chain.
The problem is not demand. The problem is the absence of a capacity model. This article is about what that model looks like and what it costs not to have one.
In a single-store operation, capacity is enforced by the person taking the order. They know the kitchen. They know what's already booked. They say “we're full on the 31st, can I do the 30th?” and the customer accepts.
In a 50-store chain, the person taking the order is:
So they say yes. They write the order down. They hand it to the morning shift, who discovers at 6am on the 31st that they've been booked at 140% of physical capacity. The morning shift then makes choices: which orders to call and apologize to, which orders to cut portions on, which to deliver late.
This is not a process problem that can be fixed with better paper. It is a structural problem: information about remaining capacity does not exist in the customer's hand at the moment they place the order. Without that information, the only way to enforce capacity is after the fact, by humans, under stress.
Consider a real example. A mid-market supermarket store has the following on December 31:
Translate that into product:
Maximum throughput for the day, with every constraint binding:
That is the physical maximum. The promisedmaximum should be lower — somewhere around 80–85% of physical, because something always goes wrong on December 31.
Now compare that to what the same store can sell if catering orders flow through a paper-and-phone process. The honest answer is “however many the staff happens to say yes to,” with a hard ceiling at “more than the kitchen can do.” There is no enforcement, only apology.
The cost of getting this wrong is not just the disappointed customers on December 31. It is the chain-wide reputation damage from any one store overpromising — the news travels through one negative review, one local-paper story, one social-media thread, and the whole brand absorbs it.
The model that works has three parts.
Per-store, per-day capacity caps. Every store has a maximum number of orders per day per category — buffets, roasts, cakes, sandwich platters. The cap is set by the store manager based on their kitchen. Caps are visible to head office and reviewable per season.
Real-time consumption visible to customers. As orders come in, remaining capacity decreases. When the cap is hit, the date is greyed out in the ordering interface. The customer never sees a date the store cannot deliver. There is no human in the loop saying “no” — the platform has already said it for them.
Lead-time rules per product. A julefrokostbuffet might require a 3-day lead time. A celebration cake, 2 days. Lead times are enforced by the same engine that enforces capacity. A customer browsing on December 28 cannot order a buffet for December 31, because the rule says “no buffets within 3 days.”
This sounds obvious. It is not implemented in 90%+ of European grocery catering operations. The few chains that have it built it themselves at considerable expense, or use platforms (FoodStorm in the US, DeliChain in Europe) that have it as a first-class feature.
The result: orders distribute themselves across the available days. December 28 fills up, then December 29, then December 30, then December 31. Customers who want December 31 specifically and find it full pick the 30th, or the 29th, or pick a different store within the chain that still has capacity. The chain captures revenue across more days, and December 31 becomes a busy-but-survivable peak instead of a guaranteed disaster.
The same math applies every Tuesday in February, just with smaller numbers.
Every store has a daily ceiling on how many catering orders it can produce without disrupting its regular deli operations. Without a capacity model, that ceiling is enforced by the same broken human process as on December 31 — except the disappointment is more diffuse and less visible. Orders are quietly declined. Customers are told “we don't really do catering” by overworked counter staff. Reputation degrades by a thousand small cuts.
With a capacity model, a slow day is a catering-promotion day. The platform can surface available stores and dates to nearby customers. The chain can run targeted offers (“free delivery on Wednesdays”) to even out the load. The deli department becomes a revenue lever the chain can actually pull, instead of a fixed cost it tries to manage.
If your chain takes catering orders on phone, paper, or a generic web form that doesn't enforce capacity, you have one of two situations:
Usually it is both. The fix is the same in either case: a capacity model that runs in the customer's hand at order time, not in the head of an overworked counter clerk.
The math is straightforward. The platform that runs it is not — but it exists, it is proven at chain scale, and the gap to deploy it is measured in months, not years.
This article draws on direct operational experience with three retail brands across 100+ Danish stores running on the DeliChain platform. The capacity math example is illustrative, simplified for clarity; real store capacity models are richer (hot vs cold, dishwasher cycles, refrigerator volume, pre-allocated shelf space) but the structure of the problem is identical.
We will walk you through the rule engine on a live demo and show you how it would map to your chain's store mix.
Book a Demo