One bundle vs separate systems for a venue

One bundle vs separate systems is easiest to understand through an ordinary day. Picture a venue with four separate tools: a booking app, a till, a kitchen screen system and an email tool. Each is good at its job. Each was chosen carefully. They are connected by integrations that pass some information between them. On most days, they almost talk to each other. The trouble is in the word almost.

Now picture the same venue with one bundle: a single system that takes bookings, runs the till and the kitchen screens, keeps the guest records and sends the emails. It may not have every specialist feature of the four separate tools, but every part knows what the others know. A booking, a table, an order and a check are the same guest.

This guide follows both venues through one Friday, from the morning to the cash-up, and then compares them on cost, time and failure. It covers where integrations help and where they leave gaps, what the restaurant software stack really costs once the hours are counted, and when separate systems are still the right choice.

Both venues are the same: 80 seats, busy weekends, a menu that changes monthly, a team of twenty. Venue A runs four separate systems: a booking app with its own guest list, a till with its own menu and reports, a kitchen screen system connected to the till, and an email tool fed by a weekly export of guests.

Venue B runs one bundle covering bookings, the till, the kitchen, guests, email and reports. Both use the accountant's software for the books and a spreadsheet for the rota.

On Friday morning, the chef changes two dishes and a price. At Venue A, the manager updates the till, then the kitchen screen routing, then the menu on the booking app's guest page, then the menu linked from the email tool. Four places, about forty minutes, and one of them is missed: the booking page still shows the old dish.

At Venue B, the manager updates the dish once. The till, the kitchen screens, the guest menu and any email link all show the change. About ten minutes.

At 15:00, a guest books for eight at 19:30 and notes a severe sesame allergy. At Venue A, the allergy sits in the booking app. The integration passes the booking to the till as a table reservation but not the note. The host prints the evening's bookings and highlights the allergy by hand, and the server will need to remember to add it to the order.

At Venue B, the allergy is saved to the guest's profile and flagged on the booking. When the table is opened, the allergy is on the check, and when the order is sent, it appears on the kitchen ticket. Nobody needs to copy anything.

At 19:30, the room fills. At Venue A, a walk-in party is added to the booking app's waitlist, seated, and then opened as a new table on the till, because the waitlist and the till do not share tables. A table moves; the host updates the booking app, and the server updates the till. Twice in the evening, the two disagree about which table is free.

At Venue B, the host seats the walk-in from the waitlist onto a table on the floor plan, and the same table opens on the till. When a table moves, it moves everywhere.

In the kitchen, both venues use screens. At Venue A, orders reach the screens through the till's integration. One modifier, "no sesame seeds", is shortened on the screen to a code the cook does not recognise; the chef catches it at the pass. Later, a remake is rung as a new item on the till, so the guest is nearly charged twice.

At Venue B, the ticket shows the allergy and the removed ingredient in plain words, and the remake goes through as a re-fire, so the guest is not charged again.

At midnight, the manager cashes up. At Venue A, the till's report shows sales, the card terminal shows its own total, and the booking app shows covers. The manager copies three numbers into a spreadsheet and notices that covers in the booking app do not match covers on the till, because walk-ins were not entered in both. Twenty minutes.

At Venue B, the day's covers, sales and payments are in one report. Ten minutes.

On Saturday, a party of fourteen arrives for a birthday. At Venue A, the booking app shows the party and a note about a cake, but the till shows only a reserved table. The server opens three checks for the joined tables, and at the end of the night the party wants to split the bill by family. Moving items between the three checks takes a long time, and the cake note never reached the kitchen, so the pastry chef finds out when the host asks.

At Venue B, the joined tables open as one check, the cake request is on the booking and visible to the floor, and the bill is split by moving items onto new checks. The kitchen was told hours earlier.

