Menu management when you run four venues

With one venue, the menu is whatever the kitchen and the owner agree it is. With four, it becomes a system. The same burger is described three different ways. One site charges a pound more for it than the others, and nobody remembers why. A dish taken off at the flagship is still on the menu at the smallest site six months later, along with an allergen note that is no longer true.

Menu management for a small group is the work of keeping four menus related without making them identical: a shared core that carries the brand, room for each kitchen and each neighbourhood, and a clear way to change things so the menus do not drift apart. This guide covers how to choose the model, set the core and the local parts, price by venue, handle the one site that must be different, and keep updating the menu manageable. Every figure in it is an example.

For a single venue, menu management is mostly about the menu itself: which dishes, at what price, described how. For a group, it adds a second layer: how the menus relate to each other, who decides what changes, and how a change reaches every site that needs it.

That second layer is where groups struggle. Each venue has its own kitchen, its own head chef and its own regulars, and each will make sensible local changes. Without a shared approach, those changes add up. After a year, four venues that opened with the same menu can have four quite different ones, with different names for the same dish, different recipes behind the same name and prices that no longer follow any logic.

None of that is anyone's fault. It is what happens when the menu has no owner at group level. The fix is a model, a process and an owner.

Menus drift for good reasons, and it helps to see them.

Each of these is a reasonable local decision. Together they mean guests who visit two of your venues meet two different versions of the brand, the kitchen teams cannot easily cover each other's shifts, and the group cannot compare how a dish sells across sites, because it is not really the same dish.

The first decision is how alike the four menus should be. There are three broad models.

Identical menus serve the same dishes at the same prices everywhere. It is the simplest to manage and the strongest for brand consistency, and it suits groups whose venues are similar in size, kitchen and audience. It struggles when one site is very different.

Related menus share a core of dishes, with room for local dishes and local prices. This is the most common model for small groups, because it keeps the brand recognisable while letting each venue suit its neighbourhood.

Independent menus treat each venue as its own restaurant, perhaps under the same owner but with its own identity. That suits groups of different concepts, and it is not really a menu management problem at all.

Most groups of four are best served by related menus, and the rest of this guide assumes that model.

The core menu is the set of dishes every venue serves, made the same way and described in the same words. It is what makes the venues recognisably one group: the dish a regular orders at any site, the dish that appears on the website and in every photograph.

Keep the core smaller than you think. A core of eight to twelve dishes, covering the main sections, is often enough to carry the brand while leaving room for each kitchen. A core that covers the whole menu is really the identical model, with all its rigidity.

Choose core dishes on evidence. The dishes that sell well at every site, that every kitchen can make well, and that say something about the brand are the natural core. Our guide to menu engineering, and the four dishes you must act on covers how to read which dishes earn their place.

Around the core, each venue can have a few dishes of its own. Local dishes let a head chef cook something they are proud of, let a site use an ingredient its suppliers do well, and give regulars a reason to visit more than one venue.

Set limits so the local part does not swallow the core. A simple rule, such as up to a third of the menu being local, keeps the balance. Ask each site to propose its local dishes to whoever owns the group menu, with a short reason, rather than adding them on its own.

Local dishes also make good tests. A dish that does well as a local dish at one site may deserve a place in the core; a dish that does badly can be dropped without touching the other venues.

Most groups have one venue that cannot follow the pattern. It might have a much smaller kitchen, a different audience such as a station or an office district, different hours, or a menu that has to meet a particular requirement, such as a fully halal kitchen or a site that serves mostly breakfast.

Do not force it into the shared menu. A smaller kitchen given the full menu will produce it badly; a breakfast-led site given a dinner menu will waste most of it. Decide deliberately which of the core dishes it serves, which it adapts, and what it serves instead.

Then treat its difference as part of the system rather than an exception. Write down its menu as a defined variation of the core, so when the core changes, everyone knows whether and how the change applies to the venue that differs.

Prices can reasonably differ between venues. Rents vary, as do wages, local competition and what guests in each neighbourhood expect to pay. A site in a busy city centre may sustain higher prices than one in a quiet suburb.

What matters is that price differences are decided, not accumulated. Set prices by venue deliberately, for example by putting each site in a price band, and review them together. A dish that costs more at one venue should do so because that venue's band is higher, not because someone raised it once and forgot.

