Does a field technician app need to work offline?

Yes, and more completely than most apps. Reading the job, capturing photos, filling the form and taking a signature all have to work with no signal, with the app queueing everything and syncing when it can. The common mistake is making reading work offline but not writing, which means the technician can see the job but cannot close it.

What should be in a job packet?

Address and access details including gate codes and keyholder, the asset and its service history, the parts the job is expected to need, the on-site contact rather than head office, and photos from the previous visit. Each of these is something technicians routinely phone the office about, which is exactly the phone call that fails where the work happens.

How does an app reduce second visits?

By recording parts against the asset rather than only against the job. Once you know what a given model of unit has consumed across previous visits, the job packet can carry those parts before anyone thinks to ask for them. The same record gives you van stock for free, since what left the depot minus what was fitted is what is still on board.

Should a small field business build its own technician app?

It is worth considering when your visits do not fit a packaged job model: one visit covering several assets, a certificate with trade-specific fields, or a sign-off chain that crosses two companies. The clearest signal is a paper form still being carried alongside the app you pay for, because that form is the part the software never held.

Articles · App ExamplesUpdated September 2026

A field technician app is judged in the basement, not the office.

Q: Is a signature captured on a phone legally valid?

In the United States, the E-SIGN Act provides that a signature, contract or other record relating to a transaction in interstate commerce may not be denied legal effect, validity or enforceability solely because it is in electronic form. What matters in practice is the context you store with it: who signed, when, against which job, and what they were shown at the time.

Any field technician app looks capable on a desk. The ones that survive a plant room, a crawl space or a fourth-floor riser are the ones that assume the connection is already gone by the time the technician arrives. That single assumption changes almost every decision in the build, which is why this page is narrower than field service apps in general.

What follows is the part people skip: what has to be on the phone before the van leaves, what the technician has to be able to record with no bars, and why the second visit is the most expensive thing your app can fail to prevent.

See what a job packet has to hold

The short version

The packet leaves with the van, and the evidence comes back with the technician.

A field technician app has two jobs and they run in opposite directions. Before the visit it has to push everything the technician could possibly need onto the device, because afterwards there is no network to ask. During and after the visit it has to capture what happened in a form that survives being written in a dark room on a cracked screen, and hold it until there is signal to send it.

Everything else, the scheduling, the invoicing, the dashboard, is downstream. Get those two right and the rest is ordinary software. Get them wrong and you have built a very expensive way for someone to write on their hand.

What a job packet has to hold before the van leaves

A job packet is everything about one visit, downloaded and readable with the phone in airplane mode. Not a link to it. Not a summary with a Load more button. The whole thing, on the device, because the moment the technician needs it is the moment they are standing somewhere with thick walls.

The five things that are always missing

Access details, asset history, expected parts, the on-site contact, and photos from the last visit. Every field business discovers this list the hard way, one wasted morning at a time. A work order app that holds only the description of the fault is holding about a third of what the technician actually needs.

Size it for the whole day, not the next job

Downloading a packet when the job is opened sounds efficient and fails in practice, because the technician opens job three while parked underground. Sync the whole day at the depot or at the first good signal, and make it obvious which jobs are ready to work offline and which are not.

Try it

What is in the packet when the signal goes

Tick what your app downloads before the technician leaves. Everything left unticked is a phone call from a place with no bars.

3 gaps the technician finds on site

The same diagnosis is repeated from scratch, and the intermittent fault stays intermittent.
A second visit. The most expensive line item in field service, and it never appears on an invoice.
Nobody can tell whether the damage is new, which turns a warranty question into an argument.

The record the technician brings back

On site, the app is a recorder. Readings, photos, parts fitted, time on the job, and a signature from whoever is there. The temptation is to make all of it optional so nothing blocks the technician. That produces jobs closed with nothing attached, and a business that cannot answer a question three months later.

The middle ground works better: a small number of fields the app will not close a job without, and everything else optional. One photo of the completed work, the parts used, and the reason if the job is not finished. Three fields, enforced, beat twenty fields that everyone skips.

