When a dropped photo costs a rep their bonus

A field rep is usually paid on what a retail-execution app records, not on what they did in the aisle. So when an update loses a photo from a finished mission, clears answers the rep already entered, or reports a mission count to the manager's dashboard that the phone doesn't show, the rep loses credit for real work. The persistence bug is small; because it sits upstream of incentive pay, it lands as a payroll dispute.

What are reps actually reporting?

GoSpotCheck by FORM is not a fringe tool. As of June 2026 it holds 4.4 out of 5 from roughly 24,000 ratings on the US App Store, about 4.1 out of 5 on Google Play, where it has been live since 2013, and 4.6 out of 5 on G2. This is a mature, generally well-liked field-execution app. That is exactly why the specific complaints repay a close read: they are not a verdict on the product, they are a map of one narrow, high-severity failure that a strong aggregate score hides.

Read past the average and a cluster of reviews describes the same sequence. An update lands, and the app loses work the rep already did. In their words, it

drops photos from missions

and, separately, it

will make users re-answer questions… because it cleared the answers

In a note-taking app that would be an annoyance. Here it is a pay event, because the same reviewers are explicit about what the retakes are for — they redo the work

to get credit and be paid

and because the back office does not see what the phone sees: mission counts that

won't show accurately in managers' computers

Reading app-store reviews as field telemetry rather than as star ratings is the same exercise we ran in reading enterprise loyalty reviews for the failure modes a vendor never demos.

Why does a persistence bug become a payroll dispute?

Retail-execution data rarely stays in retail execution. Mission completion feeds compliance scores, planogram-adherence rates, SPIFF and bonus calculations, and in many field organisations it is the primary input to variable pay. The moment a data point decides money, its failure modes change category. A lost photo is no longer a UX defect; it is a rep who did the work, cannot prove it, and is short on their next cheque. The engineering severity of the bug and the human severity of its consequence are owned by two different people, and the one who feels it has access to neither.

This is the quiet reason field apps are harder than they look. The correctness bar is not 'the screen renders'. It is 'the number that reaches payroll equals the work that happened in the store', across app updates, flaky retail Wi-Fi, and a back-office aggregation the rep never sees. Most of the reported failures live in the gap between those two clauses.

Where does the data actually get lost?

Three distinct surfaces show up in the reviews, and they fail for different reasons:

• Local persistence across updates. Photos and answers captured offline sit in a client-side store until they sync. If an app update ships a schema migration that doesn't carry that store forward, or invalidates a cache it assumed was already flushed, the un-synced work is gone. The rep sees a mission that reads as incomplete; the bytes are simply no longer there.
• Upload without acknowledgement. A capture is durable only once the server has confirmed receipt and the client has recorded that confirmation. If the app marks a photo 'uploaded' on request send rather than on server ack, or drops the ack on a dropped connection, you get a split brain: the phone believes it succeeded, the server never received it, and nobody is told.
• Reconciliation divergence. The count on the phone is an optimistic local tally; the count on the manager's dashboard is a server-side aggregate, often assembled by a different path. With no single record of truth and no convergence guarantee, the two drift, which is precisely the 'won't show accurately in managers' computers' symptom.

Why is 'just retake it' the wrong recovery?

Every one of those failures has the same remedy in the reviews: the rep does it again. That is the design smell. When the recovery path for a sync failure is a human re-performing physical work, the system has quietly appointed the field rep as its retry loop and its reconciliation process. It is a bad appointment on three counts. The rep is paid on the output, so the cost of the retry lands on them. They may be in a store they cannot revisit today, so the retry is sometimes simply impossible. And they hold no receipt, nothing that proves the first attempt happened, so a dispute becomes their word against an aggregate. A durable system never makes the person the retry mechanism; it retries itself, idempotently, and hands the human a receipt.

Why does the dashboard disagree with the phone?

The mobile-versus-manager mismatch deserves its own diagnosis, because it is the failure most likely to turn into an argument. Two systems are each computing 'the truth': the device holds an immediate, optimistic count, and the back office holds a delayed aggregate. If those are two separate calculations over two separate stores, they are guaranteed to disagree during the window between capture and settlement, and if an incentive report is pulled inside that window, the rep is scored on stale numbers. It is the same shape as the delay we picked apart in a loyalty balance a customer earned yesterday and won't see until tomorrow: the record exists, but the number the person is judged by hasn't caught up. And when the fix then has to route through a single overloaded queue, small divergences sit unresolved for weeks, which is the constraint we described in the integration team everyone waits for.

The direction out is unglamorous and well understood: acknowledge-once upload, where a capture becomes durable only after a server receipt the client records; idempotent submission keyed to rep, mission and timestamp, so a retry can never lose a record or double-count one; and one projection feeding both the phone and the dashboard, so 'done' means the same thing in both places. Put the mission event on a shared bus that order capture, stock and incentive calculation all read, and the manager's number stops being a second opinion, it is the same event seen a moment later. That is the spine of the event-driven platform we build for brewers.

As field teams move onto image recognition and AI-scored execution, the amount of money hanging off a single capture only grows: a photo no longer just proves a display existed, it computes a share-of-shelf figure that settles a trade-spend claim. The apps that earn trust in that world will be the ones that treat every capture as a financial event from the moment the shutter fires, with a receipt the rep can hold, rather than as a form field an update is free to clear.