A dispatch system that technicians route around is worse than a whiteboard. A whiteboard is visibly incomplete, so nobody trusts it further than it deserves. A dispatch system that receives half its data late and the other half reconstructed from memory looks authoritative in the office, and schedules, invoices, and staffing decisions get made on it. Adoption in the field is not a training problem. It is the product problem, and it is the whole problem.
What the job looks like from the technician's side
Picture the ten minutes at the end of a call. The technician is in an attic, a crawlspace, or on a driveway in July. They are wearing gloves. The screen is washed out in direct sunlight. Signal is one bar or none, because the building is metal or the site is rural. The customer stands three feet away waiting to hear what was wrong and what it costs. Two more calls are on the board before the day ends.
None of those conditions appear in a requirements document written in an office, and every one of them is a constraint on the software. The technician is not resisting the system. They are optimizing correctly for the conditions they face. Anything that takes four minutes at the job and thirty seconds in the truck at the end of the day will be done in the truck, from memory, and the data quality follows from that.
- They are measured on calls completed, not on records created.
- Time in the app is time the customer watches them not working.
- Taking gloves off to type in cold or wet conditions has a physical cost.
- If a form has ever rejected an entry and lost it, they will not risk that again.
- Anything that can be deferred to the truck will be deferred to the truck.
Treat all of this as rational, because it is. The question is never how to make technicians care about data. It is how to make the fastest way to finish a job also the way that produces a complete record.
Field reality and what it forces the interface to do
| Field reality | Design consequence | What happens if it is ignored |
|---|---|---|
| Gloves on, phone held in one hand | Touch targets sized for a gloved thumb; no small icons or tightly packed lists. | Mis-taps set the wrong status, and the correction never happens. |
| Direct sunlight on a scratched screen | High-contrast text and status indicators; state carried by label and shape, not by color alone. | Status is read wrong on site and dispatch acts on the misreading. |
| One bar of signal, or none | Local-first capture that queues and syncs later; submitting never blocks on the network. | Lost entries and a learned belief that the app cannot be trusted with real work. |
| The customer is standing there | Short, predictable flows a technician can complete while talking. | Completion is deferred to the truck or the end of the day and written from memory. |
| Two more calls still on the board | The common path takes a few taps; only genuine exceptions take longer. | The app becomes a tax on the last job of the day, and the last job is recorded worst. |
| The office already holds the address, contract, and pricing | Prefill everything known and ask only for what the technician alone can know. | Re-keyed data disagrees with the system of record and creates reconciliation work. |
The interface rules that follow
Make the common action the largest thing on the screen
The action a technician takes most often on a screen should be the biggest, lowest, most reachable element on it. On a job screen that is a status change or the completion button. It belongs where a thumb lands on a one-handed grip, sized so a gloved thumb hits it every time, and not beside a destructive action.
Replace free text with choices wherever a choice exists
Typing is expensive on a phone and free text is close to worthless in a report. Where the set of answers is known (failure codes, equipment types, reasons a job could not be completed), offer a short list ordered by frequency. Include an other option with a text field, because a list that cannot express reality gets defeated by people picking whichever entry is closest. Free text still belongs in one place: the note describing what was found.
Photo capture has to work the first time
Photographs are the highest-value data a technician produces and the easiest to lose. Capture has to happen inside the app in one tap, work with no signal, store locally, upload in the background, and show clearly when the upload has landed. Ask for specific photos (the nameplate, the completed work, the area left clean) rather than a generic attachment button. Named slots get filled; an add photos button gets skipped.
Never ask for something the office already knows
This is the rule broken most often. If the system holds the address, the equipment history, the contract terms, the customer's rate, and the parts loaded on the van, none of it should be typed on site. Every field the technician fills that the software could have supplied is time taken from the work and one more chance for the two records to disagree. Where a value needs checking, ask for a one-tap confirmation rather than entry.
The dispatcher's board has to show reality
Adoption fails on the office side too, in a different way. A board that shows an idealized day (every job the length it was estimated, every technician where the schedule says they are) is a board dispatchers stop looking at. They keep the real schedule in their head, in a text thread, or on paper beside the monitor.
- Travel time based on where the technician actually is, not where the previous job was scheduled.
- Skills, certifications, and licence coverage, so a job is not assigned to someone who cannot legally complete it.
- Parts and truck stock, because a reassignment that ignores what is on the van is not a reassignment.
- The job that is running long, shown while it is running long rather than at the end of the day.
- Which changes have reached the technician's device and which are still queued.
The last point matters most. If a dispatcher reassigns a job and cannot tell whether the technician has seen it, they will phone to confirm. Once they phone every time, the board is decoration and the phone is the system of record.
Capture the completion at the job, not at the end of the day
Of every behaviour change available, capturing the completion at the job pays for the rest. It turns a day of remembered work into records created while the evidence is still in front of the technician: the part number on the box, the serial plate, the signature, the photograph of what was behind the panel. It also closes the gap between finishing work and billing it. A completion submitted at nine at night with materials estimated from memory sends the office chasing detail the next morning, and the invoice goes out late or goes out wrong.
How the software earns the behaviour
- 1
Open the job with everything already known filled in, so the technician starts from a near-complete record.
- 2
Reduce the completion path to what only the technician can supply: what was found, what was done, what was used, time, and photos.
- 3
Accept the submission instantly and locally, sync in the background, and show clearly when it has landed.
- 4
Do the arithmetic in the software. Pricing, tax, and totals from a rate book beat mental math on a driveway.
- 5
Give the technician something to hand over on the spot (a summary, a signature, a copy sent to the customer) so completing at the job benefits them too.
After the replacement rollout, the trades services business reported 95%+ field data capture and same-day job completion to invoice. That was the result of technicians using the system at the job, not of a policy requiring it.
Measure adoption honestly
Logins are not adoption. A technician who opens the app to read an address and then works on paper counts as a daily active user under most definitions and contributes nothing. Measure the output instead.
- Percentage of jobs with complete field capture: status, materials, time, photos, and signature all present.
- Median time between work finishing and the completion being submitted.
- Percentage of completions submitted at the site rather than later in the day.
- Rate of office corrections after submission, which measures how often the field record was wrong.
- Percentage of dispatch changes after a technician was en route that still had to be phoned through.
Break the numbers down by crew and by individual, and read a low number as a design defect before reading it as a people problem. If one crew is at thirty percent while the rest are at ninety, that is a training conversation. If everyone is at thirty percent, the software is asking for something the job does not allow.
Fixing a system people already work around
- 1
Spend three full days in the field with three different technicians. Do not ask what is wrong with the app; time the tasks and note every point where they stop using it.
- 2
Collect the workarounds. The paper forms, the group texts, the private spreadsheets, and the notebook in the door pocket are your requirements document.
- 3
Fix the single most-used flow first, which is almost always job completion, and ship it to one crew.
- 4
Compare complete-capture rate for that crew against everyone else for two weeks.
- 5
Roll it out once the number moves. If it does not move, the change was wrong, and you learned that at the cost of one crew.
None of this requires a new platform on its own. It requires accepting that the field is the customer of the field app, and that the office's reporting is downstream of whether a technician finishes a job faster with the software than without it. Get that order backwards and you get a confident, complete-looking record of a day that did not happen.
Common questions
- Our technicians say they will not use a phone app. Is that a real constraint?
- It is usually a statement about a specific app rather than about phones. The same crews use phones all day for photos, texts, maps, and parts lookups. What they are refusing is a flow that costs them time at the job and returns nothing to them, and that objection disappears when the completion takes under two minutes and produces the customer's copy on the spot.
- Does the field app really need to work offline, or is coverage good enough now?
- Coverage is good enough most of the time, and the exceptions are exactly where the work happens: basements, attics, mechanical rooms, metal buildings, and rural sites. One lost submission is enough to teach a technician never to trust the app with a completed job again. Local-first capture with background sync is cheaper than rebuilding that trust.
- How long before the field capture rate moves?
- If the change targets the completion flow, expect a visible shift within two to three weeks for the crew it ships to, because technicians adopt anything that saves them time almost immediately. Broad rollouts take longer, mostly because habits formed around the old workaround have to be unlearned. If a change has not moved the number in a month, it was the wrong change.
- Do we need a native mobile app, or is a mobile web app enough?
- A progressive web app is enough for most field service work and is considerably faster to ship and update, provided it handles offline capture, camera access, and background sync properly. Native becomes worth the cost when you need deeper hardware access, background location, or reliable push at scale. Start with the web app, measure capture rate, and let the gaps justify native rather than deciding up front.
- Should we replace our dispatch system or fix the one we have?
- Fix it first if the constraints are in the interface, because interface problems are cheap relative to a replacement. Replace it when the constraints are structural: per-seat licensing that keeps technicians out of the system, workflows built for a different industry, or a mobile experience the vendor controls and will not change. In the trades engagement referenced here, per-user pricing had made system access something to ration, which no amount of interface work would have solved.