Field service software — for installation, maintenance, inspection, surveying, collections — is built by people sitting at desks with good connectivity, for people standing in a factory, a basement, a rooftop or a village with one bar of signal. The gap between those two situations produces a consistent set of failures, and most of them are foreseeable rather than surprising.
Offline capability is the requirement, not a feature. The person in the field must be able to open their job list, record what they did, capture photographs, collect a signature and complete the visit with no connectivity at all, and have it synchronise later. Anything that requires a round trip at the moment of use will be worked around with paper, and once the paper habit forms it persists for years. The design consequence is that the device holds the day's work locally and reconciles afterwards, which is a different architecture from a web application with a mobile view.
Data entry has to be brutally minimal. A field engineer wearing gloves, holding a torch, standing on a ladder, is not typing paragraphs. Structured choices, defaults derived from context, numeric entry over text, photographs instead of descriptions, and voice notes where a description genuinely is needed. Every field on the form should have to justify itself, because the practical effect of a long form is fabricated data entered from memory in the van afterwards.
Photographs deserve specific attention because they are the primary evidence and the largest technical problem. They are large, they need capturing at usable quality, compressing on the device, queueing when offline, and uploading opportunistically when signal appears. A design that uploads at full resolution immediately will fail on mobile data and consume the engineer's allowance. Timestamping and geotagging them at capture, rather than at upload, is what makes them credible as proof of a visit.
Location is less reliable than product teams assume. GPS indoors, in basements and inside industrial buildings is poor to absent, so a workflow that requires the engineer to be verified at the site before they can record work will block legitimate visits. Treat location as evidence where available and never as a gate. The same applies to time — record the device's time and the server's, because devices drift and disputes about when a visit happened are common.
Finally, design the back office around exceptions rather than the happy path. Most visits complete normally and need no attention. What operations actually needs to see is the ones that did not: the visit not completed, the part unavailable, the customer absent, the job that took three times the estimate, the engineer whose day cannot be completed as scheduled. A dashboard showing everything is a dashboard nobody uses; one showing only what needs a decision is a tool. That single framing decision is usually the difference between adoption and a system that runs alongside a WhatsApp group.