Be thoughtful about how differences look to guests. Regulars who visit two sites will notice a different price for the same dish. A consistent band, applied across the whole menu, is easier to explain than one dish that is mysteriously dearer. Our guide to putting a menu price increase through quietly covers how to raise prices without fuss.

Brand consistency is what guests recognise across the group: the names of the dishes, the way they are described, the style of the menu, the look of the plate. It does not require every menu to be identical, but it does require the shared parts to be the same everywhere.

Keep one master description for each core dish, and use it at every site. Keep the menu's design consistent, even where the dishes differ: the same typefaces, section names and structure. Photograph core dishes once, as they should look, and use those photographs everywhere.

Local dishes can follow the same style without being the same dishes. A guest should be able to pick up the menu at any of your venues and know which group it belongs to, even if a third of the dishes are new to them. Wikipedia's overview of brand management gives the broader principles.

A shared dish is only shared if it is made the same way. For each core dish, keep a specification: the recipe, the portion, the plating and a photograph of how it should look. Every kitchen works from the same spec, and changes to the spec go through the menu owner.

Specs matter for more than consistency. They let a chef cover a shift at another site without learning a new version of every dish. They make costing comparable across venues. And they make allergen information reliable, because the same dish has the same ingredients everywhere.

Train each kitchen on new core dishes together, or at least from the same material, and check plates now and then against the photograph. A dish that drifts at one site is far easier to correct in its first month than after a year.

Updating the menu is where a group's menu management is tested most often. A price rises, a dish is improved, a supplier changes, a seasonal dish arrives. Each change has to reach every venue it applies to, at the right time, on every version of the menu.

A simple process helps:

Batch changes where you can. A menu that changes a little every week across four sites is hard to keep straight; one that changes on a known date each month or each season is far easier. Our guide to updating the menu in one place, not five covers the single-venue version of the same problem.

Allergen information is where menu drift becomes dangerous. If a core dish changes at one site because a supplier's sauce now contains a different allergen, the allergen marks at that site must change too, and the other sites must know that their version is different.

Make allergen accuracy part of the process. Every change to a dish's ingredients, at any site, triggers a check of its allergen information. Substitutions, such as a different bread from a different supplier, count as changes. The team at each site should know where the current information is and who to ask.

For core dishes, aim for the same ingredients and the same allergens everywhere. Where a site must differ, say so clearly on that site's menu and in its records, so a guest with an allergy gets the right answer at the venue they are in.

Seasonal dishes and limited specials add life to a group's menus, but they also add work. Decide whether each one runs at every venue, at some, or at one.

Group-wide seasonal dishes are good for marketing: one dish, one photograph, one message across every site. They need careful planning, because every kitchen has to source, prepare and train for them at the same time. Site-specific specials are easier to run and give each kitchen some freedom, but they are harder to promote as a group.

A common balance is a small group-wide seasonal change a few times a year, with each site free to run its own weekly specials within the menu's style. Write down which is which, so a special at one site is not mistaken for a group dish.

A group has an advantage a single venue lacks: it can test a dish in one place before rolling it out. Put a new dish on the menu at one site as a local dish, watch how it sells and how the kitchen copes, and decide whether it deserves a place in the core.

Choose the test site carefully. The flagship may sell anything; the smallest site may struggle with anything new. A site that is typical of the group gives the most useful answer.

Give the test a fixed length, perhaps four to six weeks, and decide in advance what success looks like: how often it sells, what guests say, how the kitchen copes at the busiest time. Then decide, and either roll it out with a proper spec or take it off without regret.

The menu mix, the share of sales each dish takes, is one of the most useful things a group can compare. When the same dish sells very differently at different sites, the difference is worth understanding.

Look at the mix for each venue side by side. A core dish that leads at three sites and trails at the fourth may be made differently there, priced differently, placed differently on the menu or simply less suited to that neighbourhood. A local dish that outsells the core dishes at its site may deserve a wider audience.

Use the same date ranges and the same categories at every site, so the comparison is fair. Our guide to menu mix: what your guests order, not what you sell covers how to read it.

Sometimes a dish simply suits one venue better. A rich dish that sells well in a destination restaurant may sell poorly at a lunchtime site near offices. That is not a failure of the dish; it is information about the venues.

Before dropping a core dish at one site, check the obvious causes. Is it made to the spec? Is it priced in line with the venue's band? Is it placed well on the menu? Do the servers recommend it? If all of those are in order and it still does not sell, it may belong in that venue's variation rather than its core.

