It Has to Work When the Power Is Out

The worst room in the building for signal

The office has five bars. The router is on the wall behind reception, where somebody put it in 2019 because that's where the fibre came in.

Your stock is forty metres away, behind steel racking, through a brick wall, in a room with a roller door. Steel shelving is very good at stopping wi-fi. Stacked stock is better. By the back of aisle seven there is no usable signal at all, and there never was — nobody noticed, because until now nothing in that aisle needed a connection.

Then the scanners arrive, and suddenly the dead spot is a business problem.

This is the single most common thing we find on a first walk-through, and it's worth knowing before you buy anything rather than on go-live morning. The fix is usually cheap — an access point or two in the right places, which we'll identify at the design stage — but it is not free and it is not instant, and it belongs in the budget from the start.

And then the power goes

Coverage is the easy half. The harder half is that the electricity is not reliable, and you already knew that.

Here's the thing people miss: the scanner has a battery. The access point doesn't. Neither does the router, or the fibre ONT on the wall. During load shedding the device in your storeman's hand is the only part of the chain still awake. A UPS on the network cupboard is cheap and worth doing, and it still doesn't help you when the outage is upstream at your ISP.

So the question isn't whether the system survives a power cut. It's what your team can still do during one.

If the answer is "nothing, we write on paper and catch up later," you have bought an expensive way of generating the exact backlog the system was supposed to remove. Paper catch-up is where variance is born.

What "works offline" has to actually mean

Every vendor will tell you their system works offline. The word is doing an enormous amount of work in that sentence. Three things have to be true:

The device holds what it needs. Part records, bin locations, quantities and prices as at the last sync, stored on the scanner itself. Not a cached web page — an actual local copy the app reads from.

Writes land locally first. When your storeman scans a pick, that pick is recorded on the device immediately and queued for sync. It is not "attempted and retried."

The confirmation comes from local state. This is the tell, and it's the one you can see with your own eyes. Scan a part with the network off. If the screen confirms instantly, the app wrote locally. If it hangs, spins, or waits a beat before confirming, it went looking for a server — and what you have is an online system with a retry loop, which is a different product with the same marketing.

The hard part isn't storing offline

Storing things on a device is easy. The genuinely difficult part is what happens when two scanners did things to the same stock while they couldn't see each other, and then both reconnect.

Most of it resolves cleanly, because movements are additive. Two devices each pick three of the same part while offline. Both picks really happened. Six came off the shelf. The system subtracts both and nothing is lost. Receipts and returns behave the same way. This is most of your traffic, and it merges without anyone having to think about it.

Counts are not additive. A count isn't a change, it's a claim about an absolute quantity at a moment in time. If two people count bin C2-04 while offline and one says nine and the other says eleven, those don't add up to twenty. They contradict each other, and no amount of cleverness turns two contradictory claims into one true number.

There's only one honest way to handle it: a count should lock the location for its duration, and where two counts collide anyway, the system keeps both, applies the later one, and raises it for a person to look at. What it must never do is quietly pick one and discard the other, because then your stock figure is wrong and nothing anywhere records that a decision was made.

Ask a vendor exactly this. "Two scanners, both offline, both count the same bin, different answers — what does your system do?" The quality of the answer tells you whether they have run this in a real warehouse or only in a boardroom.

What you don't get offline

Being straight about this is more useful than pretending.

The office is looking at old numbers. Your dashboard is only as fresh as the last sync. If the floor has been disconnected for three hours, head office is working off three-hour-old figures — and the screen should say so plainly, with a timestamp, rather than displaying a stale number as though it were live. A dashboard that hides its own staleness is worse than no dashboard.

Anything needing a live third party stops. A real-time price from a supplier, a credit check, an online store's stock level — those need the internet and there is no way around it. What matters is that the rest of the system keeps working while they don't.

Printing needs care. Pair your label printer directly to the device over Bluetooth or USB. If printing routes through a server, you lose the ability to print a label at the exact moment you most need one. This is a setup decision, not a software feature, and it's easy to get wrong.

The two-minute test

Don't ask a vendor whether their system works offline. They will say yes. They will all say yes.

Ask them to prove it, in front of you, on your floor:

1. Turn off the wi-fi — or just pull the router's plug.
2. Receive a part. Pick a part. Print a label. Count a bin.
3. Watch whether each screen confirms instantly or hesitates.
4. Plug it back in.
5. Watch the queued work sync, and check the numbers landed correctly.

Two minutes. It settles the question more thoroughly than an afternoon of slides, and it is very hard to fake.

We bring the kit to your premises precisely so you can do things like this. When we're there, ask us to pull the plug — it's a fair test and we would rather you ran it with us standing next to you than discovered the answer in month three.