On Sunday, a regular who comes every fortnight books for lunch. At Venue A, the booking app knows her as a guest with twelve visits; the till knows her as an anonymous card payment; the email tool knows her as a subscriber from an export last month. Nobody at the host stand can see that she always orders the same wine and sits by the window.

At Venue B, her profile shows her visits, her spend, her preferred table and her drink, and the host greets her by name and seats her by the window. Small moments like this are why regulars stay.

On Monday, a new server starts. At Venue A, they need four logins and four sets of habits: the booking app for the host stand, the till for orders, the kitchen system's rules for course timing, and an explanation of which screen holds which guest note. Their first week is spent learning where things live.

At Venue B, they learn one system with their own PIN, and their role shows only the parts they need. Their first week is spent learning the menu and the guests, which is what the venue wanted.

On a Friday evening at Venue A, bookings stop appearing on the till. The booking app's support says the integration is the till's responsibility; the till's support says the booking app changed something. The host runs the evening from a printed list.

At Venue B, there is one support team for the whole service. That does not mean nothing ever breaks, but it does mean there is only one call to make.

On Monday, the owner wants last week's numbers. At Venue A, someone exports the till's sales, the booking app's covers and no-shows, and the email tool's results, and builds a spreadsheet. It takes about two hours, and some figures disagree.

At Venue B, the dashboard shows revenue, covers, spend per cover and no-shows against the previous period, and the reports behind it are ready. The owner reads them in fifteen minutes.

On Tuesday, the venue sends a newsletter to regulars. At Venue A, the manager exports guests from the booking app, removes the ones who unsubscribed last month, and uploads the list to the email tool. One guest who unsubscribed through the booking app is missed and receives the email.

At Venue B, the campaign goes to guests who opted in, with unsubscribes recorded in the same place. Nobody exports anything.

Add up the hours from one ordinary week. At Venue A, the extra work of keeping four systems in step comes to roughly five hours a week: menu changes in several places, copying allergies and walk-ins, reconciling the cash-up, building Monday's numbers and preparing email lists. At Venue B, most of that work does not exist.

Five hours a week is about 260 hours a year. At a manager's cost, that is a significant sum, before counting the time those hours could have spent on the floor.

Count the failure points. At Venue A, each of the four systems can fail, and so can each of the integrations between them: the booking to till link, the till to kitchen link, and the export to the email tool. That is seven things that can break. In the Friday story, three small failures happened: a stale menu, a missing allergy note and a confusing modifier.

At Venue B, the bundle can fail, and so can the internet connection it depends on. Fewer things can break, but a failure affects more at once, so a backup connection and a paper fallback matter.

Compare the subscriptions first. Four separate tools may each look inexpensive, but together, with integration fees and per-user charges, they often cost more than a single bundle. Then add the hours. The time spent keeping separate systems in step is usually the largest cost, and it never appears on an invoice.

The fair comparison is the total cost of ownership over three years: subscriptions, integrations, hardware, set-up, training, management hours and the cost of failures.

Here is an illustrative sum. The figures are examples.

The difference over three years is around 22,800, most of it in hours.

Integrations are not bad. A good one saves a great deal of typing. But most integrations carry some information and drop the rest. A booking may reach the till as a reserved table but without the guest's notes. An order may reach the kitchen without the full modifier text. A guest may reach the email tool without their latest consent status.

When comparing, ask for a list of exactly what each integration carries, field by field. The gaps are where the work and the risk sit.

Drawing the stack for each venue makes the difference visible. Venue A's drawing shows four boxes and several lines between them, each labelled with what passes and what does not, and several places where a person copies information by hand. Venue B's drawing shows one box, with the accountant's software and the rota spreadsheet beside it.

Our guide to the restaurant software stack, drawn out shows how to draw your own.

Separate systems are still the right choice in some venues. A venue with a specialist need, such as a large events business with complex contracts, may need a specialist tool that no bundle matches. A venue that is very happy with one system and has years left on it may add a bundle around it rather than replacing it. A group with a long-standing custom setup may find the move too disruptive.

