POS offline mode: the night the internet died

At ten to eight on a full Friday, the router at the back of the bar blinks red and stays red. The tills show a spinning circle. The kitchen screen stops receiving orders. The card machine says it cannot connect. Forty guests are seated, twelve more are at the door, and every system the venue relies on has just stopped talking to the outside world.

Every venue that uses a cloud point of sale will face that night eventually. What happens next depends almost entirely on what was planned beforehand: whether the system keeps working without the connection, whether there is a backup line, whether the team knows how to fall back to paper, and whether anyone has ever practised it.

This guide covers what POS offline mode means, what must keep working without a connection, what can wait, how to handle the card machine, the paper fallback, and how to test the whole plan before you need it. Every venue and figure in it is an example.

POS offline mode is how a point of sale behaves when it loses its internet connection. Some systems keep working fully: orders are taken, sent to the kitchen and stored on the devices, then sent to the provider's servers when the connection returns. Some keep working partly, taking orders but not payments, or showing the menu but not sending orders. And some stop until the connection is back.

Which kind you have matters a great deal on the night. A system that keeps working lets the team carry on almost as normal; one that stops sends the venue to paper within minutes.

Ask your provider exactly what works offline, and test it yourself. The brochure's description and the system's behaviour are not always the same.

Most connection failures start inside the venue, not on the internet as a whole. A router that overheats or needs restarting, a cable pulled loose, a power cut, a fault on the venue's own line, or a wifi network overloaded by guests. Fewer come from the internet provider's wider network, and fewer still from the POS provider's own servers.

That matters, because most local failures can be prevented or survived. A second line from a different provider, a router that switches between them, protected power for the network equipment and a separate network for guests remove most of the common causes.

Our guide to restaurant internet: two lines, one service covers how to set those up.

When the connection fails, a few things must keep working for service to continue. Orders must reach the kitchen. The kitchen must know what to cook and in what order. Guests must be able to pay, by card or by cash. And someone must be able to see which tables are waiting for what.

Everything else can wait: reports, guest records, stock updates, marketing, menu changes. If those stop for an hour, nobody notices until the next morning.

Plan your offline arrangements around the four essentials. If your system covers them offline, your plan is simple. If it does not, your plan must cover them on paper.

Being clear about what can wait helps the team stay calm. Updating the menu, checking yesterday's figures, looking up a guest's history, sending a marketing email: none of these matter during an outage.

Bookings for future dates can wait too, if the booking system is online-only. Note any phone bookings on paper and enter them afterwards. Guests who book online will be accepted when the system returns, or will see the booking page unavailable for a short while.

The rule for the team is simple: during an outage, focus on the guests in the room.

Systems that work offline usually do so by storing data on the devices in the venue, often one device acting as a local hub that the others connect to over the venue's own network. As long as the local network and that device are working, orders can move between tills and kitchen screens without the internet.

That depends on the local network still working. If the outage is a power cut, or the router itself has failed, even a system with a strong offline mode may lose the connection between devices. Ask how your system behaves in each case: internet down, router down, power down.

Ask also how long it can run offline, and what happens to anything that needs the provider's servers, such as card payments processed through the POS.

When a system has taken orders offline, it must send them to the provider's servers once the connection returns. That process, the sync, is where problems can appear: orders duplicated, payments recorded twice or figures that do not match.

Ask how the system handles the sync, and check the day's figures carefully after any outage. Compare the till's total with the card terminal and the cash. Look for duplicated checks and missing payments.

An outage that is handled well on the night can still leave a mess in the figures if nobody checks them afterwards.

The kitchen's needs are the most urgent. If orders stop reaching the kitchen, cooking stops within minutes. If your system keeps sending orders to the kitchen offline, the kitchen may not notice the outage at all. If it does not, orders must reach the kitchen on paper.

Agree in advance how paper orders reach the kitchen: written on order pads, one per table, carried to the pass, read out by the person running it and hung in order. The kitchen should know the routine as well as the floor.

Kitchens that have moved from printers to screens sometimes forget how to work with paper. A short practice once a year keeps the routine fresh. Our guide to kitchen printers: what a screen does better covers keeping paper as a fallback.