Signatures are worth getting right rather than clever. In the United States, the E-SIGN Act says a signature or record may not be denied legal effect, validity or enforceability solely because it is in electronic form. A finger on a phone screen is a real signature. What makes it useful later is not the drawing, it is what you store alongside it: who signed, when, on which job, and what they were shown at the time.

15 U.S. Code 7001, general rule of validity for electronic signatures

Time on the job is a payroll record, not a nice-to-have

The clock in a field technician app ends up in two places: the customer invoice and the payroll run. Those are different numbers and they have different rules, and the app should treat them as different fields from the first day rather than deriving one from the other later.

Under the Fair Labor Standards Act, United States employers must keep records for each non-exempt worker including hours worked each day and total hours each workweek. The Department of Labor is explicit that no particular form is required, but the information has to be accurate. An app that records arrival and departure from a job site is not automatically a compliant time record, because travel, waiting and depot time all sit outside the job.

The practical rule is to timestamp events rather than ask people to enter durations. Arrived, started, paused, finished. Durations calculated from events can be recomputed when someone corrects a mistake. Durations typed by a technician at the end of a long day cannot.

US Department of Labor, Fact Sheet 21 on FLSA recordkeeping

Parts, and the second visit nobody wanted

The most expensive failure in field service does not appear on any invoice. It is the return visit caused by a part that was not on the van. Two hours of travel, a slot lost from tomorrow, and a customer who now rates you on the second visit rather than the first.

An app can shift that number without anything clever. Record what was actually fitted, every time, against the asset rather than the job. After a few months the history tells you which parts a given model of unit consumes, and the packet can carry them before anyone asks. This is the single feature that separates an app built for a trade from a generic one, and it is why an HVAC service app looks different from a plumbing one even though the screens are nearly identical.

Van stock is the other half. If the app knows what left the depot and what was fitted, it knows what is on the van, and the restock list writes itself. Nobody needs a warehouse module for this. A running balance per van is enough to stop the same missing part costing you twice.

What each option gives a technician standing on site

Option	Works with no signal	Photo and signature on the job	Knows the asset history	Fits your job types
Paper job sheets	Yes	only if someone photographs them later	No	yes, until you need to search them
Phone calls to the office	No	No	only what the office remembers	yes, at the cost of two people
Generic notes app plus camera	Yes	stored, but not attached to a job	No	no structure at all
Off-the-shelf field service platform	usually, for reading	Yes	Yes	their job model, not yours
A technician app you build	Yes	Yes	Yes	yes, by definition

Building one around your own job types

Most field businesses do not leave a platform because it lacks features. They leave because their jobs do not fit its job model: a visit that covers three assets, a compliance certificate with fields nobody else uses, a two-technician job where only one of them signs. The workaround is a paper form carried alongside the app, and that paper form is the specification for what you should have built.

Newly is an AI app builder. You describe the app you want, including the fields that are specific to your trade, and it builds and ships a real mobile app you own. Plans start at $25 a month, there is no free plan, and iOS builds ship through App Store Connect. It is not a field service platform and does not compete feature for feature with one. It is what you reach for when the platform you tried does not match the way your jobs actually run.

One decision is worth making before anything else, because it is hard to retrofit: how the app behaves when there is no connection. Queueing writes, showing the technician what has not yet sent, and never silently losing an edit are design choices, not settings. It is worth reading about working with no signal on site before you draw the first screen.

Questions people ask about field technician apps

A field technician app is the tool a technician carries to a site visit. It holds the job, the asset history, the access details and the parts expected, and it records what happened: readings, photos, parts fitted, time on the job and a signature. The distinguishing feature is that all of it has to work with no connection, because site visits happen in plant rooms and basements.

Describe the job as your technicians actually run it

Write down what a visit involves, including the form nobody has managed to get rid of, and build the app around that instead of around a template.

Start building