Choose one disconnected journey
For a first release, consider opening an assigned job, reading its checklist and recording a visit note. Android’s architecture guide recommends local data for critical offline reads. Turn that principle into a specific acceptance condition: the technician prepares the job before leaving, then can reopen its instructions without a connection.
List the actions outside this first version too. Assigning new work or confirming a changed appointment might require office approval. Explain that boundary on the relevant screen, and give the technician a useful next action instead of an unexplained disabled button.
Give each saved state a clear meaning
Write the status messages before drawing the screens. Use separate meanings for saved on this device, waiting to send, received by the office and needs attention. Agree what evidence allows each message to appear. A reassuring tick should never leave staff guessing whether a colleague can see the note.
In the job list, distinguish an empty schedule from a schedule that was never downloaded. In the note editor, keep the pending status beside the relevant entry. For a multilingual European team, translate these operational messages with the same care as the navigation.
Decide who may change each part of a job
Picture a dispatcher moving an appointment while a technician records a visit. Ask which details each role owns, whether both edits should survive, and who reviews a disagreement. Prefer an explicit decision for that situation over a general promise that everything will merge automatically.
Firestore synchronizes local changes after reconnection and uses last write wins for multiple changes to the same document. For this example, ask the development team to demonstrate that a scheduling update cannot silently erase a visit note. The business rule should guide the data design.
Include handover and unfinished work
Define what happens when a phone is handed to another employee with an unsent note. The next account must not inherit the previous person’s customer details or pending submissions. Agree how the original employee can recover unfinished work, and make the choice understandable before sign-out.
Treat photos and text as separately visible parts of the handover. If the note reaches the office but its photo does not, the interface should show that partial result. Give a named team role responsibility for items that continue to need attention.
Rehearse the job before launch
Run the same short scenario with a technician and a dispatcher on representative devices. Record the expected visible result for every step. Start with this checklist, then add the failures that matter to your own service process:
- Open a prepared job offline, then try one that was never downloaded.
- Save a note, close the app and check that the note can be recovered.
- Reconnect twice and confirm that the office receives one note, not duplicates.
- Change the appointment on another device and inspect both versions of the job.
- Change accounts with unfinished work and check ownership and visibility.