Field service software fails on the van, not in the office
Dispatch boards, job sheets, technician apps and customer notifications. Field service is the shape of product where an AI builder gets you furthest fastest - and where the gap between the demo and the job site is widest, because the demo had a signal and the basement does not.
- Technicians work in places with no reliable signal and still have to record work.
- Dispatch changes during the day and the schedule on the phone goes stale.
- Proof of work - photos, signatures, timestamps - matters for getting paid.
- The office runs on a spreadsheet and the field runs on phone calls.
- You are paying per seat for a platform that does 60% of what you need.
Where a generated prototype stops being enough
Not general advice. These are the failures specific to this kind of product, and none of them are visible on screen.
- 01
Offline is a data model, not a feature you add
A technician in a basement has to open a job, fill in a form, attach photos and mark it complete with no connection, then sync when they surface.
- 02
Two people editing one job is the normal case
Dispatch reassigns a job while the technician is filling it in.
- 03
Photos are the payload nobody sized for
Modern phone photos are several megabytes each, and a job might have a dozen.
- 04
The office and the field need different apps
Dispatch needs a dense, keyboard-driven board on a big screen. A technician needs three large buttons and a glove-friendly form.
The sentences we hear most, and what we do about each one
"My technicians say it does not work but I cannot reproduce it"
Because you are testing on office wifi. The failures are all connectivity-shaped: a form submitted in a lift, a photo upload that died at 80%, a job list cached from this morning.
How we helpWe test on throttled and intermittent connections, and we instrument the app so a failure produces a report with the network state attached. "It does not work" becomes a log line with a timestamp and a reason.
"Two people edited a job and we lost the notes"
The classic field service data-loss bug. There is no version on the record, no conflict detection, and the second save overwrites the first without anyone noticing until the invoice is wrong.
How we helpRecords get a version, writes are checked against it, and conflicts are surfaced to a human with both versions rather than resolved silently.
"My technicians will not use it"
Adoption is the real failure mode in field service, and it is almost always an interface problem.
How we helpThe technician app is designed for the job: large targets, the shortest possible path from open to complete, defaults that are right most of the time, and a form that survives a phone locking mid-entry.
"We are paying thousands a month for a platform we half use"
Per-technician pricing on a commercial platform scales with headcount, and the fit is never quite right because the product was built for a different trade.
How we helpWe model the honest comparison: what a custom app costs to build and to run against your platform bill over three years, including maintenance.
The parts that make it hold
Offline-first technician app
Local storage, a sync queue, idempotent writes and explicit conflict handling.
Dispatch board that reflects reality
Live schedule, drag-to-reassign, travel-time awareness, and changes that reach the technician's device the moment it has a connection.
Proof of work
Photos with compression and resumable upload, signatures, GPS stamps and timestamps - attached to the job and defensible in a dispute.
Customer notifications
On-the-way and completion messages by SMS or email, with delivery tracked so a missed appointment has a record.
Parts, time and invoicing
Materials and labour captured on the job, flowing into your accounting system rather than into a re-keying task.
Reporting the office trusts
First-time fix rate, travel versus wrench time, jobs per technician - computed from job data rather than from a parallel spreadsheet.
Usually connected to
- Accounting: Xero, QuickBooks, Sage
- SMS and voice: Twilio, MessageBird
- Maps and routing: Google Maps, Mapbox
- Payments: Stripe, GoCardless
- Calendar: Google Calendar, Microsoft 365
- Existing CRM or ERP via API or scheduled sync
In the order it actually happens
Growth does not break everything at once. For this kind of product it breaks these four things, in this sequence, and each one is cheap to fix before it happens.
| At | What breaks | becomes | The fix |
|---|---|---|---|
| First technician in a dead zone | Job data entered offline is lost on submit | Local-first storage with a sync queue and idempotent writes | |
| Two dispatchers | Concurrent edits silently overwrite each other | Record versioning with explicit conflict resolution | |
| ~10 technicians | Photo uploads saturate the connection and time out | Client-side compression, resumable uploads, background transfer | |
| ~50 jobs a day | The dispatch board slows and reporting queries lock tables | Indexes, read replica for reporting, archival of closed jobs |
Four phases, each ending in something you keep
The first one is free. Scope is fixed after it, and you keep the findings whatever you decide next.
- 013–5 days
Field review
Free. We ride along with the workflow - literally, where that is possible - and test the app the way a technician uses it, on a throttled connection, one-handed, in a hurry.
You receive
- Failure report from realistic field conditions
- Offline and conflict-handling assessment
- Adoption review of the technician interface
- Ranked plan with effort estimates
- 022–4 weeks
Offline and conflict model
The data model is reworked so offline is a property of the system rather than a patch.
You receive
- Local-first data layer with a sync queue
- Record versioning and conflict surfacing
- Resumable, compressed media upload
- Tests that run against simulated network failure
- 032–4 weeks
The two interfaces
The dispatch board and the technician app are built as what they are: two different products against one backend.
You receive
- Dispatch board with live reassignment
- Technician app designed for one hand and no signal
- Customer notifications with delivery tracking
- Tested with real technicians before release
- 041–2 weeks, plus 30 days support
Integrate, ship, hand over
Accounting and messaging integrations, monitoring, and a phased rollout that starts with a willing crew rather than the whole company.
You receive
- Accounting and SMS integrations live
- Phased rollout plan by crew
- Monitoring, alerting and a runbook
- 30 days of post-launch support
Before you book the call
It will produce the dispatch board and the job forms quickly and convincingly.
Usually yes for the field app - reliable offline storage, background upload and camera access are what the job needs - and usually no for dispatch, which is better as a web app on a big screen.
One willing crew first, running alongside the existing process for two weeks, with the old system as a fallback.
Frequently, yes, and we will say so during the review. Custom pays off when your workflow is genuinely different from what the platforms model, when per-seat pricing has outgrown the value, or when the app is part of what customers buy from you.
Related solutions
Business internal tools
The admin panel, ops console or back office that the business now depends on.
See what breaksOperations dashboards
The numbers the business runs on - accurate, fast, and the same for everyone.
See what breaksBooking and scheduling
Appointments, capacity and calendars - where double-booking is the whole risk.
See what breaks
Building field service management?
The first review is free, and it ends with a straight answer - including when the answer is to buy something off the shelf instead.