The restaurant software stack, drawn out

A restaurant software stack is every piece of software a venue uses, and the connections between them. Most owners have never seen theirs drawn out. They know they have a booking system, a till, something in the kitchen, a card terminal, an email tool and an accountant's software, but they have never put them on one page to see what holds what, what talks to what, and where the same information is typed twice or lost altogether.

Drawing the stack is one of the most useful hours a manager can spend. It shows the tools nobody uses, the subscriptions that overlap, the guest who exists as three different records, the allergy note that never reaches the kitchen, and the sales figures that someone retypes into a spreadsheet every Monday. Each of those is a cost, in money, time or risk, and most are invisible until the stack is on paper.

This guide walks through the seven layers of a typical restaurant software stack, from bookings to accounts, explains how they connect and where data is usually lost, and shows how to draw your own. It covers integrations, the restaurant IT underneath it all, and how the drawing helps decide between one system or several.

Most restaurant software stacks have seven layers, whether they are run by seven tools or one:

Around them sit reporting, marketing, the rota and payroll, which draw on the seven.

The bookings layer holds the diary: who is coming, when, how many, and anything the venue needs to know, such as allergies, occasions and seating requests. It feeds the host stand, the table plan, the reminders guests receive and the waitlist on busy nights.

Its data is valuable far beyond the evening itself: it is the first record of who the guest is. When the bookings layer is separate from the others, that record often stays inside it, and the rest of the venue never benefits.

The till, or point of sale, is where orders are taken and checks are built. It holds the menu, the prices, the modifiers and the record of every item sold. For most venues, it is the source of the sales figures, and it feeds the kitchen, the payments and the reports.

Because so much depends on it, the till is the layer where problems hurt most. A slow or unreliable till slows the whole service.

The kitchen layer gets orders from the till to the people who cook them: printed tickets, a kitchen display screen, or both. It decides whether the right dish reaches the right station, in the right sequence, with allergies and changes clearly marked.

Kitchen screens add data of their own: how long each ticket took, which station was slowest, which dishes were remade. That data is valuable for improving service, but only if someone can see it alongside the sales and the bookings.

The stock layer tracks what is bought, received, stored and used. In some venues it is dedicated inventory software connected to the till, so each sale reduces the stock of its ingredients. In many venues it is a spreadsheet and a clipboard, with a weekly count of key items and a monthly stocktake.

Stock is the layer most often disconnected from the rest, which is why food cost is so often known only weeks after the fact.

The guests layer holds what the venue knows about each guest: name, contact details, visits, spend, preferences, allergies, notes and marketing consent. It is built from the other layers: bookings, orders and payments.

This is the layer where data is most often split. A guest who books online, pays by card and joins a loyalty scheme may exist in three different systems, none of which knows about the others.

The payments layer covers how guests pay and how it is recorded: card terminals, cash, transfers and any other methods, along with tips and discounts. The card terminal is often supplied by a payment provider separate from the till, with its own records and its own daily totals.

The two must agree at the end of the day. When they are not connected, someone reconciles them by hand.

The accounts layer is where the business's finances are recorded: sales, costs, wages, tax and the profit and loss. It is usually run by accounting software chosen by the accountant, and it needs a clean daily or weekly record of sales and payments from the other layers.

In many venues, that record is typed in by hand from the till's end-of-day report, which is slow and invites mistakes.

Around the seven layers sit tools that draw on them. Reporting turns the records into numbers managers can act on. Marketing uses the guest layer to send messages. The rota and payroll use the forecast and the hours worked.

Each of these is only as good as the data it can reach. A reporting dashboard connected to the till but not the bookings cannot show no-shows; an email tool that does not receive unsubscribes from the guest layer can send messages to people who opted out.

In a well-connected stack, information flows in one direction without being typed twice. A booking creates a guest record and a table reservation. The guest arrives and is seated; the order is taken on the till against that table; the kitchen receives the order with the guest's allergy marked; the guest pays, and the payment is recorded against the check; the sale reduces the stock; the day's totals reach the accounts; and the guest's visit and spend are added to their record.

That flow is the goal. In most stacks, it breaks in several places.

Data is usually lost at the joins between layers, not inside them. The most common places are:

Each one costs time, and some cost more.

One join deserves special attention: the path of an allergy from the guest to the kitchen. A guest who mentions an allergy when booking expects the venue to know about it at the table and in the kitchen. If the booking layer and the till are separate, the allergy often stays in the booking system unless a person copies it across.

Draw this path explicitly when you draw your stack. Where does an allergy enter, and how does it reach the ticket? If the answer depends on someone remembering, that join is a safety risk.

Integrations are the connections that carry data across the joins automatically. A good integration means a booking appears at the till, an order reaches the kitchen and the day's sales reach the accounts without anyone typing them. A poor one carries some data but not all, or carries it late, or breaks when one side changes.

For each integration in the stack, write down what it carries, how often, and who fixes it when it breaks. Many venues discover that an integration they rely on carries far less than they thought.

Underneath every layer is the restaurant IT that keeps it running: the internet connection, the Wi-Fi, the devices, the logins and the backups. A venue that relies on cloud software is only as reliable as its connection. Many stacks fail not because of the software but because the Wi-Fi does not reach the terrace or the router sits beside the fryer.

Draw the IT too: the internet line and any backup, the Wi-Fi coverage, every device and what it runs, and who manages them.

