Rolling out a menu change across 50 restaurants

Most chains change the menu four to six times a year. Each change touches product, supply chain, signage, the till, marketing and training at once, and of those six the training strand quietly decides how launch week reads. Everything else can be right and the launch still shows up as complaints in week one, because at store thirty-four nobody was shown how the item is built.

This guide is written with foodservice constraints in it: a crew that turns over, rotas that never put the same people together twice, a counter that has to answer questions the moment the item goes live, and a launch date set by marketing that will not move.

Counting backwards from the first order

The window is fourteen days, counted backwards. Marketing owns the launch date and everything else is derived from it, which is a different habit from the one most operations teams have, where a project starts when the brief lands and finishes when it finishes.

Four blocks fit inside those fourteen days: head office freezes the spec, the training gets built, stores complete it, and readiness is checked with time left to act on a store that is behind. Compress any one and the compression lands on the last block, because the launch date does not move. That is why the readiness check gets skipped by exactly the chains that most need it.

Days fourteen to ten: the spec has to stop moving

In the first block, head office finalises the recipe cards, the assembly and plating standards, the allergen and nutrition information, and the till flow including any upsell prompt.

The rule is not that the work has to be good, which everyone agrees on. It is that it has to be frozen. Training built on a spec that is still being adjusted has to be rebuilt, and the rebuild consumes the block that belonged to the stores. If a supplier substitution is still open on day ten, close it or accept that the item launches with a change to push separately. The fix for late authoring is not a faster training team; it is a real day-ten freeze with a named owner.

Days ten to seven: modules a shift can finish

The second block turns the spec into training. What comes out should not be one course about the new item. It should be a small set of short modules that match the moments in a shift where they are used.

Two design points carry the weight. Keep each module to three to five minutes, because crew complete these between rushes, not in a training room. And write the questions as situations rather than recall: is the sauce on the side by default, what comes with it, can it be made without the cheese. Situations tell you afterwards what a store cannot handle. Recall questions tell you who read the card.

The allergen gate is a dependency, not a fifth module

A new item is not only a new recipe. It is a new allergen answer that whoever stands at the counter has to give correctly from the moment the item is orderable. Regulation 1169/2011 makes allergen information mandatory for non-prepacked food, and the national rules in Belgium and the Netherlands let it be given orally only by someone who can give it correctly; the allergen training guide sets out what those rules require. For a rollout, three things follow.

That last point makes it a gate rather than a module. Treat an unresolved allergen specification the way you would treat undelivered stock: the item does not go on the menu at that store.

Days seven to three: every store, on their own phones

The third block is where the training reaches people, and it works only under two conditions. First, crew can actually complete it: on a phone, in the browser, in short pieces, in the language each person reads, inside paid time. A network with a mixed crew and three rotations a day has no other route that reaches everyone. Second, the person who can act on a store being behind can see that it is behind, on the day, without asking head office for a report.

Sequence the assignment to the work rather than to the catalogue: assembly before anyone touches the item, allergens before anyone takes an order, the till before anyone rings it up. On a rota where the same person does all three in one shift that order is mostly notional, but it is exactly right for a store that phases crew in.

Days three to one: the check most chains cannot run

Three days out, someone has to look at the network and answer one question: which stores are not going to be ready.

The answer is not a network percentage. A network at ninety-something tells you nothing about whether store thirty-four is at zero, and store thirty-four is the whole problem. Read it per store and per required module, and look at who is on the first shifts after launch, because a store with the morning crew trained and the evening crew untrained looks fine on the average and fails on a Tuesday night.

Then act, with three responses ranked. A call from the area manager for a store that is close. An extra pre-shift huddle on the weak item for a store behind on one module. And for a store genuinely not ready, holding the item off that store's menu. Chains find the third unthinkable until the first time they use it; then it becomes normal, because it is cheaper than a wrong allergen answer at a site nobody checked.

Launch day and the fortnight after

On launch day, watch three things per store rather than in aggregate: remaining completions, customer complaints, and any allergen question the crew could not answer. The first is your training metric. The other two are the early signal that something did not land.

Run the fortnight after as a correction loop rather than a post-mortem. Complaints clustered at one store about assembly mean a short refresh at that store, not a network email. The same complaint at fifteen stores means the module is wrong, and the fix is to rewrite it. An allergen near miss anywhere is the one case that justifies going network-wide, as a short refresher rather than a re-run. When the recipe changes again in eight weeks, you will want to know who was trained on which version, so keep the version in the record from the start.

Getting a launch through Aristotl

The documents you produce for the launch anyway, the recipe card, the plating standard, the allergen sheet and the POS note, are the input. Aristotl drafts the short modules from them with knowledge checks written as situations, and nothing reaches a restaurant until you review and publish it. That removes the build block as the bottleneck instead of adding people to it.

Assign by restaurant, region or team with a due date the day before launch, so the kitchen and the floor each get their part. Each crew member reads it in their own language, on their own phone, and crew without a company email join with the restaurant's link or QR code. Completion and knowledge check results are viewable per restaurant and per version, side by side, which turns the day-three check into a short exercise. An allergen change after launch can go out as a must-acknowledge update, with a named receipt from every person who confirmed it and a list of who still has to.

What it does not replace: practical supervision at the pass and your own HACCP plan stay with the restaurant manager and the quality team. For a task that needs demonstrated competence, pair the module with a check signed off on the floor.

Bring the item from the launch that went wrong last year, the documents you shipped with it and the stores that struggled. In a demo we build that launch as it should have run and show what the readiness view would have looked like on day three.