Field-service photos: keep evidence on the visit, even offline

A field photo is evidence of a visit, not a gallery item. If an MVP stores pictures against the technician or the last opened job, a delayed sync can attach yesterday's boiler to today's customer. For a first release, give every visit a stable identity and make the photo belong to that visit before the file leaves the phone.

1. 01

   Consider a technician who photographs a meter, loses signal in a basement, then opens the next job in the van. If the camera roll is a shared inbox, both jobs may receive the same upload or neither may. The first workflow is smaller: the technician opens a visit, captures a photo into that visit, and can see a local pending state until the file is confirmed on the server.

2. 02

   Create the photo record on the device with the visit identifier, a local file reference and a unique upload identifier. Sync can then retry the same record instead of creating a second photo. Do not wait for a network round-trip before the technician is allowed to leave the site; waiting for upload is how people save pictures to the camera roll and lose the link. Show pending, uploaded and failed as separate states. Failed must remain on the visit, not disappear into a generic retry list.

3. 03

   Decide what the photo proves. Before, after and parts used are different claims. If the operating process needs a before photo, make that requirement visible on the visit rather than hoping people remember. A missing required photo should block a complete-job action, not a save of notes. Completing a job without its required evidence creates a support problem that looks like a missing file later.

4. 04

   Keep customer identity out of the filename and the notification. The visit record already knows the customer. If another person can see the lock screen, a thumbnail with a house number or a name is unnecessary exposure. On a shared company phone, the signed-in technician must not inherit another person's pending uploads. Sign-out should either finish uploading under the original visit or keep those files queued against that visit, not dump them into the next login.

5. 05

   An MVP can skip automatic album layout and AI damage labels. The tradeoff is a plainer visit screen in exchange for a reliable attachment. Add captions only when they are stored with the photo record. If a supervisor later reviews the job, they should see the visit, the timestamp the photo was captured, and whether upload is still pending. A server timestamp of arrival is not the same as the moment on site.

6. 06

   Test the sequence without pretending the network is perfect. Capture two photos offline, complete the visit, open a second job, regain signal, and retry a failed upload. Interrupt the app after capture and reopen it. Confirm both photos remain on the first visit and that the second job has none of them. Include a photo captured after the visit was marked complete if your process allows a late add; if it does not, the product should refuse and say why.

7. 07

   For the pilot, measure visits closed with required photos pending, uploads that retried successfully, photos attached to the wrong visit, and support contacts about missing evidence. Do not put customer addresses or image contents into general analytics. Review a sample of completed jobs with the dispatcher. The useful result is a visit that still explains what was seen on site after the technician has moved on and the signal has returned.