Job management for work that happens away from a desk

A field services business rarely loses money on the work itself. It loses it in the space around the work: the enquiry that was never called back, the quote that went out three days late, the second visit because the van did not have the part, the invoice raised a fortnight after the job because the paperwork was in a folder on the passenger seat.

Every one of those is a handoff between someone in a van and someone at a desk, and every one of them is currently held together by memory, phone calls and a WhatsApp group.

• Jobs booked on a whiteboard or a shared calendar nobody trusts
• Engineers ringing the office to ask what is next and where
• Quotes written up in the evening, sent the next day, and lost to whoever was faster
• Second visits because the part was not on the van
• Job sheets on paper, rekeyed into accounts days later — or not at all
• Customers ringing to ask when someone is coming
• Certificates and compliance records reconstructed when an insurer asks

Scheduling that knows the constraints. Jobs assigned against skills, location and what the van is actually carrying, rather than against a name and a hope. Rescheduling a day should take a drag, not a round of phone calls.

Dispatch to the phone. The engineer sees the job, the address, the history of that site and what was done last time. Any previous notes go with it, so the customer does not have to explain the problem twice.

Quoting on site. Building a quote from your own price list on a phone, with your margins and any agreed customer rates already applied, and sending it before leaving. A quote handed over while the customer is still standing in the room with the problem is competing against nobody; one sent two days later is competing against whoever was quicker.

Job records that survive no signal. Notes, photos, parts used and a customer signature captured at the job and synced when a connection comes back. Basements and lofts are where this work happens, and a system that assumes connectivity is a system engineers stop using.

Invoicing from the job, not from memory. The invoice builds itself from what was recorded — labour, parts, call-out — and goes out the same day rather than whenever the paperwork surfaces.

Parts and van stock. What each van holds, decremented as parts get used, with reorder flags before someone discovers a shortage on a customer’s doorstep.

Customer communication that runs itself. Booking confirmation, day-before reminder, on-the-way notification. It removes most of the interruptions the office currently absorbs.

This is the constraint that separates field service software from everything else, and it is the one most often handled badly. An engineer standing in a plant room with no bars still has to record what they did.

The decision worth making early is which actions must work offline. Usually that is job notes, photographs, parts used and the customer signature — the things captured at the moment of work and impossible to reconstruct accurately later. Scheduling and quoting can often tolerate a connection. Retrofitting offline support after the fact is substantially more expensive than designing for it, which is why it belongs in the first conversation.

Where a job produces a certificate, a test result or a signed record, generating it from the job data is worth more than the time it saves. Rekeying is where errors enter, and a compliance record with the wrong date or the wrong serial number is worse than a late one.

Holding those records against both the job and the customer means producing them again — for an insurer, a landlord, a buyer or an audit — is a search rather than an excavation through folders.

If you already run a job management product, the useful project is usually not replacing it. These products tend to be competent at core scheduling and thin at the edges: the handoff into accounts, the customer messaging, the compliance paperwork, the reporting that tells you which jobs actually made money.

Automating those edges keeps your team on software they already know and delivers in weeks rather than months. Replacement is worth considering when the product cannot hold the data you need or its vendor has stopped developing it — not because it irritates you.