The POS that never stops: why your system must work offline
What actually happens when the connection drops mid-service, the difference between a system that works offline and one that claims to, and how to test yours before reality does.
Ask any restaurant owner about their worst five minutes and you will usually hear a version of the same story: a queue at the till, a screen saying “no connection”, orders written on paper, and half of them never reaching the kitchen.
An internet outage is not an exceptional state. Routers restart, providers stumble, and a branch network drops at two in the afternoon for no visible reason. The question is not whether it happens, but what your system does when it does.
Three kinds of system
| Type | During an outage | Risk |
|---|---|---|
| Pure cloud | Selling stops completely | Lost sales and an angry queue |
| Pure local | Keeps selling, but nothing connects | No consolidated reporting, no view across branches |
| Hybrid (local + sync) | Keeps selling, then reconciles | Needs correct conflict handling |
The third is what a restaurant actually needs: always selling, and still consistent when the line returns.
What exactly has to keep working?
“Works offline” is a generous phrase. Ask your vendor specific questions:
- Can I open a new order and complete a sale with no connection?
- Does the thermal receipt print straight from the device?
- Does the ticket reach the kitchen display over the local network?
- Is inventory deducted and reconciled correctly afterwards?
- What happens to cashier shifts and the cash drawer?
- On reconnect, does the data merge without duplicates?
If the answer to the first is “yes” and to the rest is “more or less”, you are looking at a system that can display a menu.
Sync is the hard part
Selling offline is easy. What happens afterwards is not.
A good system handles four cases:
- Ordering. Ticket 104 on one device and ticket 104 on another must not collide. Usually solved with per-device unique identifiers.
- Stock conflicts. Two devices sold the last two units of one item. The system should complete both sales and record a negative balance for review — not reject one after the customer has eaten.
- Prices and promotions. An order must be priced as of the time of sale, not the time of sync.
- Retries. An interruption mid-upload must resume, not restart from zero or send twice.
What it means for your books
The point most people miss: an offline sale does not end at the receipt. Every sale still has to produce its accounting entry and its stock deduction — even two hours later.
In GoSufra the POS, kitchen and waiter apps keep working without a connection and sync automatically when it returns, after which sales follow the normal path: ingredients come off stock, a balanced double-entry journal is posted, and the numbers appear in branch reporting. You are not left with a “day with no data” at month end.
Preparation that costs nothing
- Cause an outage on purpose. Unplug the internet for ten minutes during a quiet hour once a month and have a cashier complete a full sale.
- Train the message. “The system is fine” is the sentence that prevents panic behind the counter.
- Watch the sync indicator. A cashier should be able to see at a glance that orders are still queued.
- Do not close a shift with sync pending. Have the system block it rather than relying on attention.
- Keep a fallback line. A data SIM in one device is usually enough to keep sync alive.
The point
The internet is an external service you do not own. Selling is your business. A system that ties the second to the first makes your restaurant a hostage to a fault you cannot control.
Test yours today, during a quiet hour. The worst moment to find out is eight o’clock on a Thursday evening.
Run all of this from one system
POS, kitchen, inventory, recipe costing, staff and accounting — connected, and free to start.
Create your free account