Field Technicians: What a Service and Maintenance App Needs to Do

A service report written by hand, photographed, and retyped in the office isn’t a paper problem: it’s a problem of time and completeness. The information arrives two days later, incomplete, and the invoice goes out a week later because the materials used are missing. An app for technicians exists to fix that, not to digitize a form.

The opposite risk is squeezing the entire business management system onto a six-inch screen, made worse by the fact that the technician will use it standing up, wearing gloves, in a boiler room with no signal. What’s needed isn’t a smaller business management system: it’s a path reduced to field operations.

The full loop of a service call

Before choosing any tool, it’s worth writing out the path, because that’s where you can see where information gets lost.

1. The office receives a request and assigns it: who, when, where, with what priority.
2. The technician receives the service call with everything they need before setting out.
3. On site, they record what they did, the materials used, the times, and what they observed.
4. The customer confirms. The report closes and becomes a document.
5. The office already has the data to invoice, to reorder spare parts, and to schedule the next service call.

If even a single one of these steps reverts to being a phone call, the chain breaks and the data gets reconstructed from memory.

What the technician needs to find already written down

Calls to the office from the site are the best indicator of what’s missing from the assignment: every recurring call is a field to add.

• Who to contact on arrival, with a direct phone number, and how to get in: reception, hours, keys, permits.
• What was promised to the customer, and by whom. It’s the most frequent cause of on-site disputes.
• The system’s history: previous service calls, parts already replaced, known issues.
• The system’s data: serial number, model, physical location, documentation on file.
• Whether the service call is under warranty, under contract, or billable. Knowing this in advance, the technician doesn’t promise what they shouldn’t.

What needs to be recordable, and in how many taps

The criterion isn’t the number of fields but the number of actions. A report that takes four minutes of typing gets filled in from the car at the end of the day, and at that point paper would do just as well.

• Materials: picked from a list of recurring spare parts, not typed by hand. Free typing makes the data useless for inventory.
• Times: start and finish recorded with one tap, and correctable. If typing the times is the only option, they’ll be rounded off and inaccurate.
• Photos: before and after, already linked to the service call. A photo left in the phone’s gallery is a photo that’s lost.
• Notes: a free-text field is useful, but whatever needs to be readable by a system — outcome, cause, system status — needs to be picked from a short list.
• Issues to flag to the office: the part that’s usually missing, and the one worth the follow-up jobs.

No signal: working without a connection

Basements, shielded warehouses, industrial areas, mountains: the connection is missing exactly where the work happens. An app that requires a connection to function gets abandoned by the second time. An illustrative sequence of one day.

1. In the morning, where there’s signal, the app downloads the day’s service calls along with records and history. From that point on, everything works even without a connection.
2. At 9:40, the technician opens the service call in a basement equipment room, with no signal: they fill it in, take photos, add the materials. The data stays on the phone.
3. At 11:15, the office cancels the 3pm service call and assigns a different one. The technician doesn’t know: they have no signal.
4. At 12:30, coverage returns. The morning’s report goes out, the new assignments come in, and the technician gets a visible notice that something has changed.
5. A case to decide on in advance: the spare part the technician used turns out to have been assigned to a different service call. The conflict doesn’t resolve itself, it needs to be shown to a person.

Two rules prevent most of the problems. The technician needs to always be able to see whether their data has gone out or is still sitting on the phone. And data that hasn’t synced yet must never be able to disappear because of an app update, a device change, or an expired login.

Customer signature and administrative closing

A signature taken on site holds up if it’s clear what’s being signed and if the customer receives a copy of it. It also serves as proof in case of a dispute, so the document must not depend on the phone of whoever was on duty.

• What the customer sees before signing: work performed, materials, times, and anything left unresolved, with the reason.
• What happens if the customer isn’t there or refuses to sign: the service call closes anyway, with a note.
• What the customer receives, in what form, and who sends it to them.
• What reaches administration, and when. If the handoff still requires retyping, the problem has been moved, not solved.

When an app isn’t needed

Not every crew needs one, and for some it would just be extra weight.

• Few, long service calls, with an extensive technical report that gets written in the office anyway: the benefit is marginal.
• The business management system has no way to receive the data. Without that connection, the app creates a second archive that has to be reconciled by hand: two versions of the truth instead of one.
• The process isn’t stable. If assignment changes every week and nobody can say who decides priorities, the app will just lock the current disorder in place.
• The devices haven’t been decided yet. Personal phones, different operating systems, small screens, and gloves all change the technical choices, and need to be tested on the actual models technicians have in hand.

What this guide doesn’t cover

This guide covers the field process and the information it needs to produce. The technical choice — an app to install, a website that also works offline, or something in between — depends on the devices in use and needs to be verified on those, not decided in the abstract. Tracking inventory movements and the tests to run before rolling out company software are covered separately.