The F&B data that feeds the menu

The printed menu was decided once a year, in a meeting, with opinions. The digital menu produces evidence every day: what gets ordered, what gets ignored, at what hour and from which room. The hotel that closes that cycle (a menu that generates data, data that corrects the menu) stops arguing over taste and starts deciding on behavior.

The cycle paper never managed to close

With a printed card, the menu was an annual bet: dishes came in on the chef’s intuition, on tradition or because “it has always been there”. The only feedback was waste in the storeroom and complaints at the door. The digital menu changes the nature of the document: every order is a vote, every opened section is a glance and every ignored dish is a message. The full cycle has three steps that repeat without end: the menu proposes, the orders respond, the menu gets corrected. A menu that is not corrected by its own data is a printed card with a battery.

The dish nobody orders is not neutral

The natural reaction to a dish that does not sell is to leave it there: “it does no harm”. It does harm three times:

• It takes a spot in the storefront. Each screen shows a limited number of dishes before the guest decides, and the one that does not sell is taking that spot from one that would.
• It takes supplies in the storeroom. Ingredients bought “in case someone orders it” that expire more often than they get cooked, and that the kitchen must keep ready just in case.
• It takes the guest’s attention. A long menu does not get read: it gets abandoned. Every filler dish makes it harder to find the one that actually tempts, and the lost sale is not paid by the weak dish but by the good one.

The dish nobody orders is not harmless: it pays rent on your menu with a photo, inventory and your guests’ attention, and bills nothing in return.

How to read the signals before deciding

Not every weak dish deserves the exit: some are not liked and some are simply not seen. The data tells the cases apart, and each case has its decision:

Peak hours also ask for sections

The orders-per-hour curve does not only say when to reinforce the kitchen: it says which sections the menu is missing. Scans and cravings late at night, when the hot kitchen is closed, are asking for a cold night menu. A pool afternoon full of one-off drink orders is asking for a snack section designed for the lounger. A spike of orders right before breakfast hours is asking for scheduled ordering. The new section is not invented in a meeting: it is read in the curve.

One dish per season: the controlled experiment

A living menu does not mean changing everything monthly: it means testing with method. The simplest version is one experiment per cycle:

1. One new dish per season, not five at once. If five come in, you will not know which one worked or why.
2. Give it fair conditions: a photo up to the standard of the rest, a clear description and a visible spot in its section. A poorly presented candidate proves nothing.
3. Define the success criterion before launch: how many orders per week justify its place, compared with the dish it displaced.
4. At the end of the cycle, decide with the number: it stays, it gets adjusted (price, photo, portion) or it leaves. No sentimental appeals.

The menu gets versioned, like any product

The printed card was an edition; the digital menu is a version. Treat it the way a manager treats rates: something reviewed on a calendar, with an owner and a record of what changed and what happened next. None of this works if changing the menu is a chore: in Room Order, editing a dish, hiding a section or testing a price takes minutes, and the F&B reports of the same system tell you what happened afterwards. The full cycle (menu, data, correction) lives in one place inside R2 OS.