POS across venues with one menu and one report

The second venue opens, and the owner copies everything from the first: the same menu, the same prices, the same till layout. Six months later, the two have drifted apart. The new venue has added dishes for its lunchtime office crowd, changed some prices and renamed a category. Comparing the two means exporting reports from each, matching dish names by hand and hoping the definitions are the same.

Running a POS across venues is a balance between consistency and freedom. Standardise too little, and the group cannot compare its venues, share improvements or control its brand. Standardise too much, and each venue loses the ability to serve its own guests well.

This guide covers what to standardise across venues, what each venue should keep for itself, how to manage menus across sites, how to make reports comparable, and what to look for in a system that runs several venues. Every venue and figure in it is an example.

Venues drift apart for good reasons and bad ones. Good reasons: different guests, different neighbourhoods, different kitchens and different trading patterns. A city-centre site at lunch and a suburban one in the evening should not be identical.

Bad reasons: changes made in a hurry by whoever was on shift, dishes renamed for no reason, categories reorganised by a new manager, prices changed without anyone at the centre knowing. Those changes make the group harder to run without making any venue better.

The aim is not to stop all differences. It is to decide which differences are allowed, and to make sure the rest stay the same.

Some things should be the same in every venue of a group. The core menu, with the same dish names, descriptions and allergen information. The categories the menu is organised into, so reports group the same things together. The definitions behind the figures, such as what counts as a cover. The till's basic layout, so staff can move between venues. And the rules for voids, comps and discounts.

Standardising those makes the group comparable, makes training transferable and protects the brand. Our guide to multi venue operations: what to centralise covers the wider question beyond the point of sale.

Other things should stay with each venue. Its own prices, where costs and markets differ. Its own specials and local dishes, where guests differ. Its own table plan, staff and opening hours. Its own decisions on the night: what to 86, when to fire a course, how to handle a complaint.

A venue manager who cannot change anything becomes a caretaker. One who can change everything becomes a separate business. The balance lies in a shared core with room for each venue to serve its own guests.

Menu management is where multi venue operations most often go wrong. There are two main approaches. In the first, one menu is managed centrally and pushed to every venue, with each venue able to change only certain things, such as prices or availability. In the second, a menu is created once and copied to each venue, after which each venue's copy is its own.

The first keeps venues consistent automatically but needs a system and a team built for it. The second gives each venue freedom but needs discipline, because changes at one venue do not reach the others unless someone makes them.

Our guide to menu management when you run four venues covers both approaches in detail.

Whatever approach you choose, keep dish names and categories consistent across venues. A dish called "Chicken burger" at one venue and "Buttermilk chicken bun" at another is the same dish to the kitchen but two different dishes to the reports.

Agree a naming convention, write it down and check new dishes against it. When a venue adds a local dish, it should follow the same pattern, so the reports can still group it sensibly.

Consistent categories matter just as much. If starters are called "Small plates" in one venue and "To start" in another, comparing starter sales across the group becomes a manual job.

Prices are one of the things many groups allow to differ. Rents, wages and guests' expectations vary by location, and a single price list for every site can leave some venues underpriced and others too expensive for their area.

If prices differ, record the reason and review it regularly. Check that each venue's margins are healthy at its own prices, and that price differences do not confuse guests who visit more than one venue.

If prices must be the same, for brand reasons or because guests expect it, change them everywhere at once.

Allergen information must be correct at every venue, and it is one place where consistency is a matter of safety. If the same dish is made the same way everywhere, its allergen information should be identical everywhere.

When a venue changes a recipe, a supplier or an ingredient, the allergen information for that venue's dish must change too, and the change should be reviewed centrally to check whether it applies elsewhere. A local substitution that adds an allergen at one site, and is missed on the menu, is a serious risk.

In many groups, staff move between venues: a server covering a shift at the sister site, a manager overseeing two venues, a chef helping at a new opening. A consistent till makes that easy; a different layout at every venue makes it slow and error-prone.

