What happens to your festival bar when the signal drops
A field with 40,000 people on it is the worst coverage you will ever trade in. What offline mode must mean, and what separates resilience from marketing.
Every POS sold into events says it works offline. Almost all of them mean something narrower than you do, and the gap between the two meanings is discovered at about 9pm on the Saturday.
It is worth being unromantic about why festival connectivity is so bad. It is not that the site is remote. It is that forty thousand people arrived at once, each carrying a phone that is now hunting for signal, and the local cell was engineered for a village. Coverage does not degrade gently; it collapses at peak, which is exactly when the bar is three deep.
The four things that can be offline, and they are not the same
1. Taking the order
The till has to keep accepting taps. This is the easy part and it is what most suppliers mean by offline: the menu is cached, the basket builds locally.
2. Taking the money
Much harder, and mostly not the POS's problem. Card acquiring needs an authorisation. Some terminals will store-and-forward up to a floor limit, and that is a risk decision — you are accepting the possibility of declines you cannot recover. Cash has no such problem, which is why serious event operators still plan for it.
3. Getting the order to the kitchen
Frequently missed. A till that queues its sales locally but cannot reach the kitchen screen has not kept you trading — it has built a list of food nobody is cooking. Either the ticket has to reach a printer or screen on the same local network, or the runner has to shout, and one of those two should be a decision rather than a surprise.
4. Knowing what you have sold
Reports, stock and the hall's live view will lag. That is usually fine, as long as the reconciliation afterwards is exact rather than approximate — every queued sale arrives, once, with the time it was actually taken rather than the time it synced.
The questions that separate real from claimed
- What is stored, and where? On the device, or on a local server that is itself a single point of failure in a tent?
- What is the ceiling? How many offline sales before something fills up, and what happens then — refuse, or silently drop?
- Does a sale taken offline keep its real time? If everything syncs at 23:40, every hourly report for the night is wrong.
- Can it be duplicated? If a device syncs twice, do you get two sales? Ask them to demonstrate it, not describe it.
- What does the operator see? A staff member needs to know they are offline, or they will keep promising receipts that will not send.
The unglamorous mitigations that actually work
- A wired network to the bars, if the site allows it. Nothing beats copper for a fixed structure.
- One 4G router per bar rather than per device, so you have one thing to diagnose.
- A cash lane. Not for ideology — as a circuit breaker when acquiring is down.
- A printed menu with prices at every till, because a cached menu on a dead device is a staff member guessing.
- A dry run at load. Turn the router off during setup and watch what staff actually do.
Where HelchPOS is up to, honestly: the kitchen screen holds its queue on the device and sends when it can, and a bill in progress on the till survives the drop on that device — but the till cannot complete a sale without the network, so a signal drop mid-service is the cash lane above, not a feature we have. When this was written printing was unproven — the ticket bytes were written and tested, but no thermal printer had printed one from real hardware, so it was not offered as a feature. Since 27 August 2026 a Star TSP143IV at a live venue prints dockets over CloudPRNT; the Epson and label-printer paths are still unproven and still not offered. If a supplier cannot tell you which parts of their offline story have been tested in a field rather than an office, that is the answer to your question.