A card machine down is often the most stressful part of an outage, because guests want to pay and leave. Card terminals connect in different ways: through the venue's network, through a mobile connection inside the terminal, or both. A terminal that uses only the venue's network stops when the network stops.

Check how your terminals connect. Terminals with their own mobile connection can often carry on through a broadband fault, as long as the mobile signal is good. Some terminals can also store card payments offline and send them later, within limits set by the card provider; ask whether yours can, and what the risks are.

If cards cannot be taken at all, explain calmly, offer cash or a bank transfer where possible, and as a last resort take the guest's details and agree how they will pay later.

When cards are down, cash matters more. Keep a sensible float and enough change to handle a rush of cash payments. Make sure the team knows how to record cash payments on paper if the till is not working, with the table, the amount and the time.

Cash taken during an outage must be recorded against the right checks afterwards, so the day's figures add up. A simple sheet, one line per table, is enough.

If the booking system is online-only, the host stand may lose sight of the evening's bookings. Print the evening's bookings before service, or keep a copy on a device that can show it offline, so the host can still seat guests in order.

Walk-ins can be handled on paper: names, party sizes and times on a sheet, seated as tables come free. When the system returns, the waitlist and bookings can be brought back up to date.

If guests order from their phones by scanning a code at the table, an outage in the venue may not stop them, because their phones use their own mobile data. But their orders still need to reach the kitchen, which depends on the venue's own connection.

If the kitchen cannot receive phone orders during an outage, tell guests at the table and take their orders by hand. A guest who orders on their phone and hears nothing for twenty minutes is far unhappier than one who is told the system is down.

Every venue should have a paper fallback kit, kept in the same place and checked regularly: order pads, pens, a printed menu with current prices, a sheet for recording payments, a printed list of tonight's bookings and a copy of the outage plan. Keep it at the pass or behind the bar, where everyone knows where to find it.

Check the kit monthly. Prices change, pads run out and pens disappear. A fallback kit with last season's prices causes its own problems.

The bar faces the same problem as the kitchen: drinks orders that normally arrive on a screen or a printer stop arriving. Agree how drinks orders reach the bar on paper, and how tabs are kept. A bartender who keeps tabs on paper during an outage needs a clear sheet: the table or name, each drink and the time.

Tabs are where outages cause most lost revenue, because drinks are poured and never charged. When the system returns, enter every paper tab before closing, and check that every table's drinks reached its check.

An outage goes more smoothly when everyone knows their role. The manager decides when to switch to paper and looks after the guests. One person, often whoever runs the pass, carries paper orders to the kitchen and keeps them in order. One person records payments on paper. Someone else checks the backup connection and calls the provider if needed.

Write the roles into the outage plan, and assign them at the start of each shift, so the team does not have to decide in the moment. In a small venue, one person may hold several roles; what matters is that every role is covered.

Someone must decide when to switch to paper, and everyone must know who that is. Usually it is the manager on duty. The decision should be quick: if the system has not recovered within a few minutes, and the backup line has not taken over, switch.

Waiting too long is the common mistake. Ten minutes of hoping the connection returns can leave a dozen orders untaken and the kitchen idle. Switching early costs little; the team can always switch back.

When the system returns, paper orders need entering so the figures and the guest records are complete. Do it as soon as service allows, while the team remembers the details: each table's order, its payments and any voids or comps.

Check the totals afterwards. The day's takings should match the cash and the card terminal, including everything taken on paper. If they do not, find the difference before the team goes home.

The most important part of any offline plan is testing it. On a quiet afternoon, disconnect the internet and see what happens. Do the tills keep taking orders? Do orders reach the kitchen? Does the card machine work? How long does the backup line take to switch over?

Then run the paper fallback: take a few orders on paper, carry them to the pass, record a payment by hand and enter it all afterwards. Time it. Fix whatever goes wrong.

Test again after any change to the network, the POS or the card terminals, and at least once or twice a year. A plan tested once, two years ago, is barely a plan.

The best offline plan is one you rarely use. A second internet connection from a different provider, through a router that switches over automatically, keeps most venues online through most failures. A mobile connection is often a good backup, as long as the signal is strong where the router sits.

