Offline work in the field — a real requirement or a convenient excuse

"Our people work where there is no signal" comes up in almost every conversation about a rollout. Sometimes it describes reality. Sometimes somebody heard it from a foreman, passed it on, and never checked.

The difference is expensive: full offline working is one of the few items that can push a start date back by a quarter.

Requirement or excuse#

In the companies we talk to, that sentence does two different jobs.

Sometimes it states a fact. Crews going down into basements and plant rooms, installation in steel-framed halls, sites where the network ends a kilometre before the gate. Predictable and daily.

Sometimes it closes an uncomfortable conversation. If the system needs a network and the network is "never there", nobody can ask for an end-of-day report either. Honest and untrue at once.

A third case is the most common of the three: there is coverage, it is just weak, and the app handles that worse than no signal at all. It spins, loses the typed-in form, makes you start again. The fix is not offline mode but decent behaviour on a bad connection.

How to measure whether you really lose signal#

No software is needed. Two weeks and one table are.

Ask for a note, not an opinion. Four columns: date, place, minutes, what they were trying to do. Asked in conversation, the answer is "constantly". Written down, it is a number.

The last column decides. Not how often the network dropped, but how often it dropped while someone needed the system. Losing signal between sites costs nothing.

Separate reads from writes. "I wanted to check the address" and "I wanted to close the job" are two problems with two very different prices.

Count minutes, not incidents. Three minutes in a lift and four hours in a plant room are not one line item.

Suppose twelve crews log a dozen gaps a month, mostly short and mostly reads: that is no case for full offline. If three of them spend half a day off the network and file the most reports, the answer changes for those three crews, not the company.

Level one: reading from a local cache#

The app keeps what it last downloaded and shows it when there is no network: today's jobs, addresses, site history, photos from the previous visit.

That covers most gaps in your table: in the field, information is needed far more often than the ability to enter it. It is also the cheapest level, because read-only data creates no conflicts; the only decision is what to fetch in advance.

One thing has to be right — show when the data was last refreshed. Stale data shown as current is worse than a blunt connection error. An engineer who drove to an address changed yesterday will not trust that screen again.

Level two: queueing writes#

The completed form, the photo and the status change do not go straight to the server. They land in a queue on the device and leave when the network returns.

That covers the case which happens most: not a whole day offline, but the connection dropping on submit. Five minutes of typing cannot vanish because someone stepped into a lift.

Most of the cost sits in the interface, not the synchronisation. A queue you cannot see is worse than none — nobody knows whether it went, so they send it twice. Three things must be visible without hunting: how many items wait, when something last got through, what to do with one that will not go. The last is skipped most often, and it generates calls to the coordinator.

Level three: full disconnected working#

A whole day with no network. People create records, edit existing ones, reach for data nobody downloaded before setting off; in the evening everything synchronises both ways.

This is not a longer version of level two. It is a different architecture, one in which the device stops being a window onto the system and becomes a copy of it. Three things have to be settled.

What sits on the device. Company data on a phone that can be lost or left in a van — a decision about scope, and about losing the hardware.

Who issues identifiers. Two crews create a new job offline. Both numbers are made on the device and must not collide once everything syncs.

How conflicts are resolved. The section below.

The cost runs in months rather than weeks, and it does not end at handover: every feature added later has to work disconnected too. That is a tax on the whole rollout, not a line in the quote — which is why full offline belongs in the architecture discussion, not on a wish list.

Conflicts: the bill that arrives after the rollout#

A conflict is the same thing changed in two places before those places met. Someone has to decide which version survives.

The simplest rule — the later write wins — is also the worst, because it is silent. A conflict in a text field is sometimes noticeable; one in a number never is. Hours worked, materials used and quantities on a completion sheet look equally credible afterwards, whichever won.

Conflicts are better avoided than resolved: appending rather than overwriting, a separate entry per person rather than one shared field, a status changed by one role, not three. Those are decisions about the shape of the data, made at the start rather than at sync time.

A separate matter, if the system runs an agent that acts once a person approves. An approval given offline describes the state of things hours earlier, so queued actions are proposals worth a second look, not instructions awaiting dispatch.

Summary#

Start with level one: cheap, and it covers most of what happens. Add level two, which protects work somebody has already done. Choose level three only with measurements behind it, narrowed to the crews it concerns.

The common mistake is not picking the wrong level but accepting the requirement without checking it. Two weeks of notes cost less than one scoping meeting, and usually change its conclusion.

The other conditions that have to be met before a crew will open the app at all are in the guide on managing field teams.