Scheduling a menu change

A menu change is rarely something you want to happen now. It is something you want to happen on Tuesday, at every location, without anyone remembering to press a button at 6am.

That is what dating a version does.

Creating the next version

New version on a menu’s Manage screen opens four fields:

• Label — what you will call it. Fall 2026, Q4, Summer LTO.
• Starts — the date it takes over.
• Ends (optional) — leave it blank and it runs until something replaces it. A version with no end date shows as 2026-08-17 → open.
• Copy items from — Empty, or any existing version.

Then Add version.

Copy items from is the field to notice

Building a seasonal menu from Empty means re-adding every dish that is not changing — which is most of them, and every one is a chance to leave something out.

Copy the current version and edit the difference. Remove the four dishes coming off, add the three going on, and the eighty that stay are simply already there.

Nothing you do to a future version touches service

This is the whole point of versions. The live version is what the line reads; a dated version sitting in front of it is invisible to them until its start date arrives.

So you can build next season over three weeks, in daylight, with people reviewing it — rather than editing the live menu at midnight and hoping.

What happens at the changeover

At the start date, locations following the schedule move to the new version. There is nothing to press.

Two things that do not happen automatically, and both matter:

• A location with a pinned version does not move. A pin overrides the schedule and does not expire, so a store pinned months ago for one good reason will sit out every changeover since. Check your pins before a seasonal change — see What each store serves.
• Acknowledgment does not carry over. Recipes that changed will re-prompt the line, and your coverage will dip at the changeover. That is correct, and it is how you can tell whether the new menu was actually read. See Revisions and history.

Editing, archiving, deleting

Each version row carries Edit (label and dates), Archive, and Delete.

Archive anything that was ever live. It keeps the record of what was being served on a given date, which is the question you will actually be asked later. Delete is for a version built by mistake and never served.

Scheduled versions are visible on the dashboard

Your dashboard’s Scheduled to activate section lists versions with a future start date, and reads “Nothing scheduled ahead” when there are none — so a change you set up six weeks ago is not a thing you have to remember. See Your dashboard.

A practical sequence for a seasonal change

1. New version, labelled and dated, copying items from the current one.
2. Edit the difference — remove what is coming off, add what is going on.
3. Publish any genuinely new recipes so they can be added. Only published recipes can go on a menu.
4. Check store pins and menu access, especially for locations added since the last change.
5. Leave it. It takes over on the date.