Why reps' orders vanish or double when they lose signal
A field app that works in the office can lose or duplicate orders out of signal. What has to be decided, in business terms, before an offline app is built.
Your sales reps visit customers all day. The app was specified with a line that says “must work offline”, priced as if it were a tick-box. In the office and on good signal it works. Then a rep goes into a basement stockroom, takes six orders, and at some point afterwards those orders are gone, or entered twice, or quietly older than a change the office made in the meantime.
The cost never shows up as an error message. It shows up as a customer who was told their order was taken and was not, a second delivery of the same order, or a price the rep promised that the office then changed. The dispute that follows is about money and trust, and nobody can say which version of the order is the real one.
What was actually going on
This is the usual result of building an online app and then adding a cache to it. “Works offline” is treated as a feature. It is really a promise about what the app does when there is no network, and it needs to be written down before the first screen is designed.
Three questions decide everything, and they are business questions.
What can a rep do with no connection? Not “everything”. Recording a visit, taking photographs and taking an order against a saved catalogue: yes. Checking a live credit limit, confirming a payment, or seeing a booking another person made ten minutes ago: no, and the app has to say so rather than showing old data as if it were current.
What happens to work done offline? It must survive the app being closed, the phone restarting and the battery dying. So each action is saved on the phone at the moment it happens, not held in memory until the signal returns.
Who wins when two people changed the same thing? That is a business decision that is often mistaken for a technical one, and answering it wrongly is how field apps quietly lose data.
What we recommended
This article is a set of design rules, not the report of one client’s incident. The rules are the ones the mobile app in Sazinga Field is written against.
The phone saves the order first and treats that as the finished action, so the rep never waits on the network. A background process then sends the saved changes to the office and reconciles what comes back. What the rep sees is as fresh as the last successful sync, and the app shows when that was. A quiet “last updated 40 minutes ago” prevents more support calls than hiding it.
Every saved change carries a reference number made on the phone. If the order reached the office and the reply was lost on the way back, the rep’s phone thinks it failed and tries again. The office recognises the same reference and returns the original result instead of creating a second order. That single property removes the most common cause of duplicates.
Changes are sent in order, retried with growing pauses, and capped. One that cannot be sent goes into a visible “needs attention” list for the rep to act on. Silently dropping it is how trust in an app dies. Photographs are compressed and sent separately, so a visit report never waits on a weak upload.
On conflicts, “whoever synced last wins” is what you get by not choosing. It is acceptable for a rep’s own visit notes and unacceptable for anything shared, because it silently erases the other person’s work. Two reps logging separate visits to the same dealer are not in conflict at all and should both be kept. Stock movements should be sent as changes, so two reductions both apply. A genuine clash on the same figure should be shown to a person with both versions side by side. Credit limits, prices, approvals and anything financial are decided by the office, and the app must cope with being told that the price it quoted has changed.
What it did not fix
An offline promise cannot make old information fresh. A rep out of signal cannot see a credit limit that changed an hour ago, and the office may still reprice an order the rep has already promised. The design makes that visible and recoverable. It does not make it disappear.
Nothing here describes a specific customer’s loss. It is the set of decisions that stops the six-orders-in-a-basement case turning into a dispute.
The pattern, for anyone commissioning a field app
Before you sign off a “works offline” requirement, get the answers to three questions in writing: what can a rep do with no signal, what happens to that work if the phone dies, and who wins when two people changed the same thing.
Then test the messy middle, not just flight mode. The failures live in a connection that is present but delivering nothing, a reply that arrives after the phone gave up, an app closed mid-sync, a login that expired over three days offline, a phone with the wrong clock. Try it on the phones your reps actually carry, on the network they actually have.
Where this ends up
The promise described here is the one the mobile app in Sazinga Field is written against, for dealers and field staff taking orders where there is no signal to fall back on.