A Field Service App: What Must Work Offline and What Must Reach the Office

A field app is judged in an underground car park and in a basement with no signal, not in the office. The first requirement is that the technician can complete a job without a network, and the second is that everything they entered reaches the office by itself once signal returns - without them having to remember to press anything.

What must work without signal

The last row is the forgotten one: an app that requires tapping "send" will lose reports, because the technician is already driving to the next job.

What the technician actually fills in

The longer the form, the worse the quality of what is entered. What works: what the fault was from a short list, what was done from a short list, parts replaced from a catalogue, and one free-text field for everything else. Four fields.

Every additional field has to justify itself with one question: who reads this, and what do they do with it. A field nobody reads is time stolen from the technician on every job, and a reason they fill in the rest carelessly.

What must reach the office the same day?

1. Whether the job is closed or needs another visit.
2. What is needed next - a part, an approval, a call to the customer.
3. Parts consumed, so van stock and warehouse stock stay correct.
4. A signature or confirmation that the work was done.
5. Whether there is a sales opportunity - the technician sees things nobody else does.

Point 5 is the only field that returns money directly, and it is almost always missing. A technician who ticks "system is old, worth proposing a replacement" produces a better lead than any advertising.

Van stock - the forgotten part

Every technician has a small warehouse in their vehicle, and most businesses do not manage it. The result is familiar: a part that should have been in the van is not, an extra trip, and a customer waiting another day.

The minimum management that works: every part consumed on a job is deducted automatically from van stock, and every replenishment from the warehouse is recorded as a movement. It is exactly the logic described in inventory in a system versus a spreadsheet, applied to a location that moves.

What to check before choosing

• Genuine offline - ask for a demo in aeroplane mode, not an explanation.
• Hebrew and RTL in the app, including in free-text fields.
• One screen where the technician sees their day.
• Navigation that opens directly from the job address.
• On-screen signature, and where it is stored.
• Sync - how often, and what happens on a conflict.
• Battery consumption across a full working day.

The last sounds marginal and is not: an app that drains the battery by midday makes technicians stop using it, and that is the most common silent failure in field deployments.

What happens when it does not work

The technician goes back to paper and the office types it up in the evening. It looks like a solution and is worse than either alternative: information arrives late, some of it is lost, and the technician does the work twice - once on site and once on the phone with the office.

The early sign is reports that all arrive at exactly the end of the day. That means somebody is sitting down and filling them in from memory, which is precisely when the record stops being accurate - and from that moment stock, hours and customer history all start drifting from reality.

What the office has to give the technician back

Adoption depends on the reverse direction: what the technician receives, not only what they fill in. Three things change attitudes to an app more than any training:

• A day laid out in advance - jobs in a sensible geographic order, with an address that opens in navigation.
• Information that saves a phone call - the model, when it was installed, what was done last time, and who the actual contact is.
• Fewer calls from the office - when the status updates itself, nobody needs to ring and ask where they are.

The third is what technicians mention first when the system works, and nobody thinks of it in advance.

What the customer should receive

The forgotten side is the customer, and it is exactly where a field app repays the investment in service. Three simple messages remove most inbound enquiries: confirmation that the job was logged and when it is scheduled, a message when the technician is on the way, and a short summary by email or message afterwards - what was done and what is still needed.

The third is worth the most and is implemented least. A written summary prevents the "what did you actually do at my place" conversation, and serves as evidence when a dispute surfaces two months later. It also creates a natural moment to ask for a review, at the point the customer is happiest.

Pricing a job correctly

The fields the technician fills in are also the basis for billing, so decide in advance exactly what you charge for: the call-out, hours, parts, travel, or a combination. That decision determines which fields must be accurate - and above all, what counts as "an hour" when the technician drove for forty minutes and was on site for twenty.

Businesses that do not settle this discover two unpleasant things: invoices reaching customers with numbers they query, and technicians recording hours differently from each other. Two lines in one procedure solve both.

Sources

• Fireberry by Powerlink - mobile app
• Kala CRM - ticket management and communication