Getting Field Crews Off Paper Without a Mutiny

Field software projects fail in a consistent way, and the cause is almost never technical. The app works and the crews don’t use it. Six months later the paper tickets are back, next to a subscription nobody cancelled.

Usually the system was designed for the office, which wants data. The office also paid for it, and the office isn’t the one typing it in.

Look at what paper does well

Before you replace paper, be honest about why it lasted this long.

• No signal needed, which matters on a rural job site or inside a plant
• Gloves, rain and darkness don’t bother it, and it never needs charging
• Filling it in badly takes four seconds, and badly is often enough
• It never asks a required question the tech can’t answer yet

That last one does most of the damage. A paper ticket tolerates blanks. Software written by somebody who wants clean data won’t, and a required field the tech can’t fill at 4pm on a roof is when the app gets abandoned.

Every required field assumes the tech has the answer at the moment you ask.

Design for the worst thirty seconds of the day

Forget the demo. The tech is in a truck, it’s raining, the next job is late, and there’s one bar of signal. The app has to work in that moment.

Offline first

The app has to work fully with no connection and sync when it finds one. An "offline mode" that degrades the app falls short, because across much of Southeast Ohio and West Virginia no signal is the normal condition. Sync conflicts have to resolve without asking the tech to referee.

Photos instead of typing

A photo takes two seconds and carries more than the paragraph a tech won’t write. Serial plates, meter readings, the site before and after, damage that was already there. Make the camera the main input and keep typing for the exceptions. It’s a big part of why the FalconSnap rollout at HMR Plumbing stuck.

Big targets, few taps

Gloved hands, sunlight, one hand holding something else. Use large buttons and high contrast, and let the tech close a job in three taps.

Defaults that are usually right

Prefill everything you can infer: the tech, the date, the site, the last material used. Confirming a default takes one tap. A dropdown of two hundred options sends people back to paper.

Give the crew something back

This is the part that gets skipped, and it decides adoption. If the crew feeds the app and only the office benefits, the crew will resent it and quietly work around it.

1. Tomorrow’s schedule on the phone, so nobody rings the office to ask
2. The site history: what was done here last time, and by whom
3. Parts and manuals on hand, so nobody hunts for the binder in another truck
4. Proof they finished, timestamped, which settles disputes in their favour as often as against
5. Hours that flow to payroll, so a submitted ticket is a paid ticket

Payroll is the strongest lever you have. Once the app is how the crew gets paid accurately and on time, management stops having to push it.

Roll out in the order that builds trust

Start small, and skip the newest crew.

Begin with two or three techs, including at least one respected sceptic, the one everybody else listens to. Run in parallel with paper for a few weeks so nothing gets lost while the app proves itself. Fix what they complain about quickly and visibly, and tell them it was their complaint. Then expand, and let them explain it to the others.

What the office has to give up

Part of its wish list. That list always includes fields that would be lovely to have and cost the crew twenty seconds each. Twenty seconds times eight jobs times twelve techs is real money, and the people spending it never asked for the system.

For every field, ask who reads it and what decision changes because of it. Fields that pass that question go in. The rest are how crews end up back on paper.

Working through that trade-off is the design work in a field application, and it’s why our review phase happens in the truck.