Integrations: useful, until one of them breaks

On a busy Saturday, the online orders stop arriving in the kitchen. Nobody notices for forty minutes, because the delivery platform still shows them as accepted. The problem turns out to be the connection between the platform and the till, which stopped working after an update nobody knew had happened. By the time it is fixed, a dozen guests have waited an hour for food that was never cooked.

Integrations, the connections that pass information between a venue's systems, make a modern restaurant possible. The booking system talks to the till, the till talks to the kitchen, the payments talk to the accounts. But every connection is also something that can break, quietly, at the worst moment, and the more of them a venue has, the more of its service depends on things it cannot see.

This guide covers which integrations are worth the risk for a restaurant, which are better built into one system, how to tell when a connection has failed and what to ask before adding another. Every venue and figure in it is an example.

Integrations connect two systems so that information entered in one appears in the other: a booking that becomes a table on the floor plan, an order that becomes a kitchen ticket, a day's takings that become an entry in the accounts. Without them, someone types the same information twice, or the systems simply do not know about each other.

Most integrations work through an application programming interface, a set of rules one system offers so others can send it information or ask for it. Each connection is built on those rules, and depends on both systems keeping to them.

Integrations break for ordinary reasons. One system updates and changes the rules the connection relied on. A password or key expires. The internet drops for a few minutes and messages are lost. One system is down for maintenance. A menu item exists in one system and not the other, so an order cannot be matched.

None of these is unusual, and most of them happen without warning. The question is not whether a connection will fail, but how often, how you will know and what happens to the service while it is down.

The most dangerous failures are silent ones. A connection that stops working without any alarm can lose orders, bookings or payments for hours before anyone notices. The till looks normal, the booking page looks normal, and the gap only shows when a guest arrives for a table nobody knew about.

Before relying on any integration, ask how a failure will be noticed. Does it raise an alert? Does someone check it? Is there a simple way to see that the latest order or booking arrived? A connection without a way to notice failure is a risk waiting for a busy night.

Each integration has a cost beyond its price: someone must set it up, keep it working, notice when it fails and fix it. When two systems are made by different suppliers, each may blame the other when the connection breaks, and the venue is left in the middle.

Add up these costs for every connection in your stack. A stack of six systems with ten connections between them is ten things that can break, each needing someone's attention.

The restaurant software stack is the set of systems a venue uses: the till, bookings, kitchen screens, guest records, marketing, payments, accounts, payroll, stock and perhaps delivery. Some venues use one system for most of these; others use a separate system for each, joined by integrations.

Draw your stack on a page: each system as a box, each connection as a line. The picture shows at once how many joins your service depends on, and where a single failure would stop a service.

The choice between one system or several is really a choice about integrations. One system that covers bookings, the till, the kitchen and guests needs no connections between them, because they share the same information from the start. Several best-in-class systems may each do more, but they need connections, and each connection can fail.

Neither is always right. Our guide to one system or several: the honest comparison sets out the trade-off in detail.

Some failures stay in the back office; others reach guests at once. A booking that never reached the floor plan means a guest arriving for a table that is not held. An online order that never reached the kitchen means a guest waiting for food that is not being cooked.

Map each integration to what a guest would experience if it failed. The ones that would leave a guest waiting, or turned away, are the ones that deserve the closest watching and the best fallback.

Some integrations are worth the risk because the alternative is worse. Card payment terminals that pass amounts to the till save mistakes on every bill. Accounting software that receives daily takings saves a day a month. Payroll that receives hours saves retyping.

These share a feature: if the connection fails, the service carries on. A payment can be typed in by hand; the takings can be exported; the hours can be entered later. The failure costs time, not guests.

Other integrations deserve more thought, because their failure stops the service. Orders that reach the kitchen only through a connection, bookings that reach the floor plan only through a connection, or payments that cannot be taken when the connection is down all put the service at the mercy of a link the venue cannot see.

For these, prefer systems where the parts are built together, or make sure there is a quick fallback, such as orders printed as well as sent, or a way to take bookings by hand, for the moments the connection fails.

