Field service apps: what technicians actually need

Field service app development goes wrong when the app is designed for the office. Managers want dashboards, timesheets, chat and a map of every technician; technicians want to see today's jobs, get there, do the work, prove it, collect payment and go home without the app losing anything. The gap between those two lists explains most of the field apps that are abandoned for WhatsApp within a month. This article sets out what a technician mobile app must do, in the order that matters, and how to build one that field staff keep using.

Who the app is for, and what a day looks like

A technician or delivery agent starts the day with a list of jobs and an approximate route. They travel, often on two wheels, with the phone in a pocket or on a mount. At each stop they need the customer's details, the job's history, what parts or items are involved, and a fast way to record what happened: photos, readings, a signature, a payment. Between stops connectivity drops in lifts, basements and industrial estates. At the end of the day they need to know their jobs are recorded and their earnings are right. Design for that day, on that device, in that light, with those gloves.

The five core flows and the rest

Offline routes are the first requirement

The day's jobs, customer details, history and any documents must be on the device before the technician leaves the depot or their home. The app loads the working set at shift start and refreshes when connected, but never blocks a job on the network. Navigation hands off to the maps app the technician already uses, with the address and a pin, because a custom map is a maintenance burden and usually worse. Re-sequencing from dispatch arrives as a clear notification with the reason, and the technician can see the old and new order. Our offline-first mobile apps guide covers the local database and sync engine under this.

Proof of delivery in one screen

A proof of delivery app lives or dies on the completion screen. The pattern that works: a single screen with a large signature area, a photo button with a guide overlay, an optional customer OTP for high-value deliveries, and automatic capture of time and location. Submitting queues the proof locally and moves on; the upload happens in the background. Every extra mandatory field costs adoption, so the business must justify each one by naming the report or decision that uses it. Photos are compressed on device to a size the business has agreed and uploaded resumably so a weak signal does not restart them.

Checklists that adapt to the job

A boiler service, a meter installation and a parcel drop need different steps, so checklists are configured per job type by the operations team, not hard-coded. Each step can require a photo, a reading or a confirmation, and the app enforces only the steps the business has marked as required. When a step cannot be completed, the technician records a reason from a short list, which becomes an exception the office can act on. Configurable checklists are what let the same app serve new service lines without a release.

Payments on site

Technicians and delivery agents collect money, and the app must make that easy and auditable. Show a UPI QR code or send a payment link, let the customer pay from their own phone, and confirm on the technician's screen through the backend's webhook rather than trusting a screenshot. Record cash explicitly with a running total the technician can see, so end-of-day reconciliation is not a surprise. Refunds and price changes on site go through a quote flow with an approval rule, not a free-text amount field. The client integration is covered in payments in mobile apps in India.

Design for the conditions

• Large touch targets and high contrast for sunlight and gloves
• Voice notes and speech-to-text for observations, because typing on site is slow
• Camera guidance overlays so photos are usable the first time
• Minimal navigation depth: the current job is always one tap away
• Battery discipline: location sampling scaled to movement, sync batched
• Local language interfaces for the whole field workforce, not just English
• Works on the devices the workforce actually has, including older Android

Sync status and trust

The support call that field apps generate most is "did it save?". Answer it in the interface: a quiet indicator showing pending items, a screen listing what is waiting to sync, and a clear message when something has failed permanently and needs the technician's attention. Nothing should ever be silently discarded. Once technicians trust that the app keeps their work, they stop taking screenshots as insurance and stop calling the office.

What the office gets

The office side is not neglected; it is fed by the field app rather than imposed on it. Dispatch sees job progress within seconds of connectivity, exceptions (missed, delayed, disputed) rise to the top, proof and payments flow into the back office and reconciliation, and management reports come from the same data. For a service business, this back office is often a CRM or field-service module; the CRM for service businesses article covers that side, and TheEazy CXM, our group's CRM product, is one place it can live.

A worked example

A last-mile logistics operator's drivers were using a mix of a legacy app, paper manifests and WhatsApp photos, and dispatch spent its afternoons phoning drivers for status. We built a React Native driver app around the five core flows: the day's route loaded offline at shift start, one-tap navigation, a single proof-of-delivery screen with photo, signature and OTP, UPI and cash collection with a running total, and a visible sync state. Location updates were throttled to protect battery, and a dispatch console received progress and exceptions in near real time. Drivers adopted it because it was faster than paper, dispatch stopped phoning for updates, and end-of-day cash reconciliation became a report rather than an argument. The dispatch platform and driver app case study describes the full build.

Team and timeline

A field workforce app is typically two mobile engineers, a backend engineer for the sync API, dispatch integration and payments, a designer who has done field research, and a QA engineer who tests on real devices and networks, over ten to fourteen weeks to a piloted release. It sits under our React Native mobile development service from $17,500 / ₹11.2L; the dispatch console and back office are scoped under product and platform development from $42,000 / ₹28L. A ten-day Sprint Zero at $3,250 / ₹2,00,000 includes ride-alongs with technicians and produces the flow designs and a fixed quote. Details on the pricing page.

Before you start: a checklist

• Spend a day in the field with technicians before writing any requirement
• List the five core flows and freeze the mandatory fields for each
• Decide what data loads at shift start and how it refreshes
• Choose the proof-of-delivery elements per job type: photo, signature, OTP, geotag
• Agree the on-site payment methods and the cash reconciliation process
• Set battery and location-sampling rules with the operations team
• Confirm target devices, languages and the pilot group
• Define the dispatch console's exception list before building dashboards

Questions clients ask

• Should we track technician location continuously? Sample by movement and job state, not on a fixed short interval; continuous tracking drains batteries and technicians switch it off.
• Can technicians use their own phones? Usually yes if the app supports the Android versions in the fleet; provide devices for roles that need specific hardware like printers or scanners.
• How do we handle price changes on site? Through a quote flow with approval rules, so the customer sees a proper revised quote and the office keeps control.
• Do we need chat in the app? Rarely at first; a call button and structured exceptions cover most needs, and chat can be added once the core is trusted.

Related reading

Read building an offline-first driver app for the logistics version, merchant and partner onboarding as a product for how field partners get into the system, and push notifications that users keep on for dispatch alerts that technicians do not mute. Android's background work guidance is the primary reference for keeping sync and location within platform limits.

Build the five flows a technician uses every hour, make them work without a network, and the office reports will follow from the data.