Field service software is bought frequently and abandoned frequently. The pattern is consistent: the office finds it excellent, the engineers do not use it, and within a year the whiteboard is back.
The systems that survive share a small number of characteristics.
It must work in a van, in a basement, in the rain
This is the whole thing, and most evaluations miss it because they are conducted on a laptop in an office.
It must work without signal. Plant rooms, basements, lift shafts, rural sites, vessels. If the app cannot record a job without a connection and sync later, it will be abandoned.
It must be usable one-handed with cold hands. Large targets, few taps, no fiddly dropdowns. The person using it is standing up, holding something else, in poor light.
It must be faster than paper. Not equivalent — faster. Engineers adopt tools that get them home earlier and reject tools that add ten minutes per job for the benefit of somebody else's report.
The battery must survive the day. An app that constantly polls location will not, and the engineer will close it.
Evaluate field software by sending an engineer out with it for a week. The office demonstration tells you nothing that matters.
What the job record has to hold
The site, not just the customer. A managing agent with forty buildings is one customer and forty sites, each with its own access arrangements, equipment and history. Systems that only model customers make this painful.
History at that site. The engineer arriving needs to know what was done last time and what was flagged for next time. This is the single most valuable feature and the one most often absent.
Access information. Key safe codes, who to ask, parking, permits, induction requirements, the dog. This lives in someone's head and should not.
Equipment or assets. Serial numbers, install dates, service intervals, warranty status. For maintenance businesses, the asset is what the job is about.
Parts used. Recorded on site, feeding both the invoice and stock.
Scheduling that reflects reality
Most scheduling tools assume jobs are interchangeable and engineers are identical. Neither is true.
What matters in practice: who is qualified for what, travel time between jobs rather than just duration, which jobs must happen on a fixed date, and how easily today's plan can be rearranged when the first call of the day turns into three hours.
That last point decides whether the schedule stays accurate. A system that makes rescheduling awkward will be bypassed by phone calls, and then it no longer reflects what is happening.
Capturing the work
What the engineer records on site should be everything needed afterwards, entered once.
What was done, in enough detail that the invoice can be justified if queried.
Photographs. Before and after, and of anything that will become a dispute. These are worth more than any written note and take seconds.
Parts and time. Feeding the invoice directly.
Signature or acknowledgement. With a timestamp.
Follow-up work identified. The most commercially valuable field on the form. An engineer noticing that something else needs attention is a quotable opportunity, and without a place to record it, it is mentioned in the van and forgotten.
Certificates and compliance
For regulated trades, the certificate is not paperwork — it is the deliverable, and it has a required format.
A system that generates it from the job record, stores it against the site, and reminds you when the next one is due removes a genuine administrative burden and a genuine risk. If your trade has certification requirements, this should be near the top of your evaluation criteria rather than an afterthought.
The office side
From the job record everything else should follow: the invoice generated without retyping, as covered in quoting and invoicing; the customer notified automatically of arrival and completion; and follow-up work becoming a quote rather than a memory.
Then into accounting without further entry — see connecting accounting to operations.
Buy or build
Buy, in most cases. The category is competitive and mature for standard trades work, and existing products have solved offline working, scheduling and certification in ways that would be expensive to rebuild.
Build only where the work genuinely does not fit: unusual scheduling constraints, certification no product supports, or a maintenance regime driven by asset data the products cannot model. The argument is set out in build versus buy.
Getting it adopted
Involve the engineers in choosing. Not consulted afterwards — involved in the trial, with a real say. A system imposed on the people who must use it in the rain will lose.
Then start with one crew for a month, fix what they complain about, and roll out with them advocating. That sequence works far better than a company-wide launch and a training session.
Our consultancy team helps UK trades and field service businesses choose and implement job systems. Start a conversation.