Make sure staff can sign in at every venue they work at, with the right role for each. Remove access when they stop working at a venue.

Kitchens differ between venues more than dining rooms do. One site has a pizza oven, another a grill, a third a tiny kitchen with two stations. The same dish may be cooked at a different station in each, and the till must send it to the right one at each venue.

Set up each venue's stations to match its own kitchen, and check that every dish on the shared menu goes to the right station at every site. A dish sent to a station that does not exist at one venue, or to the wrong cook, is a ticket that never gets made.

Venues in a group often share suppliers, but not always. A site in a different city may buy from local suppliers at different prices, which changes its costs and margins on the same dish.

Keep track of where each venue buys its key ingredients, and how its costs compare with the others. Where prices differ greatly, ask whether the group can buy together, or whether the difference justifies a different menu price at that venue.

Training should be the same at every venue: the same till, the same routines, the same standards for taking and sending orders. A server trained at one site should be able to work a shift at another without relearning anything but the room.

Keep a single training guide for the group, with a short section for each venue's own differences, and train new managers on the group's reports and standards as well as their own venue's.

Guests who visit more than one venue in a group are often its most valuable. A guest record shared across venues lets each one recognise them, see their allergies and preferences, and treat them as a regular rather than a stranger.

Check how your system handles guests across venues, and agree with each venue what may be recorded and how it is used, in line with the privacy rules where you trade. A guest who tells one venue about an allergy should not have to repeat it at the next.

Consolidated reporting brings every venue's figures together, so the group can see its total and compare its venues. At its simplest, it shows each venue's sales, covers and average spend side by side, for the same dates, using the same definitions.

Without it, the group's figures come from exporting each venue's reports and combining them by hand, usually in a spreadsheet, usually a week late. With it, the owner can see the whole group each morning.

Decide which figures you need across the group: usually sales, covers, average spend, labour and food costs, and a few service measures. Then make sure each venue records them the same way.

Figures can only be compared if they mean the same thing everywhere. What counts as a cover: every guest, or only those who ordered food? Is a staff meal a comp or a discount? Is a service charge part of sales? Are takings counted when the check closes or when the payment is made?

Agree the definitions for the whole group, write them down and set up every venue the same way. A group whose venues count covers differently is comparing numbers, not performance.

Venues in a group rarely trade at the same times. A city site may be busiest at lunch on weekdays, a suburban one on weekend evenings. Comparing them on total sales for the same week misses that.

Compare each venue at its own busy times, and look at sales per open hour as well as totals. That shows which venues use their hours well, and where hours could be shortened or extended.

Comparing venues fairly is harder than it looks. A large city site will always outsell a small neighbourhood one; a venue open seven days will always outsell one open five. Raw totals reward size, not performance.

Compare like with like: sales per cover, spend per head, sales per open hour, the share of covers that came back. Compare each venue with its own past as well as with the others: a small venue growing steadily may be doing better than a large one standing still.

Explain the differences you find before acting on them. A venue with lower spend per head may serve a lunch crowd with a different budget, not be failing.

Groups that operate in more than one country, or across time zones, need care with currency and time. Figures in different currencies must be converted before they can be added together, at a rate that is stated and consistent. Days must be counted on each venue's own clock, so a late night in one city is not split across two days in the report.

Check how your system handles both, and make sure the group's reports say which rate and which clock they use.

A cloud POS is usually the simplest way to run several venues, because every venue's data lives in one place and can be reached from anywhere. An owner can see each venue's figures from a phone; a central team can manage menus and staff without visiting each site.

The same risks apply as for any cloud system: each venue needs a reliable connection and a plan for outages. Our guide to cloud POS: what it fixes and what it risks covers them.

Changes that affect every venue, such as a new menu, a price change or a new till layout, need planning. Decide the date, tell every venue in advance, train the staff who need it and check each venue on the day.

Roll out larger changes in one venue first, learn from it, then roll out to the rest. A new menu that confuses the kitchen at one site is easier to fix before it has confused six.

