Your screens are beautiful. Is what they display true?

Walk through any modern canteen, hotel breakfast room or campus food court and the screens are everywhere: menu boards above the counter, a welcome display in the lobby, kiosks, a web page showing this week’s menus, sometimes a printed card still on the table. The hardware got beautiful. The question nobody asks is quieter: where does the content on those screens actually come from?

In most operations, the honest answer is: from somebody retyping it. The chef finalizes the menu in one place; an assistant copies it into the signage platform’s template; someone else updates the web page; the buffet cards get typed a third time. Every one of those keystrokes is a chance for the screen to disagree with the kitchen — a price that didn’t follow this morning’s change, a dish that was swapped after the menu was sent, and most seriously, an allergen line that describes last week’s recipe.

A screen that displays wrong allergen information is not a cosmetic problem. Under EU Regulation 1169/2011 and its national implementations, what you display is your declaration. The prettier the screen, the more authoritative the error looks.

The fix is not another screen. It’s a source.

The signage industry solved the display problem years ago — the platforms are excellent at layouts, playlists, schedules and screens. What they cannot know is what is actually being cooked today, at which site, with which ingredients, at what price. That knowledge lives in the kitchen’s recipe and menu system.

So the architecture that works is the same one we argue for with ERPs and cash registers: keep your signage platform — feed it from the source. In CalcMenu, the menu the chef builds and the manager approves is already structured data: dish names in every service language, current prices per site, allergens computed from the actual recipe composition, nutrition values, origin, even the Eco-Score. Publishing is then a data flow, not a typing job:

Via API or interface, into the signage you already own. CalcMenu exposes the approved menu — dishes, descriptions, prices, allergens, translations — so your existing signage platform can pull it (or receive it) and render it in your own templates and branding. Your signage vendor keeps doing what it does best; it just stops depending on somebody’s afternoon of copy-paste. The same principle already drives our POS connector, which pushes items, prices and allergens to cash registers and ordering platforms: one source, many channels.

Or directly, without a third-party platform. For operations that don’t run a signage system, CalcMenu publishes the approved daily menu itself — to screens, to the printed card, even to Evolis card printers — simultaneously, in one click. The chef creates, the manager validates, and every channel updates together.

And down to the buffet label. The same logic extends past the big screens to the smallest display in the room: electronic shelf labels at the buffet show dish name, allergens, origin and price straight from CalcMenu — change the dish, and the label follows, with no reprinting.

What changes operationally

The update becomes the non-event. Price adjustment on the daily menu at 9:40? The board above the counter, the lobby screen, the web menu and the buffet labels all say the same thing by 9:41 — because none of them was edited. They were all reading the same record.

Allergen display becomes an output, not a task. Nobody “does the allergen icons” for the screens anymore. The icons are derived from the recipe’s actual composition, the same source that feeds your labels and menus. When a recipe changes, every display that shows it changes — which is precisely the single-source-of-truth architecture that allergen compliance demands.

Multi-site and multi-language stop multiplying the work. Ten sites with different menus and three service languages is thirty versions of manual signage work — or zero, when each screen simply requests its own site’s approved menu in its own language.

The screens finally earn their keep. Digital signage was sold on flexibility: change anything, anytime. Most operations use a fraction of that, because every change costs manual work downstream. When the content flows from the kitchen system, the flexibility becomes real — daily menus, spontaneous changes, sold-out dishes removed mid-service.

The question to ask your signage setup

Not “can it display our menu” — of course it can. Ask instead: when the chef changes the menu, how many humans touch how many systems before every screen is correct? If the answer is more than zero, your signage has a data problem wearing a design solution.

Whether the fix is feeding your existing platform through an API or interface, or letting CalcMenu drive the displays directly, the principle is the same one that runs through everything we build: the recipe database is the single source of truth, and every screen, label, card and register is just a view of it.

To see your menus flow from kitchen to every screen — through your signage platform or directly — request a demonstration.