Where the core of the service, bookings, the floor plan, the till, the kitchen and guest records, is built as one system, there is nothing to join between them. A booking becomes a seated table, an order becomes a ticket and a guest's allergy reaches the kitchen because they are all the same information, not because a connection carried it.

This removes the most dangerous kind of failure: the silent break in the middle of a service. It does not remove the need for connections to the outside world, such as accounts or payroll, but those are the ones whose failure costs time rather than guests.

The till sits at the centre of most restaurant stacks, so POS integration is where most connections meet: bookings, kitchen, payments, accounts, delivery and loyalty may all connect to it. The more connections it has, the more ways a service can be disrupted.

Our guide to POS integration: the four systems it must talk to covers the connections a till genuinely needs and the ones that can wait.

Delivery platforms are one of the most common integrations, and one of the most fragile. Orders arrive from the platform, need to reach the kitchen and need to match the till's menu. When the menus differ, prices change or the connection drops, orders are missed or rung wrongly.

If you connect a delivery platform, check it at the start of every service, keep the platform's tablet as a fallback and match the menus carefully whenever either changes.

Accounting connections are usually among the safest, because their failure is rarely urgent. If the daily takings do not reach the accounts one night, they can be sent the next day, or exported by hand, without any guest noticing.

Check them weekly rather than daily, and make sure the mapping between the till's categories and the accounts is kept current. Our guide to accounting integration that saves a day a month covers what should flow and what should not.

A restaurant API is what lets a system be connected to others: the set of rules another tool can use to read or send its information. Some systems offer a public API for venues to build their own connections; others offer only the connections their supplier has built.

For most venues, a public API matters less than it sounds. Building and keeping a custom connection working takes technical skill and ongoing attention. It matters most for groups with their own technical staff, or venues with an unusual system they must keep.

When a connection between two suppliers' systems fails, each may say the problem lies with the other. The venue is left in the middle, making calls during service, while the connection stays broken.

Before relying on a connection, agree who is responsible for it. A connection built and supported by one of the two suppliers, who accepts that responsibility, is far easier to get fixed than one built by a third party nobody owns.

Many connections depend on the menu being the same in both systems. A dish added to the till but not to the delivery platform, a price changed in one and not the other or a modifier named differently can cause orders to fail, arrive wrongly or charge the wrong amount.

Make menu changes in a set order, in every connected system, and check a test order afterwards. Menus that drift apart between systems are one of the commonest causes of integration problems.

Before adding an integration, ask a few questions. Who built it, the supplier of either system or a third party? Who fixes it when it breaks? How will you know it has failed? What happens to the service while it is down? Is there a fallback?

Ask other venues who use the same connection how reliable it has been. A connection that fails every few weeks is a very different proposition from one that has run for a year without trouble.

For the integrations a service depends on, add a quick check to the opening routine: has the latest online order arrived, did the last booking appear on the floor plan, did yesterday's takings reach the accounts? A minute's check at the start of the day catches most failures before guests do.

Make the check someone's job. A connection that everyone assumes is working, and nobody checks, is the one that fails silently.

When an integration fails, the first job is to protect the service: switch to the fallback, tell the team and keep guests looked after. The second is to fix the connection, which usually means contacting the supplier who built it.

Keep a note of who to call for each integration, and how to reach them during service. Discovering at eight on a Friday that nobody knows who supports a connection is an avoidable problem.

Many integrations stop when the internet does. Before relying on a connection, find out what each system does when the connection to the internet is lost: does the till keep taking orders, do kitchen tickets still arrive, are bookings held until the connection returns?

A venue whose service stops when the broadband drops is depending on something it does not control. A backup connection, such as a mobile router, and systems that keep working through a short outage, protect the service on the day the line fails.

For each integration the service depends on, write down the fallback in one line: what the team does if it fails. "If online orders stop, check the platform's tablet every ten minutes and ring orders in by hand." "If bookings stop reaching the floor plan, the host checks the booking system directly."

