No reception. Can your employee still record the work properly?

Your employee reaches the customer's storeroom and opens the business app, but the phone has lost its connection. The visit needs to be recorded before they leave. A tick appears beside the note. Does that mean it is saved on the device, received by the office or accepted as completed work? A useful mobile application gives a clear answer and a practical next action.

Start with one complete responsibility. Decide what information the employee must have beforehand, what they may record independently and which commitments need current confirmation. That turns offline working into a defined design brief that people can test in their actual working conditions.

Illustrated employees with a tablet and checklist in an equipment storeroom.

Decide what can continue without reception

Consider a fictional equipment hire business. During a service visit, an employee checks the accessories supplied with a machine. Reception disappears inside the storeroom. They want to record a missing carrying case and keep a photograph. Meanwhile, an office colleague changes the next appointment.

The observation and the appointment have different consequences. An employee may be able to capture what they see without consulting anyone. Confirming a new visit requires current scheduling information and the authority to make that commitment. Design separate actions instead of applying one ‘offline available’ label to the whole application.

Employee action Decision needed before implementation
Read visit information What must be loaded beforehand, and how old may it be?
Record an observation Where is the draft kept, and how is that state shown?
Attach a photograph How are local storage and confirmed receipt distinguished?
Change an appointment Which current check makes the change final?

This is a design proposal, not a description of an existing product. The Android guidance on offline applications treats reading, writing and reconciling local and network data as separate concerns. An application does not have to support every offline write to provide useful offline functionality.

Explain the limits of the device's information

A previously loaded assignment may remain readable after the office has changed it. Show when relevant information was updated and agree how long it can support a decision. A general equipment description and a recently changed appointment need different treatment.

Include the first time someone opens an assignment. A demonstration with previously loaded records does not prove that a new visit will be available on the road. Let employees check which assignments and attachments are ready before travelling. An empty local list must not imply that the business has assigned no work.

The Firestore offline access documentation gives a concrete example: offline queries use cached documents and can return an empty result when none are cached. That result does not establish that the central schedule is empty. The product needs to communicate the difference in terms the employee can use.

Make each confirmation precise

‘Saved on this device’ should describe local storage within the application's agreed limits. ‘Received by the office’ needs evidence from the receiving application. ‘Completed’ should refer to a defined business step, such as a reviewed visit report. Employees should not have to infer which meaning a green tick represents.

Treat the note and its photograph separately when their transfers are separate. The text might arrive while the image remains outstanding. Show both results and explain the next action. Creating another visit record should not be the employee's way of finding out whether the original attachment arrived.

Agree who follows up outstanding submissions. If the app must be reopened to continue a transfer, include that in the instructions and acceptance test. Do not promise automatic background delivery until it has been demonstrated on the intended devices and application versions.

Resolve differences without losing context

Connectivity returning is a technical event, not a decision about the work. In the equipment example, the employee's observation and the office's appointment change may both be valid. Replacing the whole record with whichever copy arrives last could discard information a colleague still needs.

Choose an approach for each kind of change. An observation might be added as a separate entry. An appointment change might need checking against the current version before acceptance. A genuine conflict should give an authorised colleague both proposals and their context, while retaining the employee's original draft.

Firestore documents ‘last write wins’ behaviour for multiple changes to the same document. That behaviour does not decide which business commitment should stand. Ask your technical partner to demonstrate how version checks, separate observations and confirmation preserve the agreed rules. Test the whole visit, including a concurrent office change.

Include device handovers and support

What happens when another employee takes over a shared phone, someone signs out or the device needs replacement? Make unreceived work visible before those actions. Provide a supported recovery route and explain which actions could remove a local draft.

Take only the information needed for the task onto the device. Agree access, retention and removal with the people responsible for the application and devices. Independence requires both the means to continue carefully and a clear understanding of when missing information makes help necessary.

Ask about existing workarounds without treating them as misconduct. A paper note may reveal exactly what the current application fails to preserve. Use that knowledge to improve the design. Employees should not carry the consequences of working conditions that the application was never designed to handle.

Rehearse a complete visit

Use fictional records in a safe test environment. Start online, load a visit and disconnect the network. Record a note and photograph, close the application and reopen it. Check what remains. Meanwhile, have an office colleague change the next appointment. Restore connectivity and compare what both sides receive.

Repeat with an assignment that was never loaded and an interrupted photograph transfer. Open the received image in the office application. A successful text submission does not prove that its attachment arrived. Use the intended devices and prevent real customer messages or orders during the test.

Before expanding the rollout, agree which limitations must be resolved and who handles outstanding questions. A narrower capability that people understand can be more useful than a broad promise that fails during an ordinary visit. The acceptance decision should reflect what employees can actually finish.

Our mobile application work connects employee actions with data, permissions and the business platform. Bring one visit that becomes difficult when reception fails. We can establish what must be available beforehand, what can continue independently and which confirmation genuinely completes the responsibility.

Your next step

What do you want to make possible?

You do not need a software specification to start.

Talk about your next step