Restaurant Tech
Why restaurant chains fail at scale, and the tech stack that prevents it
One location runs on a notebook. Three branches without a system is where inventory bleed, unrecorded voids, and staff time theft quietly become the margin.
The second branch is the one that teaches you the business you actually have.
A single restaurant is a system with one operator at the centre of it. The owner knows what came in, roughly what went out, who was on shift, and whether the evening felt right. That knowledge is real and it is enough. It is also completely non-transferable.
The second location does not fail because it is a worse restaurant. It fails because the operator can only be in one of them, and everything they were holding in their head at the first site now has to exist somewhere else.
The three places margin actually goes
Inventory variance. In a single site, theoretical usage and actual usage are reconciled by instinct, because the owner notices the chicken is going faster than it should. Across three sites nobody notices until the monthly stock count, and by then the variance is a number without a cause. You know you lost four hundred thousand rupees of food. You do not know at which branch, on which shift, or whether it was theft, over-portioning, or waste that nobody recorded.
Unrecorded voids and comps. Every restaurant voids items. The question is whether the void is attached to a shift and a person. Where voids are a manager override with no record, the void becomes the mechanism: an item is rung in, served, paid for in cash, and voided. This is not a hypothetical failure mode; it is the single most common form of loss we find when we instrument a multi-branch operation.
Staff time. Rosters written on paper and hours confirmed verbally produce payroll that is directionally correct and specifically wrong. At one site the owner catches it. At three, a systematic fifteen minutes a shift across thirty staff is a full-time salary a year.
None of these are dramatic. That is exactly why they persist. No single instance is large enough to investigate.
What has to be true of the system
The failure mode of restaurant technology is that it optimises the customer-facing side and leaves the operational side to spreadsheets. That gets you a nice ordering experience on top of a business you still cannot see.
The stack that actually prevents the three problems above needs four properties:
Every transaction is attributable. Order, void, comp, discount, and refund, each attached to a person and a shift, without a manager override that erases the trail. The point is not distrust. It is that unattributable events cannot be investigated, so they are never investigated.
Theoretical usage is calculated automatically. If a dish has a recipe, the system knows what selling it should have consumed. Variance becomes a daily number per branch rather than a monthly surprise across all of them.
One view across branches. Not three dashboards. If comparing sites requires opening three systems and exporting to Excel, it will happen monthly at best, which is too late to act on.
Ticket times are recorded, not felt. Kitchen throughput is the constraint on covers, and most operators manage it by standing in the pass. Recorded ticket times let you manage it from anywhere, and they make the difference between branches visible.
The commission question
Separately from all of this: most chains are giving up to thirty percent of every delivered order to an aggregator.
The usual defence is that the aggregator brings demand you would not otherwise have. For a new site with no local recognition that is often true. For an established brand with a repeat customer base it stops being true fairly quickly, and you are paying thirty percent to rent a relationship you already own.
A direct ordering channel does not replace aggregators. Realistically nothing does. It changes the mix. Moving a third of delivery volume to a direct channel on an operation doing meaningful delivery numbers is usually worth more than every efficiency gain in the previous section combined, and it is the easiest of them to implement.
The reason we mention it last rather than first is that a direct channel on top of an operation you cannot see just means losing money faster with better margins on it.
Where to start
If you are running two or three sites and something feels wrong but you cannot name it: instrument voids first. It is the cheapest thing to fix, it requires no new hardware, and it will tell you within one month whether you have a process problem or a people problem.
Everything else is easier to justify once you know which one you have.