Local specials keep each venue lively and give its chef a voice. Allow them within limits: a set number of local dishes, following the group's naming convention, with allergen information checked to the same standard as the core menu.

Review local specials each month. A special that sells well at one venue may deserve a place on the core menu; one that never sells should make way for another idea. That way, local freedom feeds the whole group.

Standards that live in one person's head do not survive a second venue, let alone a fifth. Write them down: the naming convention, the categories, the void and comp rules, the opening and closing routines, the way a check is split. A simple written standard operating procedure for each lets every venue work the same way.

Keep them short and practical, and review them when something changes. A standard that nobody reads is no standard at all.

A new venue is the moment to get consistency right. Copy the core menu, categories and settings from an existing venue, then make the local changes deliberately: prices, specials, the table plan, staff and hours.

Check everything before opening: dish names, allergens, stations, prices and the till layout. Train the team on the group's standards as well as the till. A venue that opens consistent stays consistent far more easily than one that has to be brought back into line later.

Once a month, review the whole group. Compare each venue's key figures with its own past and with the others, using fair measures. Check that menus have not drifted: dish names, categories and allergens. Check the voids, comps and discounts at each venue against the group's rules.

Share what works. A dessert that lifted spend at one venue, a change to the rota that saved hours at another or a better way of handling walk-ins can often be repeated across the group.

Some venues should be different. An airport site, a hotel restaurant or a venue in a holiday resort trades in its own way: different hours, different guests, different peaks. Forcing it into the group's standard pattern can do more harm than good.

Decide deliberately which venues need a different setup, and write down why. A venue that is different by design is easy to manage; one that drifts away from the standard without anyone deciding is the problem.

An invented group runs three bistros. Each venue manages its own menu, and over two years dish names, categories and prices have drifted. The owner spends a day each month combining reports in a spreadsheet, and still cannot compare dessert sales across the three.

The group agrees a core menu with shared names, categories and allergen information, and lets each venue set its own prices and add up to four local dishes. It writes down its naming rules and its void and comp policy, and reviews menus monthly for drift. Each venue's figures are compared using spend per cover and sales per open hour.

Within three months, the monthly reporting day shrinks to an hour, the owner can see which venue sells the most desserts and why, and a successful dessert from one site is added to the core menu for all three.

In servearound, several venues sit under one business. The network dashboard shows revenue, covers, spend per cover and the no-show rate for all venues or for one, each against the previous period, and the network's transactions list every venue's bills and paid orders, with the venue, the method and who took each one, totalled in the network's currency at each day's rate. The detailed reports, from payments and orders to the menu report and kitchen analytics, cover one venue at a time, chosen from a picker, so comparing two venues in detail means reading each one for the same dates.

A menu built at one venue can be copied to the others with its dishes, photographs, options and set menus. Each copy arrives switched off, and from then on it belongs to that venue, so later changes at one venue do not reach the others. Each venue keeps its own floor plan and point of sale. See Analytics and pricing.

The core menu's names, descriptions and allergens, the categories, the definitions behind the figures, the till's basic layout and the rules for voids and comps.

Its own prices where markets differ, its specials, table plan, staff, hours and decisions on the night.

Either one central menu pushed to every venue, or one menu copied to each venue and kept in step by discipline.

Every venue's figures brought together for the same dates and definitions, so the group sees its total and compares its venues.

Use measures like spend per cover and sales per open hour, and compare each venue with its own past.

Usually, because every venue's data lives in one place, as long as each venue has a reliable connection.

Plan it, tell every venue, train the staff, and try larger changes in one venue first.

Monthly: key figures, menu drift, and voids, comps and discounts against the group's rules.

Running a POS across venues means deciding what stays the same and what each venue keeps. Standardise the core menu, names, categories, allergens, definitions, till layout and rules; let each venue keep its prices, specials, table plan, staff and decisions on the night.

Keep dish names and categories consistent so reports can be compared, compare venues by fair measures rather than raw totals, handle currencies and clocks with care, write your standards down, roll out big changes one venue at a time, and review the whole group every month.