Changing the menu: a calendar, not a crisis

In many kitchens, a new menu arrives the same way every time. The date is set, then nothing much happens for weeks. Ten days before launch, the dishes are still being argued about. Five days before, someone realises the printer needs a week. Two days before, the costings show two dishes losing money. On the day, servers are learning dishes they have never tasted, the old stock is still in the fridge, and the website shows last season's menu.

Changing the menu does not have to be like that. The work involved is the same every time, and it can be laid out on a calendar and planned backwards from the launch day, so each step happens when it should. This guide sets out four changes a year, each planned week by week from ten weeks out to the first fortnight after launch. Every figure in it is an example, and the weeks will stretch or shrink to suit your venue.

Menu changes become crises for predictable reasons. The decisions are left late, because they feel creative and can always wait. The practical steps, such as costing, ordering, printing and training, all depend on those decisions, so they are squeezed into the last few days. And nobody owns the whole process, so the gaps between steps are nobody's job.

The result is a launch where some things are done badly and others not at all. Dishes go on the menu without being costed. Servers describe dishes they have not tasted. Allergen information lags behind recipes. The printed menu, the website and the till disagree.

None of this is about effort. Teams in a crisis work hard. It is about sequence: the steps happen in the wrong order, too close together. A calendar fixes the sequence.

Most venues that change their menu with the seasons do so about four times a year. Others change twice a year, or run a fixed core menu with smaller changes more often. Choose the rhythm that suits your kitchen and your guests, then fix the dates.

Pick launch dates that make sense for your trade. A change just before your busiest season gives the team no time to settle; a change in a quieter week, a little before the season turns, lets the kitchen learn the new dishes before the rush. Our guide to seasonal trade, mapping your own restaurant year covers how to find those quieter weeks.

Put the four launch dates in the diary at the start of the year. Every other date in this guide is counted back from them, so a launch date that keeps moving drags the whole calendar with it.

The principle of the calendar is simple: start from the launch day and work backwards. Each step has a lead time, the time it needs before the next step can begin, and some steps cannot start until others are finished. A printed menu cannot be proofed until the dishes, prices and descriptions are final; training cannot happen until the dishes are tested.

Laying the steps out against the weeks before launch shows what must happen when. It is the same idea as a Gantt chart, used in many industries to plan work that depends on other work, though a simple list of weeks is usually enough for a menu.

The calendar below uses ten weeks. A small café with a short menu might compress it to six; a group changing menus across several sites might need twelve. The order matters more than the exact weeks.

Ten weeks before launch, decide what the new menu will be, in outline. Which dishes stay, which go, and roughly what comes in?

Start from evidence. Look at the current menu's sales by dish, the dishes that earn well and those that do not, and any dishes that cause problems in the kitchen. A menu audit, done a week or two earlier, gives a clear picture; our guide to a menu audit you can run in an afternoon covers how. Note any dish you plan to remove and why, because removing a dish from the menu needs more care than adding one.

The outcome of this week is a short list: the dishes staying, the dishes going and the gaps the new dishes must fill, such as a new vegetarian main or a lighter starter.

Eight weeks out, the kitchen develops the new dishes. The head chef and the team work on recipes, cook them, adjust them and agree portions and plating.

Cost every new dish as soon as its recipe is stable, using the prices you expect to pay during the season it will run, not the price of a test batch. A dish that looks profitable at today's prices may not be when its main ingredient's price rises later in the season.

Price the dishes at the same time, with the whole menu in view, so the new dishes sit sensibly next to the ones that stay. If a dish cannot be priced to earn its place, change it now, while there is time, rather than discovering the problem on the day.

Six weeks out, test the new dishes in real conditions. Menu testing means more than cooking a dish once in a quiet afternoon. It means cooking it as it will be cooked on a busy night, by the cooks who will cook it, at the station it will come from.

Run the new dishes as specials during normal services. Watch how long they take, how they hold, whether the station copes and what guests say. Ask servers which questions guests ask about them. A dish that looks wonderful in the afternoon and takes eleven minutes at the peak needs changing before it goes on the menu.

