A field team needs a working app when the signal drops

Why field apps fail in the field

Testing a field app only in the office on good Wi-Fi misses the conditions it must survive. In the field, a technician in a car park basement taps “Submit”, sees a spinner, taps again, gives up and calls the office. Later the phone reconnects and sends both submissions. Or the app quietly loses the photos. After a few such days, the team goes back to WhatsApp photos and paper job sheets, and the app becomes another thing the office has to chase.

The underlying problems are predictable:

• Offline capture: can the form, photos and signature be saved without a connection?

• Delayed sync: when the connection returns, does the data upload reliably, in order, without the user doing anything?

• Duplicates: does a retry create a second record?

• Conflicts: what if the office reassigns or edits the job while the technician is offline?

• Visibility: does the device show pending updates, and does the office show the last confirmed status and when it was received?

An illustrative example: a maintenance job in a basement plant room

An illustrative example, not a real client: consider a hypothetical facilities maintenance contractor in Dubai with technicians covering residential towers under annual maintenance contracts. A chiller fault is reported at 10:00. The office assigns job FM-2231 to a technician, who receives it while still above ground.

• 10:40: the technician reaches the basement plant room. No signal. The app still opens the job from the copy saved on the phone.

• 10:45 to 11:30: they record findings, take six photos, note a replaced part (one contactor, with a part number), and capture the building engineer’s signature. Each step is saved on the device. The job shows “Completed, waiting to sync”.

• 11:05: meanwhile, the office receives a call from the building management saying a second unit is also noisy, and edits FM-2231 to add a note and raise priority.

• 11:35: the technician taps “Submit” twice out of habit. Because the app gave the submission a unique ID when it was created, the second tap does nothing new.

• 11:50: back at ground level, the phone reconnects and syncs.

Now the conflict. The office edited the job’s notes and priority; the technician edited status, findings and parts. The agreed rule for this contractor:

• Status, findings, parts, photos and signature: the technician’s version wins, because they were there.

• Assignment, priority and customer notes: the office’s version wins.

• If both changed the same field, keep both values and flag the job for the supervisor.

Here, nothing overlaps. The job merges cleanly: completed, with the office note about the second unit now visible to the technician, who is still on site and can check it before leaving.

Without these rules, the most likely outcomes would have been two completion records, an overwritten office note, or a job that showed “Assigned” in the office until the technician phoned in.

Until 11:50, the office dashboard showed “Last synced 10:38; last confirmed status: assigned”. The technician’s phone showed the newer work and its pending sync. The office could see that its information was old, but could not infer whether the job had started or how much unsynced work existed. Once sync succeeded, it showed the confirmed completion and the recorded event times.

A field-readiness test

Run this with two real technicians before rollout:

1. Put a phone in airplane mode. Can the technician open today’s jobs and complete one fully, including photos and signature?

2. Close and reopen the app while offline. Is the work still there?

3. Reconnect. Does it sync without the technician doing anything?

4. Tap submit several times while offline. How many records reach the office?

5. Edit the same job from the office while the phone is offline. Is the result what your conflict rule says?

6. Fill the phone’s storage or use a low-end device. What fails, and does the user see it?

7. Does the device show its pending updates, while the office shows each device’s last contact and clearly marks subsequent progress as unknown?

8. If a sync fails permanently, who is told and what do they do?

Expect to find failures. That is the purpose. Fix them before adding a second task.

Start with one task

The temptation is to build everything at once: scheduling, quotes, inventory, timesheets, customer signatures, analytics. Start with the one task that causes the most chasing, usually job completion with evidence. When that works offline and the office trusts it, the next task, such as parts used against van stock, is much easier to add. A fuller operating system is worth considering when jobs, parts, contracts and invoicing are all being reconciled by hand across several tools.

Where SolvTree fits

This maps to our custom systems, specifically field apps built around how your technicians and site teams actually work, with offline capture, sync and conflict rules agreed up front. We would start with one field task, test it in the conditions where it usually breaks, and widen from there.

Next step: Book a free 30-minute operational audit and we will map one field task and its failure conditions with you. The report is yours to keep.