Think Build Implement Repeat
London, UK +44 7367 067226
WhatsApp FOLLOW f in X
  1. Home
  2. Blog
  3. Why Does a New Menu Go Live Differently at Every One of Our Restaurants?
Problems We Solve

Why Does a New Menu Go Live Differently at Every One of Our Restaurants?

Restaurant groups launch a new menu and each site gets EPOS buttons, prices and recipe specs slightly wrong. We build one menu source that pushes to every site.

Updated 3 min readBy SpiderHunts Technologies

Free estimateNo obligation

Get a free estimate

Tell us what you need. A senior engineer reads every enquiry.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →

Quick answer — TL;DR

A menu change in a restaurant group touches the EPOS at every site, printed menus, the website, delivery platforms, recipe specs, allergen information and supplier orders. When each of those is updated by hand, sites go live with different prices, missing buttons and old specs. We build one menu record that holds the dish, price tiers, recipe and modifiers, and pushes the change to each system with a launch checklist per site.

Launch day, eight versions of one menu

The new spring menu launches on Tuesday. On Wednesday the reports start coming in. One site still has last season's risotto on the till because the button was never removed. Another has the new burger priced at the old price. Two sites have the new dessert on Deliveroo but not on the till. At the flagship, the chefs are plating the new salad from the tasting-day photo because the recipe spec card never arrived.

The development chef and the ops team spend the rest of the week ringing round, fixing things one by one. By the time every site is right, someone has already asked for a tweak to two dishes, and the cycle starts again.

One change, many places to make it

A single dish change in a group is not one edit. It is a list of edits across systems that do not talk to each other, often done by different people.

Where the menu livesWho usually updates itWhat goes wrong
EPOS at each siteOps or the EPOS providerButtons missed, old prices, wrong course
Delivery platformsMarketing or site managersItems live that the kitchen cannot make
Website and printed menusMarketing and printersDescriptions out of step with the dish
Recipe specs and allergensDevelopment chefSpecs sent by email, not filed
Supplier orderingPurchasingNew ingredients not set up at every site

Where the EPOS is centrally managed, part of this is easier, but prices often vary by site tier, some sites run a reduced menu, and delivery menus differ from dine-in. Those variations are exactly where the mistakes happen.

What an uneven rollout costs

Wrong prices on the till mean lost margin until someone notices, or guests charged differently at two sites for the same dish. Items on delivery platforms that the kitchen cannot make lead to cancelled orders and poor ratings. Chefs cooking without the spec produce a different dish at each site, which is the thing a group brand is supposed to prevent. And allergen information that lags behind the recipe is a risk the group takes seriously for good reason.

Then there is time. Development chefs and ops managers spend launch week firefighting instead of visiting sites to check the food.

How we give the menu one home

  1. We build a menu record for each dish: name, descriptions for each channel, price by site tier, course, modifiers, recipe, ingredients and the allergen information your team maintains.
  2. Each site is assigned a menu profile, such as full, reduced or delivery only, so variations are set once instead of remembered.
  3. A menu change is drafted, reviewed and given a go-live date. Nothing reaches a site until it is approved.
  4. On the go-live date, changes are pushed to each EPOS through its API or as a prepared import file for the provider, and to delivery platforms where they support menu integration.
  5. Recipe specs, with photos and plating notes, are published to a kitchen screen or tablet at each site, and the old version is withdrawn.
  6. Each site gets a launch checklist: till checked, specs read, new ingredients ordered, delivery menu checked. Head office sees which sites have signed off.

Where a system cannot be updated automatically, the tool produces the exact list of changes for that system so the person doing it is not working from memory.

A launch week that looks different

The development chef writes the dish once. Ops sets which sites get it and at what price tier. On launch morning, every site has the same buttons, the same specs and the same delivery menu, and the few sites that have not ticked their checklist are visible by lunchtime. When a tweak comes a week later, it goes through the same route and reaches every site together.

Over time, the menu record becomes the history: which dishes ran when, at which price, at which sites. That is useful for the next menu planning session.

Is this your menu launch?

  • Every launch is followed by days of fixing tills site by site.
  • Prices for the same dish differ between sites by accident.
  • Delivery menus lag behind the restaurant menu.
  • Recipe specs go out by email and nobody knows who has read them.
  • Allergen information is updated separately from the recipe.

FAQ

Frequently asked questions

The questions readers ask us after this guide.

Still have a question?

Ask us directly — a senior engineer will get back to you.

Ask about your project

Can you push changes to our EPOS automatically?

It depends on the EPOS. Many have APIs or central menu management we can write to. Where they do not, we produce a precise import or change list.

Does this handle different prices at different sites?

Yes. Price tiers and site menu profiles are part of the design, because that is where most rollout mistakes come from.

Who is responsible for allergen information?

Your team. The system keeps it attached to the recipe and flags when a recipe changes, but your own process decides what is correct.

What drives the cost?

The number of EPOS and delivery systems involved, whether they have usable APIs, and how much recipe data exists already.

What do you need from us?

Your current menus, site list with price tiers, EPOS details and your recipe specs in whatever form they exist.

Keep reading

More on Problems We Solve

Start here

Tell us how your group's sites report to head office

Describe how many sites you run, which EPOS, rota, stock and accounts systems each one uses, and which report takes the most chasing. We will say what we would connect and what we would leave alone, and if your existing tools can already do it with better setup, we will tell you that instead.

  1. You tell us what you needTwo minutes on the form, or a message on WhatsApp.
  2. A senior engineer reviews itAnd comes back with questions, a realistic range and an honest view on fit.
  3. Free 30-minute scoping callWe talk through scope, options and a realistic estimate — with no obligation.
Free estimateNo obligation

Talk to someone who builds this

Send a short brief and we will come back with an honest view and a realistic range.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →