One system across venues, or one per site?

Most restaurant groups do not choose to run several systems. They grow into it. The first venue chose a till and a booking system years ago. The second, bought from another owner, came with its own. The third opened when a new system looked better, so it got that one. Now the owner signs in to three tills, two booking systems and a spreadsheet to find out how the week went, and the managers cannot cover each other's shifts because they do not know each other's systems.

Running one system across venues fixes much of that. One till, one booking system, one guest list and one set of reports, with every venue in the same account, means the figures are counted the same way, staff can move between sites and a change can be made once for everyone. Moving to it takes effort, and there is one case where keeping a site separate makes sense.

This guide covers what separate systems really cost, what one system gives a group, how to move venues across and when to leave a site on its own. Every venue and figure in it is an example.

Groups end up with several systems for understandable reasons. A venue bought from another owner arrives with its own. A new venue opens when a different system is on offer. A manager prefers a system they used before. A contract on one system has years left to run.

Each decision made sense at the time. Together, they leave a group with a patchwork that costs more every year it continues.

The first cost is in reporting. Each system counts sales, covers, voids and discounts in its own way, closes its day at its own time and exports its own format. Adding them together means exporting, cleaning and combining every week, and the result is never quite comparable.

Consolidated reporting becomes a weekly chore rather than a screen you open. Our guide to consolidated reporting across four venues covers how hard it is to add venues together fairly even when the figures come from one system.

The second cost is time. Managers learn one system and cannot cover another venue without retraining. Menu changes are made separately in each system. Staff who move between sites need several logins and several sets of habits. The owner checks several dashboards to see one week.

Each of these costs a little time on its own. Across a year and a group, they add up to many days of work that one system would remove.

The third cost is in guests. A regular at one venue is a stranger at another, because their history sits in a different system. Their allergies, their preferences and their visits do not follow them, and the group cannot see its best guests across all its venues.

Marketing suffers too. Separate guest lists mean separate consent records, duplicate guests and campaigns that cannot reach the whole group's regulars at once.

The fourth cost is money. Several subscriptions, several sets of hardware, several support contracts and several integrations with accounting and payment providers each carry a cost, and few groups add them up.

Add them up once. The total, plus the hours spent combining reports and retraining staff, is the real cost of running separate systems, and it is usually higher than the cost of moving to one.

One system across venues gives a group figures counted the same way everywhere, a view of the whole group in one place, staff who can work at any venue, menus that can be shared and adapted, one record for each guest and one set of standards built into the system itself.

It also makes the group easier to grow. A new venue joins the existing system, inherits its settings and starts with the group's menus, roles and standards, rather than starting from scratch.

The till is usually the system that matters most, because it records every sale, void and payment. POS across venues, one till system for every site, means the same menu structure, the same way of recording voids and comps and the same end-of-night figures everywhere.

Each venue still needs its own floor plan, its own local dishes and prices and its own team. Our guide to POS across venues with one menu and one report covers how to set it up.

One booking system across venues lets the group see every venue's diary, offer a guest a table at a sister venue when one is full and recognise guests wherever they book. It also makes the booking pages, emails and reminders consistent across the group.

Each venue still keeps its own tables, shifts and booking rules, because each room is different. What is shared is the system and the guest records, not the detail of each diary.

One guest list is one of the biggest gains. A guest who visits two venues has one record, with their visits, preferences and allergies in one place. The group can see who its best guests are across every venue, and consent for marketing is recorded once.

It also makes data protection simpler. A guest who asks for their record, or asks to be removed, has one record to find rather than several in different systems.

One system lets the group build its standards into the software. The same staff roles and permissions at every venue, the same allergen information on every dish, the same reports and the same procedures for voids and comps are set once and apply everywhere.

Standards built into the system are far easier to keep than standards written in a document. Our guide to standardising across venues without killing character covers which standards to fix and which to leave to each venue.

Staff who work at more than one venue need one login that works wherever they are, with access to the venues they work at and no others. With separate systems, they need several logins, several PINs and several sets of habits, and covering a shift at a sister venue becomes a training exercise.

One login also keeps the records straight. Every order, void and payment is recorded against the same person wherever they worked, so their performance and their hours can be seen across the group.

One system usually means the same hardware at every venue: the same tills, card terminals, kitchen screens or printers. Spares can be shared, faults are familiar and staff who move between sites find the same equipment.

Check what each venue's existing hardware can do before the move. Some may work with the new system; some may need replacing, and the cost belongs in the plan.

Payment providers often differ between venues too, each with its own fees, settlement times and reports. Moving to one provider, where contracts allow, makes reconciling the group's takings simpler and may lower the fees.

Where a venue must keep its own provider for a while, make sure its payments are still recorded the same way in the till, so the group's figures remain comparable.

There is one good case for keeping a site on its own system: when the venue is genuinely separate from the group's way of working. A restaurant inside a hotel that must use the hotel's system, a franchise that must use its franchisor's, a concession in a stadium or airport that comes with its own till, or a venue that is about to be sold.

In those cases, the effort of moving would be wasted or impossible. Keep the site separate, take its key figures into the group's reports by hand and accept that it will always be a little different.

Some reasons for keeping a site separate are not good ones. "The manager prefers the old system." "We would have to retrain the team." "The contract has six months left." Each is a reason to plan the move carefully, not a reason to avoid it.

A manager's preference matters, and their concerns should be heard, but a group that keeps several systems to avoid a difficult conversation pays for it every week.

Plan the move venue by venue, not all at once. Start with the venue whose current system is causing the most trouble, or whose contract ends first. Learn from the first move before doing the next.

For each venue, list what needs to move: the menu, the tables and floor plan, the guest list, the staff and their roles, the booking rules and any future bookings. Set a date, plan the training and agree who is responsible for each part.