Keep these decisions visible. A core dish dropped at one site should be recorded as part of that site's variation, so it is not accidentally restored at the next menu change, and so the group knows its core is really served in three venues, not four.

Menu management needs an owner. In a small group, that is often a head chef for the group, an operations manager or the owner, working with each venue's head chef. Without one, every change is decided locally, and drift is inevitable.

The owner's job is not to make every decision. It is to keep the core, the local parts and the variations clear, to agree changes with the site chefs, and to make sure every change reaches every menu. Good multi-venue operations depend on that kind of clarity in every area, from purchasing to staffing, and our guide to multi-venue operations, and what to centralise covers the wider picture.

Meet regularly. A short monthly menu meeting between the owner and the site chefs, looking at sales, feedback and proposed changes, keeps the menus related and gives each kitchen a voice.

Each venue has several versions of its menu: printed menus, specials cards, boards, the website and the menu on guests' phones. Across four sites, that can be twenty versions of the menu to keep in step.

The answer is one source of content for each venue, from which the other versions are produced. Printed menus, the website and the phone menu should all come from the same dishes and prices, so a change made once appears everywhere. For the group, the core dishes' names, descriptions and photographs should be the same at every site.

Check regularly. Once a month, open each venue's website and phone menu and compare them with the printed menu on the table. Out-of-date prices online are one of the most common complaints a guest makes, and one of the easiest to prevent.

An invented group runs four venues: a flagship in the city centre, two neighbourhood sites and a small site at a railway station with a compact kitchen. They opened with the same menu, but three years later each has drifted: different descriptions, prices that follow no pattern, and a station menu that tries to serve everything the flagship does.

The group sets a core of ten dishes, served everywhere to one spec, with one description and one photograph each. Each neighbourhood site may add up to five local dishes; the flagship up to eight. The station site gets a defined variation: six of the core dishes, adapted for its kitchen, and a breakfast section of its own. Prices move into two bands, city and neighbourhood, with the station in the city band.

Changes now go through a monthly meeting and are made on a set date. Within a season, the menus are recognisably one group again, the station's kitchen copes far better, and the group can compare how its core dishes sell at each site.

In servearound, a menu built at one venue can be copied to any of the network's other venues with Copy to Venues. Its categories, dishes, photos, tags, modifier groups and set menus travel together, and the copy arrives switched off, so nothing changes at the other venue until someone turns it on. From then on, each venue's menu is its own: local prices and local dishes are set there, and a change at one venue does not reach the others, so a group-wide change is made at each site.

Within a venue, one dish can sit on several menus without being copied, with a different price on each if needed, and prices can be changed in bulk by a percentage or an amount. Marking a dish sold out on the till shows it as sold out on every guest menu at once. Menu analytics show each venue's sales by dish and by category, with units, checks, revenue and share of sales for every dish that sold, and a network dashboard shows the group at a glance. See the menus module and pricing.

Only if they are very alike in size, kitchen and audience. Most small groups do better with a shared core and room for local dishes and prices.

Big enough to carry the brand, small enough to leave room for each kitchen. Eight to twelve dishes across the main sections is a common starting point.

Yes, if the difference is decided. Put venues in price bands and apply each band consistently, rather than letting individual prices drift.

Give it a defined variation of the core: which dishes it serves, which it adapts and what it serves instead, written down as part of the system.

A group head chef, an operations manager or the owner, working with the site chefs, with a regular meeting to agree changes.

Check a dish's allergens every time its ingredients change at any site, including supplier substitutions, and record where a site's version differs.

Decide them centrally, write them down, change the master first, then every version at each site on a set date, and have each venue confirm.

Run it as a local dish at one typical site for a fixed number of weeks, decide in advance what success looks like, then roll it out or drop it.

Differences in how the same dish sells point to differences in recipe, price, placement or audience, which are worth understanding before changing anything.

Menu management for a group of four is the work of keeping menus related without making them identical. Choose the model first: for most small groups, a shared core of dishes made to one spec and described in one voice, with room for local dishes and deliberately banded local prices. Give the venue that must differ a defined variation rather than forcing it into the shared menu.

Give the menu an owner, meet monthly with the site chefs, and make changes on set dates through one process that updates every version of the menu at every site. Check allergens whenever ingredients change, test new dishes at one typical site first, and compare the menu mix venue by venue to learn what each neighbourhood really wants.