Most restaurants do not have one menu. They have four, maintained in four places, and they only find out how far apart the copies have drifted in the middle of a Saturday rush.
August 17, 2026
The line calls out that the salmon is gone at 6:40 on a Saturday. A server marks it 86 on the terminal, the kitchen board updates, service carries on. Forty minutes later a delivery ticket prints for two salmon. Then another. The marketplace never got the message, because the marketplace menu is a different menu, living in a different portal, last touched by whoever had the password in the spring. What follows is a refund, a one-star review about an item the guest never received, and a manager spending twenty minutes of peak service inside a phone menu editor. That is not a staffing problem. It is a menu architecture problem, and nearly every restaurant running more than one ordering channel has some version of it.
Nobody sets out to run four menus. You get there one reasonable decision at a time. The POS menu was built by an installer during onboarding. The online ordering menu was built months later when the website went up, from a slightly newer PDF. A marketplace onboarding team typed a third version off a photo of a printed menu. Then a kiosk arrived, or catering got its own order form, and now there is a fourth. Each was a copy of something. Copies drift, and they drift silently, because no single screen ever shows you all four side by side.
There are two quick tests. First: how long does it take to change one price everywhere, and how many logins does it need? If the honest answer is longer than a few minutes or more than one login, you have copies, not a menu. Second: when two channels disagree, does anyone in the building know which one is right? If the answer is that it depends who you ask, the drift is already costing you money — usually in undercharged items and comped orders that never get traced back to a stale price.
A properly structured menu is one record. Items, descriptions, prices, modifier groups, tax treatment, prep station routing and availability all live in one place. Channels are publishing targets, not copies — a view of that record with its own rules layered on top. You edit the item once and every channel reflects it, including the ones you were not thinking about when you made the change.
That does not mean every channel looks identical. Some differences are legitimate and even necessary. The distinction worth being strict about is which fields a channel may override and which it may never touch.
| Channel | Reasonable to differ | Should never differ |
|---|---|---|
| Dine-in POS | Course routing, seat assignment, coursing prompts | Item names, modifier structure, allergen information |
| Direct online ordering | Photos, longer descriptions, pickup and delivery windows | Price relative to dine-in, item identity, tax treatment |
| Third-party marketplace | Menu price, item subset, prep time estimates | Item names, modifier groups, what prints for the kitchen |
| Kiosk and QR ordering | Upsell prompts, image-led layout, category order | Prices, availability, modifier rules |
| Catering and large orders | Minimums, lead times, package pricing, tray sizes | Recipe identity and how inventory is depleted |
Read that right column again, because it is the part people concede first under time pressure. The moment a marketplace importer renames an item or flattens a modifier group, your kitchen is reading two different tickets for the same dish, your sales reports stop aggregating cleanly, and your item-level margin analysis quietly becomes fiction. If you have ever tried to run menu engineering across channels and found the numbers would not reconcile, this is usually why.
Availability is the field that changes most often and travels worst. One action — from any terminal, from a manager phone, or straight from the kitchen display — should mark an item unavailable everywhere within seconds, and turn it back on just as fast when the walk-in delivery lands. That is the whole feature. Everything else about menu management can survive a five-minute lag; this cannot.
Countdown availability is the underrated version of the same idea. Prep-limited items — twelve short rib portions, forty morning croissants — should carry a count that decrements as orders come in and pulls the item automatically at zero. It sounds fussy until you compare it to the alternative, which is a cook shouting a number across a kitchen and hoping the front of house heard it correctly.
The cost of getting this wrong is not just the refund. On most marketplaces, cancelling an accepted order affects your standing, and repeated cancellations quietly reduce how often you get shown. You end up paying commission for less visibility. And the guest who ordered a dish you did not have is not a guest with a neutral opinion of you — they are the one writing a review about it.
Marketplace commission is real money. Selling a dish at the same price on a platform that takes a meaningful cut of every order frequently turns a profitable item into a break-even one, and sometimes worse once packaging is counted. Adjusting menu prices for marketplace channels is normal, permitted by the platforms, and something most established operators already do. What matters is doing it deliberately, from one place, with the delta visible — not by editing a portal at midnight and forgetting the reasoning six weeks later.
The trap is letting that logic bleed into your own channel. Your commission-free online ordering carries no per-order commission, so pricing it like a marketplace hands the difference to nobody and gives guests no reason to order direct. Price it at dine-in parity and let the gap between channels do the persuading. The arithmetic behind that choice is worked through in commission-free vs third-party delivery, and the plumbing side is covered in delivery integrations explained.
Item names port between systems easily. Modifiers do not. Required versus optional, minimum and maximum selections, nested choices, per-option upcharges, the specific wording the kitchen needs to see — all of it is structural, and most channel importers flatten it into a plain list because that is all their data model holds. What arrives on the other side looks close enough in a menu editor and is wrong on the line.
The practical rule: build modifier groups once, make them reusable across items, and never let a channel editor create a local modifier. If a channel needs something a modifier group cannot express, fix the group rather than patching the channel. And audit it the cheap way — take your three most-modified items, place a real order for each on every channel you run, and read what prints in the kitchen. An hour of that finds more problems than a day of comparing screens.
Groups face the opposite failure. Centralise too hard and a location cannot 86 an item or reflect its own market pricing. Decentralise and within a year the same dish has five names, four prices, and no comparable reporting. The workable middle is a core menu owned at group level — items, recipes, modifier structure, naming — with a short, explicit list of what each location may override, normally price and availability, occasionally a small set of local items.
Written that way, a corporate price change or seasonal rollout is one edit that reaches every store, and a store that changes something is making a visible, auditable choice rather than a quiet exception. That governance is the same principle covered in POS for franchises, and it applies just as much to a two-location group as to fifty.
Menu hygiene fails when it depends on someone remembering. Put it on a schedule instead — this takes about fifteen minutes a week once the structure is right.
Ask how many places a price lives. Ask whether 86ing reaches marketplaces, how long that takes and whether modifier groups are reusable. For an outage, require a capability-specific boundary rather than assuming menu sync or reconciliation. On Novaryq, the Beta offline-cash workflow covers cash order entry on a supported, prepared terminal with the workflow enabled; card payments require connectivity, and menu synchronization must be validated separately.
Then have them show you, on a live store, one price change reaching every channel while you watch. Vendor capabilities differ and change over time, so if you are comparing a Toast alternative, a Square alternative or a Clover alternative, confirm current behaviour directly with each vendor rather than relying on any published comparison, including this one. This reflects publicly available information as of 2026.
Use a platform where the menu is a single record and each channel is a publishing target rather than a separate copy. Direct integrations push item, price, modifier and availability changes to connected marketplaces automatically. If your setup requires logging into each platform portal to make the same edit, you are maintaining copies, and they will drift — usually first on price and availability, which are the two fields that change most often.
Often yes. Marketplace commission takes a meaningful share of every order, so dine-in parity can turn a profitable item into a break-even one once packaging is included. Platforms permit channel pricing and most established operators use it. Set the adjustment deliberately and manage it from one place. Keep your own direct ordering channel at dine-in parity, since it carries no commission and the price gap is what encourages guests to order direct.
One action from the POS or the kitchen display should mark the item unavailable across dine-in, online ordering, kiosk, QR and connected marketplaces within seconds, with the same speed turning it back on. For prep-limited items, countdown availability that decrements with each order and pulls the item at zero is more reliable than manual 86ing during a rush, because it does not depend on anyone remembering.
Own a core menu at group level — items, recipes, modifier groups and naming — and define a short explicit list of what individual locations may override, typically price, availability and a small set of local items. That keeps corporate rollouts to a single edit, keeps reporting comparable across stores, and makes any local deviation a visible decision rather than an accumulation of quiet exceptions.