Data migration, moving information from one system to another, is the part of the move that needs the most care. Guest lists, future bookings, menus and historic sales each move differently, and some may not move at all.

Find out early what the old system can export and what the new one can import. Some data, such as guest lists, can usually be moved with a spreadsheet; other data, such as years of sales history, may need to stay in the old system's reports or in your own archive.

Guest lists need particular care when they move. Check that the list is of guests who actually visited or booked, remove duplicates, and do not assume that marketing consent recorded in the old system carries over unless it was recorded properly and can be shown.

Our guide to owning your guest data when you switch systems covers how to move guests without losing them or their trust.

Future bookings are the most time-sensitive data in the move. Guests who booked through the old system expect their table to be there. Move them carefully, check every one and keep the old system available until the last of them has passed, so nothing is lost.

Tell the team which system holds which bookings during the changeover. A host checking the wrong diary on the night of the move is the most common way for a guest's booking to go missing.

Historic sales figures rarely move neatly between systems, and they do not need to. Export the old system's key reports, by month and by venue, and keep them in your own archive, so year on year comparisons remain possible after the move.

For the first year on the new system, comparisons with last year will mean setting the new reports beside the old exports. After a year, the new system has its own history.

Train the team before the move, not on the day. A few short sessions on the new till and booking system, practising real tasks, make the first service on the new system calm rather than chaotic.

Choose a quiet day for the switch, have someone who knows the new system on hand for the first services and keep a simple guide by each till for the first weeks.

The first weeks after a move always bring small problems: a dish set up wrongly, a printer that does not print, a report that looks different. Expect them, keep a list and fix them quickly.

Review the move with the venue's manager after a month: what went well, what did not, what to do differently at the next venue. Each move should be smoother than the last.

Check the contracts on every existing system before planning the move: notice periods, end dates, early termination fees and who owns the data. A move timed to a contract's end saves money and avoids paying for two systems at once.

Where a contract has years to run, compare the cost of ending it early with the cost of running separate systems for those years. The second is often higher than it looks.

The group's accountant usually notices the difference first. Separate systems mean separate exports, different categories and figures that have to be matched by hand before the accounts can be prepared.

Agree with the accountant how the new system's figures will reach them, by venue and for the group, before the move. A format agreed once saves hours every month.

Managers are often the most attached to their venue's old system, because they know it well and it works for them. Involve them early: show them the new system, listen to what they need and let them help plan their venue's move.

A manager who helped choose and plan the move champions it with their team. One who had it imposed often finds reasons why it does not work.

One system is the foundation of good multi venue operations. Central buying, shared standards, staff who move between sites and a group-wide view of the figures all depend on the venues working in the same way, on the same system.

Our guide to multi-venue operations: what to centralise covers which functions a group should run centrally once its venues share a system.

Set up the reports the group needs on the first day each venue joins the new system: the same daily, weekly and monthly views for every venue, built the same way. A venue that joins without them becomes a venue whose figures are looked at differently.

The first month on one system is also a chance to agree the definitions: what counts as a cover, how voids are recorded, when the day closes. Agreed once, they then hold for every venue that follows.

Every month a group delays the move to one system, it pays for separate systems again: the subscriptions, the hours combining reports, the retraining and the guests it cannot recognise. The cost of waiting is rarely written down, which makes it easy to ignore.

Write it down once, as a monthly figure. Set against the one-off effort of moving, it usually shows that the move pays for itself within months.

An invented group of three venues runs three tills and two booking systems. Each Monday, the owner's assistant spends half a day combining exports into a spreadsheet, and the figures never quite match. Regulars of one venue are unknown at the others, and managers cannot cover each other's shifts.

The group moves to one system, one venue at a time, starting with the venue whose till contract ends first. Guest lists are cleaned and imported, future bookings are moved and checked, and the old systems' monthly reports are archived. Within four months, all three venues are on one system, the Monday spreadsheet has gone and a manager covers a sister venue's busy Saturday without any retraining.

servearound is built for one system across venues: a network holds every venue, each with its own floor plans, shifts, menus, prices and booking rules, staff are assigned to the venues they work in and every guest has one record across the group. The network dashboard shows revenue, covers, spend per cover and the no-show rate for all venues or one, network transactions list every venue's bills and paid orders in the network's currency, and the detailed reports cover one venue at a time, chosen with a picker.

For the move, guests can be brought in from an Excel or CSV file using servearound's template, and imported guests are not signed up to marketing emails, so consent is asked for again. Guests cannot be exported from servearound today, so keep your own archive of what you bring in. servearound is priced per venue, per month: see pricing and Analytics.

Usually, yes. It makes reporting, training, guests and standards far simpler.

Subscriptions, hardware, hours spent combining reports and retraining staff, and guests the group cannot recognise.

When it is genuinely separate: inside a hotel, run under a franchise, a concession or about to be sold.

One at a time, starting with the venue whose system causes most trouble or whose contract ends first.

Clean them, import them and ask for marketing consent again unless it can be shown.

Archive the old system's reports by month and venue for year on year comparisons.

Move and check every one, and keep the old system until the last has passed.

Before the move, with someone who knows the system on hand for the first services.

Most groups grow into several systems rather than choosing them, and the cost shows up in reporting, time, guests and money. One system across venues counts figures the same way everywhere, makes consolidated reporting a screen rather than a spreadsheet, lets staff move between sites, gives each guest one record and builds the group's standards into the software.

Move venues one at a time, plan the data migration carefully, protect future bookings, archive historic sales and train the team before the switch. Keep a site on its own only when it is genuinely separate from the group's way of working, and treat POS across venues as the foundation of multi venue operations rather than a project for later.