The question is whether the specialist feature is worth the time and risk of the gaps between systems. Sometimes it is.

Guests never see the systems, but they feel the gaps. They notice when a booking note is forgotten, when they are asked about their allergy for the third time, when an email arrives after they unsubscribed, or when the server does not know they have been coming for years. They also notice when everything simply works: the allergy is remembered, the table is ready, the server knows their name.

That is the strongest argument for closing the gaps. Every one of them is a moment where the guest might feel like a stranger.

For a group, multiply everything. Three venues with four separate systems each means twelve subscriptions, twelve sets of logins, several integrations per venue, and three sets of reports to combine every Monday. A guest who visits two of the venues exists as several records in several places.

With one bundle across the group, each venue keeps its own floor plan, menus and opening hours, but the guest record, the reports and the way of working are shared. The time saved grows with each venue.

A bundle is right for most independent venues and small groups: where the team's time is precious, where allergies and guest notes must travel reliably, where reports need to combine bookings and sales, and where several venues need the same setup. It is also right where staff turnover is high, because a new starter learns one system instead of four.

Our guide to one system or several sets out the general comparison, with the tests to run before deciding.

No bundle covers everything. Accounts and payroll usually stay with the accountant's software, and many venues keep the rota and stock in their own tools. The aim is not one system for the whole business, but one system for the service: bookings, the till, the kitchen, guests and the numbers, where the gaps between separate tools cause the most trouble.

If you move, start with the part that causes the most pain, often bookings and the till together, and add the rest as the team settles. Set up and test before switching, train the team, and choose a quiet week. Keep the old systems available for a short time, and export their history before cancelling.

Check the contracts on the old tools for notice periods, so you are not paying for both for long.

A week after moving, look at the same Friday again. Menu changes take one update. Allergies reach the ticket without being copied. Walk-ins and tables agree everywhere. The cash-up is one report. Monday's numbers are ready. The email list is always current.

The team usually notices the difference before the owner does, because they are the ones who stopped copying information between screens.

servearound is one bundle for the service: bookings and the room, the till, the kitchen screens, guests, email campaigns, feedback and analytics, with a booking, a table, an order and a check belonging to the same guest. Menus are changed once and appear everywhere; an allergy taken with a booking is flagged on the booking and appears on the kitchen ticket; walk-ins seated from the waitlist open the same table on the till; and remakes go to the kitchen as a re-fire, so the guest is not charged twice.

Reports are built from the service itself, and the dashboard shows revenue, covers, spend per cover and no-shows against the previous period. Each part works on its own, so a venue can start where the pain is. Accounts, payroll, rotas and stock stay in their own tools. See pricing and Analytics.

Not always. Separate systems can win where a venue needs a specialist feature that no bundle offers.

Mostly in hours: menu changes in several places, copying information, reconciling reports and preparing lists.

They help, but most carry some information and drop the rest. Ask exactly what each one carries.

Information that does not travel, especially allergies and guest notes.

A single failure affects more at once, so a backup connection and a paper fallback matter.

Use total cost of ownership over three years, including the hours spent keeping systems in step.

Yes. Start with the part that causes the most pain and add the rest as the team settles.

Usually not. Accounts and payroll stay separate under either approach.

Follow one allergy, one walk-in and one menu change through your current systems on a busy night, and count every place a person had to copy something.

One bundle vs separate systems is clearest through an ordinary day. Four separate tools that almost talk to each other create small gaps everywhere: menus changed in four places, allergies copied by hand, tables that disagree, cash-ups reconciled from several reports, and email lists rebuilt each week. One bundle closes most of those gaps.

Compare the two on time, failure and total cost of ownership over three years, counting the hours as well as the subscriptions. Check what each integration really carries, draw your restaurant software stack, keep separate systems where a specialist need justifies them, and move gradually, starting where the pain is greatest.