When the internet goes down, service doesn’t.

The evening it matters

Saturday, 20:40, forty covers on the floor.

Your connection dies. On most restaurant systems that is the end of service: no orders in, no tickets to the kitchen, no way to close a bill. On Chequo it is a banner at the top of the screen. Nobody switches anything on, because the offline machinery has been running all evening, every evening, instead of sitting in a code path waiting for its first emergency.

• No offline mode to find and enable: it is always running
• Waiters keep ringing in orders and firing courses
• Kitchen tickets keep printing and the kitchen display keeps working
• Guests keep paying, taking a receipt, and leaving

How it survives

Every device keeps its own record of the service.

Each phone and tablet writes what it does to its own storage before it shows you the result: a check opened, an item added, a course fired, a payment taken. The device’s own disk is the guarantee, not the network. Kill the app mid-tap, drop the tablet, run the battery flat: the service is still there when it comes back.

• Orders, items, fired courses, and payments all recorded on the device
• Written down before the screen confirms it
• A running count of what is still waiting to reach the cloud
• Signing out or unpairing a device is refused while work is unsynced

The kitchen still hears you

Your devices talk to each other over your own network.

One device on your Wi-Fi quietly acts as the meeting point for the others, and it does that job all the time, not only during an outage. So when the internet goes there is nothing to discover, elect, or connect under pressure. The shared picture of the restaurant is already there, and the kitchen carries on hearing the floor.

• Fired orders appear on the kitchen display, with no internet
• Kitchen statuses flow back to the waiter’s screen
• Every device sees every table, not only its own checks
• A waiter can pick up a check a colleague opened
• If that device dies, another takes over in about fifteen seconds

Printing

Your printers were never on the far side of the internet.

Chequo composes the receipt and the kitchen ticket on the device in your hand and sends them straight to the printer across your own network. The cloud is never in the middle. That is why printing does not even notice an outage.

• Kitchen tickets and guest receipts both print offline
• Any network thermal printer, no proprietary hardware
• Built-in print heads on all-in-one terminals
• Mobile-data failover on terminals with their own SIM

Coming back

The catch-up you never have to think about.

When the line returns, each device sends its queue to the cloud in the order things actually happened. The server recognises work it has already seen, so a retry can never create a second order or a second payment. And check numbers are reserved ahead of time, so the number printed on a guest’s bill during the outage is the number that shows up in your reports.

• Replayed in the order it happened, not the order it arrives
• Duplicate-proof: a retry returns the original result
• Check numbers reserved in advance, final from the moment they print
• Anything the server refuses is raised to a manager, never dropped

Straight answers

What we don’t pretend.

An outage is not a normal evening, and a POS that claims otherwise is lying to you. So here is exactly where the edges are, all of it visible in the product, none of it buried in a contract.

• Card payments run on your own card terminal, not through Chequo. If it has its own SIM, and most do, it keeps authorising on mobile data while your restaurant’s connection is down, and Chequo records the tender alongside cash.
• Refunds, voids, comps, discounts, and bill splits are deliberately blocked while offline: they need manager approval and they touch your fiscal records. They appear disabled with the reason on screen, never as a silent failure.
• The receipt handed over at the table is clearly marked provisional. The real fiscal document is filed the moment you are back online, and can be reprinted from your closed checks.
• A brand-new device needs one connected start-up before it can work offline.
• If a device cannot reach the others, it stops accepting food orders after thirty seconds and says so, rather than sending a waiter to a kitchen that will never hear about it.