Most layers of a modern stack are software as a service: run in the cloud, paid monthly and used in a browser or an app. Some venues still run an older till on a server in the back office. Mark which is which on the drawing, because they fail differently. A cloud tool stops when the internet stops; an on-site server stops when its hardware fails, and it usually needs someone on site to fix it.

Cloud tools also connect more easily to each other, while older on-site systems often need special integrations that are expensive to keep working.

For each layer, write down what the team does when it fails. If the till goes down, how are orders taken and sent to the kitchen? If the internet drops, can the card terminal work on mobile data? If the booking system is unavailable, where is tonight's list?

A simple failure plan, with printed bookings for the evening, paper order pads and a mobile data backup for the card terminal, turns a failure into an inconvenience rather than a disaster.

Once the drawing is done, add up the cost of the whole stack: every subscription, every device, every payment fee, and the hours each week spent moving data between tools. The hours are often the largest item, and the least visible.

A stack that costs a little in subscriptions but many hours in retyping and reconciling is expensive. Seeing the total on one page is usually what prompts the changes that matter.

Look at who logs in to each tool and how. Shared logins, such as one password for the whole team, make it impossible to know who did what, and they stay valid after people leave. Each person should have their own login, with access to what their role needs.

When someone leaves, every tool they used needs their access removed. The more tools in the stack, the easier that is to forget.

Every tool that holds guest or staff data must protect it, and the venue is responsible for what its suppliers do with it. In the UK and EU, the General Data Protection Regulation sets the rules; other countries have their own. The more tools hold the same data, the more places it can leak from.

Our guide to marketing consent covers how consent should be recorded and carried across tools.

To draw your stack, take a single sheet of paper or a whiteboard and follow five steps:

The drawing usually takes an hour. What it reveals often saves many hours a month.

Most drawings show the same patterns: more tools than anyone thought, several doing the same job, a few nobody uses, three or four places where data is typed by hand, and at least one guest who exists in more than one system. Many also show a gap: a layer handled on paper because no tool covers it.

Mark each finding with its cost: the subscription, the hours spent, the risk. That turns the drawing into a list of decisions.

Start with the easy decisions. Cancel tools nobody uses. Where two tools do the same job, keep the better one. Where a tool does a job the venue does not need, cancel it. These decisions save money immediately and make the rest of the stack simpler.

Check each cancellation for data first: export anything the venue needs to keep, and make sure no other tool depends on it.

Next, fix the joins where data is lost or retyped. Some can be fixed with an integration; some by changing how a tool is used; some only by replacing tools so that two layers live in the same system.

Prioritise by cost and risk. The allergy join comes first, whatever its cost. After that, the joins that cost the most hours each week.

The drawing makes the biggest decision easier: whether to run the stack on one system or several. One system covering several layers removes the joins between them, because there is nothing to connect. Several specialist tools can offer deeper features, but each join is another place for data to be lost.

Most venues end up somewhere in between: one system for the service layers, with specialist tools for accounts and payroll. Our guide to one system or several compares the two honestly.

In a group, draw one stack for the group and check whether every venue uses the same tools. A group where each venue has its own booking system or till cannot compare its numbers, share guest records or move staff easily.

The drawing often makes the case for one system across venues. Our guide to multi-venue operations covers why.

Stacks grow quietly. A new tool is added for a promotion, a trial is never cancelled, an integration is set up and forgotten. Redraw the stack once a year, or whenever a tool is added or removed, and keep the drawing where managers can find it.

A current drawing also helps when someone new joins. They can see in five minutes how the venue's restaurant technology fits together.

Here is an illustrative drawing for a 90-seat venue. The details are examples.

Decisions: cancel the review tool and the loyalty app; move bookings, the till, the kitchen, guests and email onto one system, so allergies reach the ticket and guests have one record; keep the stock spreadsheet and the accounting software, with a simple weekly sales summary for the accountant.

servearound puts several layers of the stack in one system: bookings and the room, the till, the kitchen, guests, email campaigns, feedback and reporting. A booking, a table, an order and a check belong to the same guest, so an allergy taken with a booking is flagged on the booking and appears on the kitchen ticket, and the guest's visits and spend build up on one record. Analytics is built from the service itself, from bookings, tables, orders, tickets and payments, so there is nothing to export before reading the week.

Payments are recorded against each check by method, with cards taken on your own terminal. Stock, accounts, payroll and rotas stay in their own tools. Pricing is per venue, per month: see pricing and Analytics.

Every piece of software a venue uses, and the connections between them.

Bookings, the till, the kitchen, stock, guests, payments and accounts, with reporting, marketing and the rota around them.

At the joins between layers: bookings to till, till to kitchen, till to stock, guests across systems, payments to till and till to accounts.

Usually about an hour for a single venue.

The path of an allergy from the guest to the kitchen, then the joins that cost the most hours.

The internet, Wi-Fi, devices, logins and backups that every layer depends on.

Yes, where possible. It makes reporting, guest records and moving staff far easier.

Once a year, and whenever a tool is added or removed.

A restaurant software stack has seven layers: bookings, the till, the kitchen, stock, guests, payments and accounts, with reporting, marketing and the rota drawing on them. Data is usually lost at the joins between layers, where information is retyped, duplicated or never carried across, and the most important join is the path of an allergy from the guest to the kitchen.

Draw your own stack in an hour: every tool, every connection, every place data is typed twice or lost. Cancel what nobody uses, fix the joins by cost and risk, check the integrations and the restaurant IT underneath, and use the drawing to decide between one system or several as part of the venue's wider restaurant technology.