Keep the list where the manager on duty can find it, and run through it now and then. A fallback known only to the person who set up the connection is no fallback at all.

Many integration failures follow an update to one of the systems. Ask your suppliers to tell you before updates that affect connections, and check the connections after any update you know about.

Changes in the venue cause failures too: a new menu item that is not mapped, a payment method added to one system and not the other, a table renumbered on the floor plan but not in the booking system. Each change is a moment to check the connections it touches.

The simplest way to reduce integration failures is to have fewer integrations. Each system removed, and each job brought into a system the venue already uses, removes a connection that could fail.

Review the stack once a year. Ask whether each system still earns its place, and whether its job could be done by a system you already have. Many venues find a tool or two they no longer need.

In a group, integrations multiply: each venue's connections, plus connections between the venues and the group's own systems. A group with different systems at different venues may have several versions of the same connection, each failing in its own way.

One system across venues reduces the connections to the outside world to one set, built once and checked once. It is one of the strongest arguments for standardising a group's systems.

Some connections are nice to have and could be switched off without harm. A link that copies reviews into a dashboard, a connection that posts the menu to a listing, a feed that sends sales to a second reporting tool: each adds a little convenience and a little risk.

Review them now and then. If a connection is rarely used, or its job could be done by hand in a few minutes a month, switching it off removes a thing that can break.

Every connection is also a door. Integrations use keys and passwords that give one system access to another, and those keys can be lost, shared or left active after a supplier or member of staff has gone.

Keep a list of every connection, who set it up and what access it has. Remove the ones no longer used, change keys when people with access leave and treat each connection as part of the venue's security, not just its convenience.

Every integration moves your data between systems, and each system keeps its own copy. Know where your data lives, which system holds the master copy of each kind and what happens to the copies if you stop using a system.

Guest data matters most. A guest list split across a booking system, a till and a marketing tool, each slightly different, is harder to keep accurate and harder to answer for when a guest asks what you hold.

An invented bistro uses five systems: a booking system, a till, a kitchen printer service, a marketing tool and accounting software, joined by six connections. Twice in a month, bookings fail to reach the till's floor plan, and once the kitchen misses a dozen orders when a connection drops after an update.

The owner moves bookings, the till, the kitchen and guests into one system, leaving only the accounting connection, which is checked weekly. The silent failures stop, the morning check takes a minute instead of ten and the owner spends far less time on the phone to suppliers blaming each other.

servearound is built so the core of the service needs no integrations: bookings, the floor plan, the till, the kitchen screens, guest records, campaigns and reports share the same information, so a booking becomes a seated table, a guest's allergies reach the head of the kitchen ticket and settling the bill completes the booking, with nothing joining them that could break in the middle of a service.

Outside that core, servearound does not connect to accounting software, payroll, delivery platforms, other booking platforms or other tills today, and there is no API key or webhook for venues to connect their own tools. Card payments are taken on your own terminal and recorded against the check, and bills for any dates download as a spreadsheet for the accounts. See pricing and point of sale and kitchen.

Connections that pass information between systems, such as bookings to the till or takings to the accounts.

Updates, expired keys, internet drops, maintenance and data that does not match between systems.

Those whose failure costs time rather than guests, such as accounts and payroll.

Those the service depends on, such as orders reaching the kitchen only through a connection.

Check it at the start of each day, and ask for alerts where they exist.

Usually only if you have technical staff to build and maintain custom connections.

It removes the connections between the parts. Several systems may each do more, at the cost of more joins.

Once a year, asking whether each system still earns its place.

Integrations make a modern restaurant work, and every one of them is a thing that can fail, often silently and at the worst moment. Integrations worth the risk are those whose failure costs time rather than guests, such as accounts and payroll. Those that carry the service itself, such as orders reaching the kitchen, are safer built into one system or backed by a quick fallback.

Draw your restaurant software stack, count the joins, ask who fixes each connection and how you will know it has failed, and check the critical ones every morning. Treat POS integration and any restaurant API with care, weigh one system or several honestly and remember that the most reliable connection is the one you no longer need.