The internet is down and the restaurant keeps serving
It is nine in the evening, the restaurant is full, and the router goes down. In a lot of systems that means the till stops, orders go back to pen and paper, and afterwards somebody spends two hours entering what happened — with mistakes. The fix is not better internet. The fix is a till that keeps working without it.
The idea in a minute
The till does not wait for a server reply to carry on. It records the step on the device and keeps serving; the upload happens by itself in the background.
How it works
- 1
1. The tables and the menu live on the device
The floor plan, the items and their prices are stored on the till itself. So when the line drops the screen does not go blank or freeze — the waiter opens the table, sees the menu, and carries on.
- 2
2. Every service step works offline
Seating guests at a table, opening a takeaway order, adding an item, changing a quantity, removing an item, sending to the kitchen, and taking payment. Not one step — the whole service cycle from the customer sitting down to paying.
- 3
3. The sequence is preserved, not just the actions
The steps depend on each other: the items cannot upload before the order they belong to. Zemam saves the work as a linked chain, so when the connection returns it uploads the order first, takes the number the server gives it, and carries that through the remaining steps in the right order. What was recorded on the device comes out on the server exactly the same.
- 4
4. The upload happens by itself
The moment the connection is back, the saved work uploads in the background with nobody pressing anything or having to remember. The till keeps serving throughout — no waiting screen, no sync pause.
- 5
5. “The line is down” and “the server refused” are different
If the problem is connectivity, the step simply waits and retries itself — there is nothing wrong with it. But if the server answered and refused (an item was removed from the menu, say, or the shift was closed), retrying would earn the same refusal. So the system separates that case and puts it in front of a person to decide, instead of looping forever.
- 6
6. Rejected work has a list and a way out
Work the server rejected appears in a single list on the till with two ways out: retry, or discard. Discarding is protected: ordinary work (seating, ordering) a cashier can drop, but anything where money actually moved — an order the customer paid for — can only be discarded by a manager. So money never disappears from the record with one press.
In short
The whole service cycle works with no internet: seat, order, send to kitchen, and pay.
Upload is automatic the moment the line returns — no sync button, no re-entry.
Sequence is preserved, so an order lands on the server exactly as it was on the device.
Anything where money actually moved can only be discarded by a manager.
Situations that happen
Friday peak and the router drops
The restaurant is full and the waiters are taking orders. Nothing stops, and nobody falls back to pen and paper. The moment the line returns, every order is already on the server.
A line that flaps in and out
Worse than a clean outage: intermittent drops that make every tap hang. When the till is not waiting on a server reply, flapping connectivity stops being noticeable at all.
A branch with poor connectivity anyway
Branches in malls or areas where the line is never stable. Operations stop depending on line quality, and the branch runs as fast as any other.
A truck or a pop-up
Mobile or temporary operations with no fixed line. The till runs on device data and uploads whenever it finds a network.
Related reading
Does your line drop at peak time?
Talk to us and we'll show you the till running with the network pulled — and the work uploading itself when it comes back.