Adjust and test again where needed. By the end of this stage, every new dish should be one the kitchen has cooked under pressure and is confident it can deliver every time.

Five weeks out, turn to supply. Tell suppliers about the new ingredients, agree prices and delivery days, and find out about lead times for anything unusual. Some specialist ingredients take weeks to arrive the first time.

Plan the stock change. List the ingredients that only the outgoing dishes use, and set a date to stop ordering them, so they run down rather than being thrown away. List the ingredients the new dishes need, and set the date of the first order so they arrive in time for the last tests and the launch.

Do the same for equipment and packaging. A new dish may need a particular dish, bowl or tool, and these are easy to forget until the day they are needed.

Four weeks out, write everything guests will read. Final dish names, descriptions, prices and any supplements. Dietary labels for each dish, checked against the full recipe.

Update the allergen information for every new and changed dish, from the recipes as they will be served, including sauces, garnishes and sides. Remove the dishes that are leaving from the allergen record, and check that any dish staying on the menu has not changed in a way that affects its allergens.

This is the point at which the menu's content is fixed. Changes after this date ripple into print, digital and training, so make them only when they are necessary, and make sure every later step hears about them.

Three weeks out, produce the menus. Prepare the printed menu from the final content, check a proof on the paper you will use, and send it to print with enough time for delivery. Our guide to menu templates and where they let you down covers the pitfalls of laying out a new menu.

Prepare the digital versions at the same time: the menu on the website, the menu guests open from a QR code, any boards and any delivery platforms. Prepare them, but do not put them live until launch day, so guests do not see dishes that are not yet available.

Prepare the till too. The new dishes, prices and options need to be set up so servers can order them, and the dishes that are leaving need to come off on the right day. Our guide to updating the menu in one place, not five covers how to keep these versions in step.

Two weeks out, train the team. Every cook who will make a new dish should make it, from the recipe and the photograph, until they are confident. Every server should taste every new dish, hear from the chef what makes it good and learn its allergens.

Give servers the words. A short description of each new dish, what guests are likely to ask and which dishes are worth recommending help them sell the menu from the first night. Prepare an answer for the question regulars will ask about any favourite that is leaving.

Brief the managers too. They need to know what is changing, why, and what to do if something goes wrong on launch day.

In the last week before launch, run down the old menu. Stop ordering ingredients that only outgoing dishes use, use up what remains in specials and staff meals, and plan the last order of the old menu so the fridge is clear for the new one.

Check everything is ready. The printed menus have arrived and are correct. The digital versions are prepared and checked. The till is set up. The first deliveries for the new dishes are booked. The allergen guide is updated and ready to swap in.

Hold a short final run-through with the kitchen and floor leads. Walk through launch day: who switches the digital menus, who swaps the printed menus, who briefs each shift. A twenty-minute meeting now saves an hour of confusion on the day.

On launch day, switch everything at once. The printed menus go on the tables, the website and the QR menu change, boards update, the till offers the new dishes, delivery platforms change, and the new allergen guide replaces the old one.

Brief every shift before service: the new dishes, what is good tonight, which dishes the kitchen wants to sell, and any dish that is not yet available because an ingredient has not arrived. Keep the briefing short and specific.

Watch the first service closely. The head chef and a floor manager should keep an eye on ticket times, dishes sent back and questions from guests, and be ready to make small changes quickly: a garnish simplified, a description clarified, a dish taken off for the night if it is not working.

The first two weeks of a new menu show what works and what does not. Look at how each new dish sells, how long it takes in the kitchen, what guests say and what servers hear. Check the waste, especially for new ingredients whose usage the kitchen is still learning.

Make small adjustments where needed: a portion trimmed, a price changed, a description rewritten, a dish moved to a better place on the menu. Keep changes to the printed menu to a minimum, because reprinting is costly, but use the digital menus and the team's words to fix what can be fixed.

At the end of the fortnight, hold a short review. What went well? What would you do differently next time? Write it down, because the next change is only three months away.

Not every change needs the full calendar. Between the main changes, smaller adjustments happen: a dish swapped when an ingredient goes out of season, a price changed when a supplier's price rises, a special promoted to the menu.

