Menu drift: keeping price and availability in sync as you add branches
The first branch is easy. You know the menu by heart, you know when the mushrooms run low, and if a price changes you change it once. There is one screen, one truth, one you.
The second branch is where it starts. Not with a crash — with a quiet gap. A price gets edited by hand at one store and not the other. An item sells out at branch two but stays live on branch one's marketplace listing. A courier picks up an order for something the kitchen 86'd an hour ago. Nobody did anything wrong. There was just no single place that held the truth, so the truth drifted. That drift is the tax you pay for growth, and most operators pay it in refunds, one-star reviews, and evenings spent reconciling menus instead of running the floor.
What menu drift actually is
Menu drift is the slow divergence between what your menu says and what each branch and channel can actually deliver. It shows up in three places, and they compound.
Price drift: menu changes have to be updated manually at each location. Every store is its own back-office. Raise the price of a burger across the brand and you are now doing the same edit five, ten, twenty times, on five, ten, twenty screens — and the moment one is missed, two branches quote two prices for the same plate.
Availability drift: one location can run out of stock while another has too much, and neither knows. The item is 86'd in the kitchen but still selling on the app. ("86" is old floor slang for an item marked sold-out — it is still the fastest word a line cook can shout.) The order lands anyway, the runner walks it back, the guest waits, the refund gets logged.
Visibility drift: there is no real-time view of what is happening across the brand. You find out about the gap from a review, not a dashboard. By then it has been wrong for a shift.
Why it is structural, not a discipline problem
The instinct is to blame the staff. Train harder, check more, add a step to the closing routine. It never holds, because the problem is not effort — it is architecture. When every branch and every channel keeps its own copy of the menu, the number of things you have to keep identical grows with branches times channels. Three branches selling on four marketplaces plus their own web ordering is not seven menus to maintain. It is fifteen, and every price change is fifteen edits that all have to be right at the same minute.
No routine survives that math. The gap is not a sign of a sloppy team; it is the predictable output of a system where the truth lives in many places and no one place is authoritative.
Every menu change has to be updated by hand at each location — and the one you miss is the one the guest orders.
One catalog, synced everywhere it should be
The fix is to move the truth to one place. dojofood runs a single master catalog for the brand, synced to every branch and every channel. You change an item once and it propagates — to each store, to Uber Eats, Wolt, Bolt Food, Deliveroo, and to your own web ordering — everywhere it should appear.
"Everywhere it should" is the part that matters, because branches are not clones. So the catalog carries per-branch and per-channel overrides. A branch that does not run brunch hides those items locally without forking the menu. A delivery channel can carry its own price to absorb commission, set once, not re-keyed. And when the kitchen 86's an item, availability flips at that branch across every channel at once — the app stops selling what the line cannot cook. One edit in, the right change out, only where it belongs.
| Hand-edited per channel | One catalog with overrides | |
|---|---|---|
| Price change | Re-key at every store and channel | Edit once, propagates everywhere |
| Sold-out (86) item | Flip manually per app, or miss one | Flip at the branch, hides across all channels |
| Brand-wide view | Piece it together from each store | One real-time screen across branches |
| Per-branch difference | A separate forked menu to maintain | An override on the master, not a fork |
| New branch onboarding | Rebuild the menu from scratch | Clone the catalog, adjust overrides |
Onboarding drifts too
The same fragmentation shows up in how fast a branch comes online. Onboarding is inconsistent across locations — some sites onboard a server in three days, others take two weeks. That spread is the same disease wearing a different coat: when each branch is set up as its own island, the good habits live in one manager's head instead of in the system. A shared catalog turns opening a branch into cloning a known-good menu and adjusting the overrides, not rebuilding from a blank screen. The floor is trainable against one truth instead of twenty local ones.
If you are running more than one location, the question is not whether menu drift appears — it is whether your system fights it or feeds it. dojofood's multi-location management and catalog management put one master catalog behind every branch and channel, so you change the menu once and it stays true everywhere it should. Book a 20-minute walk-through and bring your worst example; we will show you where the truth would live.