The backup must switch automatically. A backup that needs someone to change cables in the middle of service will be used late or not at all.

Outages often seem to happen at the worst time, partly because the busiest moments put the most strain on the network: more devices, more guests on the wifi, more orders in flight. Keep guest wifi separate from the venue's own network, and check that the router is not overheating in a cupboard. Many busy-night outages are preventable.

A power cut takes out the network as well as the lights. A small uninterruptible power supply for the router and the main network equipment can keep the connection alive for a short cut, and give the tills and terminals time to keep working on their batteries.

Longer cuts usually mean the kitchen cannot cook either. Your plan for those is about guest safety, closing service calmly and protecting stock in the fridges, more than about the point of sale.

Some outages come from the provider rather than the venue. If the POS provider's servers have a problem, every venue using the system is affected. Ask about pos uptime: how often the system has been unavailable, for how long and at what times, and how the provider tells customers about problems.

A cloud POS with a strong offline mode can carry a venue through a provider's outage as well as a local one. A cloud POS without one makes your paper fallback just as important for the provider's problems as for your own. Our guide to cloud POS: what it fixes and what it risks covers the wider trade-offs.

An outage affects guests, however well it is handled. Service recovery is about how you treat them: tell them honestly what has happened, keep them informed, and make up for any wait or inconvenience in a way that fits.

Most guests are understanding when they can see the team handling a problem calmly. A short explanation, a sincere apology and, where the wait was long, a drink or a dessert on the house usually leave them with a good memory rather than a bad one. Our guide to service recovery: putting a bad night right covers the approach.

After every outage, hold a short review. What happened, how long did it last, what worked and what did not? Did the backup line switch over? Did the team know where the fallback kit was? Did the figures add up?

Fix what went wrong: a backup that did not switch, a kit with old prices, a terminal that could not connect. Each outage is a chance to make the next one easier.

An invented bistro runs a cloud POS on a single broadband line. One Friday, the line fails at ten to eight. The tills stop, the kitchen screen goes quiet and the card terminals, which use the same line, cannot connect. The team spends twenty minutes trying to fix the router before switching to paper, and the paper menu has old prices.

After that night, the bistro adds a mobile backup line through a router that switches automatically, moves the card terminals to their own mobile connections, puts a small battery backup on the network equipment and builds a fallback kit with current prices. It tests the whole plan on a quiet afternoon.

Three months later, the main line fails again during service. The backup takes over within a minute. Most of the team never notices.

servearound is a cloud POS with no offline mode. The point of sale, the kitchen screens and the host stand all reach servearound over the internet, and when a screen loses its connection, it says it cannot reach servearound and keeps trying until the connection returns. Digital menu boards keep showing the board they last had through a dropped connection or a restart.

That makes a backup line and a paper fallback part of every servearound venue's setup. Because servearound runs in a browser, a tablet on a mobile connection can stand in for a till whose network has failed. Card payments are taken on your own terminal and recorded against the check, so a terminal with its own mobile connection can keep taking cards through a broadband fault. See Order Fulfillment.

How a point of sale behaves without an internet connection: fully working, partly working or stopped until the connection returns.

Orders to the kitchen, the kitchen's view of what to cook, payments and a view of which tables are waiting.

Check whether it has its own mobile connection, offer cash or transfer where possible, and agree a way for guests to pay later as a last resort.

Within a few minutes, if the system has not recovered and the backup line has not taken over. Waiting too long is the common mistake.

Disconnect the internet on a quiet afternoon, see what still works, run the paper fallback and fix what goes wrong.

Yes. A second line from a different provider, switching automatically, keeps most venues online through most failures.

A small battery backup for the network equipment covers short cuts. Long cuts are about closing safely.

Tell them honestly, keep them informed and make up for long waits in a way that fits.

POS offline mode decides what happens on the night the internet dies. Know exactly what your system does without a connection, and plan around the essentials: orders to the kitchen, the kitchen's view, payments and the tables. Everything else can wait.

Install a backup line that switches automatically, give card terminals their own connection, protect the network's power, keep a paper fallback kit with current prices, decide who switches to paper and when, test the whole plan on a quiet afternoon, look after guests honestly and review every outage afterwards.