Signals

A hospitality operator, reviewing the till system they run their business on, wrote that the data in the reports is sometimes inconsistent, and gave cost of goods as the example. Not missing. Inconsistent. The report runs, produces a number, and the number is wrong in a way nobody can predict.

Look underneath and the cause is usually structural rather than a bug. The same system cannot model a composite item and a variant at the same time, so a meal deal with a choice of drink has to be entered as something it is not. Another operator described exactly that: a value meal with a free drink attached, and no honest way to record what actually left the building.

Once the entry is a compromise, every figure downstream inherits it. Stock decrements against the wrong item. Cost of goods drifts. The report is not lying so much as faithfully reporting a fiction that was agreed at setup and never revisited.

So the manager recalculates by hand before anyone senior sees it. That hour is real work, it appears on nobody's rota, and it continues for as long as the item structure cannot express what the kitchen actually sells.

A widely used online ordering platform permits one tablet. One. Front of house and the kitchen cannot both hold a live view of incoming orders, and operators asked for this for years without it reaching the roadmap.

The same platform prices delivery as a flat fee or a percentage, with no way to charge by actual distance. A till used by thousands of small venues has no floor map and no support for more than one menu, so a place with a lunch card and an evening card is running one of them somewhere else. A serious European system, sold only through resellers, publishes no price list at all, and a Dutch review this year scored both its reporting and its integrations six out of ten while noting separate charges for updates, training and out-of-hours support.

None of these are scandals. Each is a reasonable product boundary. What they share is that the gap does not stay a gap. Somebody fills it, and that somebody is on the payroll.

The second tablet becomes a person walking to the kitchen. The distance-based delivery fee becomes a manual adjustment on the phone. The second menu becomes a laminated card and another set of prices to remember. The subscriptions arrive on an invoice. This does not.

The clearest example we have seen is not a hack invented by a frustrated operator. It is published by the vendor.

Faced with the one-tablet limit above, the documented advice is to take orders on the first tablet, then put a second tablet in the kitchen and configure its email client to collect the automatic order confirmation emails. That is an email inbox used as a kitchen display. It works. It is also exactly the sort of arrangement that survives three managers, ends up in the training notes, and leaves nobody able to say why the kitchen watches an inbox.

The same shape appears around reporting. When the built-in figures cannot be trusted, the routine becomes exporting to a spreadsheet and correcting it there. One reviewer found their exports mangled accented characters, so even the export needs a pass before it is usable. Another reported syncing failures between devices and database rollbacks, which makes the spreadsheet not a formatting step but the actual reconciliation.

This is the argument for being careful with any platform, ours included. A workaround is a problem somebody already cared enough to solve badly. It is the most useful thing to find when working out what to build, and the most dangerous thing to leave in place, because after about six months a temporary fix that works is indistinguishable from a decision.

Worth adding: that ordering platform has announced it closes on 30 April 2027. Every workaround built on top of it now has an expiry date, whether or not the people running it know that yet.