Give these a lighter version of the same process. Cost the change, test the dish if it is new, update the allergen information, change every version of the menu together and tell the team. A small change done carefully takes a day or two; done carelessly, it creates exactly the disagreements between channels that the calendar was meant to prevent.

Keep a limit on mid-season changes. If the menu is changing every week, it is no longer a seasonal menu but a rolling one, and the team needs a different rhythm to keep up.

The calendar needs an owner. In a small venue, it is often the head chef or the general manager; in a group, someone responsible for menus across the sites. The owner does not do every step, but makes sure each one happens on time and that everyone knows what is coming.

The owner's main job is to protect the sequence. When a decision is late, the owner makes sure it is made, or moves the launch date rather than squeezing the later steps. When a change is made after the content is fixed, the owner makes sure print, digital, allergens and training all hear about it.

Share the calendar with everyone involved: the kitchen, the floor, whoever orders stock and whoever manages the website. A calendar that lives in one person's head is not a calendar.

Here is the whole calendar in one list, counted back from launch day:

Copy it into your own diary with real dates for each of your four launches.

An invented bistro changes its menu four times a year, and every change has gone the same way: late decisions, a rush to print, servers learning dishes on the night, and a website still showing the old menu a week after launch. The team dreads each change.

For its autumn menu, the bistro sets the launch date ten weeks ahead and puts every step of the calendar in the diary, with the head chef as owner. Dishes are decided in week ten, costed in week eight and tested as specials in week six, when one new main proves too slow and is simplified. The printed menu is proofed in week three and arrives a week early. Every server tastes every dish in week two.

On launch day, the menus, the website, the QR menu and the till all change by eleven in the morning. The first service runs smoothly, waste in the first fortnight is lower than at any previous change, and the review notes only two small things to do differently in winter.

In servearound, a new menu can be built in advance and scheduled to start on its launch date, with the outgoing menu set to end the day before, because only one menu runs at a time; it can also be kept switched off until the day. Dishes staying on from the old menu can sit on the new one without being copied, so their descriptions, photos and prices are edited once. On the day, the menu guests open from a table's QR code and the venue's menu page change with the schedule, and digital menu boards set to the live menu follow.

Print designs start from your own menu, say when a dish has been added, removed, renamed or repriced since they were printed, and keep each published version, so the printed menu can be produced and checked weeks ahead. Allergen and dietary tags sit on each dish, and after launch the menu report shows how each new dish sells, with how often guests looked at it against how often they ordered it. See the menus module.

Many venues change about four times a year, with the seasons. Others change twice a year or run a fixed core with smaller changes. Pick a rhythm and fix the dates.

About ten weeks for a typical venue, counted back from the launch date. A short café menu may need six; a group may need twelve.

Cooking the new dishes in real services, as specials, by the cooks who will make them, to see how they sell, how long they take and how the station copes.

As soon as their recipes are stable, at the prices you expect during the season they will run, and before prices and print are fixed.

Stop ordering ingredients that only outgoing dishes use in the final weeks, and use up what remains in specials and staff meals.

On launch day, at the same time as the printed menu and the till. Prepare it in advance, but do not put it live early.

Every cook makes each new dish from the recipe, and every server tastes every dish and learns its description and allergens, about two weeks before launch.

Use a lighter version of the same process: cost, test, update allergens, change every version of the menu together and tell the team.

One person, usually the head chef or general manager, whose job is to keep each step on time and make sure every part of the venue hears about changes.

Changing the menu becomes a crisis when decisions are left late and every practical step is squeezed into the last few days. Fix four launch dates a year and plan each one backwards: decide what changes ten weeks out, develop and cost at eight, run menu testing in real services at six, sort suppliers and stock at five, fix copy, prices and allergens at four, prepare print and digital at three and train the team at two.

In the last week, run down the old stock and check everything; on launch day, switch every version of the menu at once and brief every shift; in the first fortnight, watch, adjust and review. Give the calendar one owner, share it with everyone, and handle mid-season changes with a lighter version of the same sequence.