A field service management platform

A service company was dispatching technicians by phone, whiteboard, and paper work orders — and spending nearly as much time on administration as on billable work. Once a van left the yard, the dispatcher had no visibility into what was happening in the field. Jobs finished, technicians drove back to drop off their paperwork, and someone re-keyed the data into a billing system the following morning — assuming the handwriting was legible.

By the time an invoice reached a customer, days had typically passed. Cash sat unbilled, disputes were common, and every job that ran long or hit a parts problem surfaced only through a phone call.

The problem

The real problem was the gap between what happened in the field and what the office knew. A dispatcher working from a whiteboard had no live picture of job status, no way to reassign a technician mid-day without disrupting everything, and no historical data to improve scheduling the following week.

Three constraints shaped the work:

• Unreliable or absent connectivity. Many job sites — industrial facilities, rural properties, commercial basements — had no mobile signal. The mobile application had to treat connectivity as the exception, not the rule.
• No appetite for disruption. This was a tight operation. Any retraining period that slowed the day would cause real harm. The new tools had to feel faster than the clipboard on day one, or technicians would revert.
• End-to-end, not piecemeal. A scheduling tool alone would not fix anything if the invoice still required manual data entry. The entire loop — dispatch to field to billing — had to close in the same system.

What we built

We built four tightly connected pieces that form one operational loop:

• Scheduling and dispatch board — a Next.js web application for the office team showing every open job, every technician, and a live map view. Drag-and-drop assignment, route-aware scheduling hints, and automatic SMS notifications to technicians when a job changes.
• Technician mobile app — a React Native application for iOS and Android that downloads the full day's job queue on startup and stores every piece of job data locally. Technicians navigate to jobs, log arrival and departure, complete digital work orders, capture photos of equipment and completed work, and collect customer signatures — all without a data connection.
• Digital work orders — structured forms that replace paper, with required fields, equipment-specific checklists, and photo attachments. A completed work order becomes the single source of truth for billing and service history.
• Invoice drafts from the completed job — when a work order is marked complete and syncs to the server, the system generates a draft invoice automatically. The office reviews, approves, and sends.

The architectural decision that made the rest tractable was treating the mobile device as the authoritative record during a job, not a thin client. Every job record syncs down to the device before a technician leaves the yard. Every field action — status updates, photos, form responses, signatures — queues locally in a SQLite store. When connectivity returns, the sync engine reconciles the local queue against the server in the background. The dispatcher sees live updates without the technician making a single phone call.

How we approached it

We sequenced the build around the highest-risk dependency: offline sync. We built and field-tested the sync engine with volunteer technicians before the dispatch board or invoicing workflows existed. Getting that piece wrong would have cost far more to fix after a full rollout.

The dispatch board came next, starting in read-only mode alongside the existing whiteboard so the office team could build trust in the new view before depending on it. We ran both in parallel. By the day the whiteboard came down, the dispatcher had already been using the digital board as her primary tool.

Historical customer data — service addresses, equipment records, and contact details from completed paper jobs — was cleaned, normalized, and imported before the first technician logged into the mobile app. Walking into a job with the asset history already loaded was one of the features the crew valued most.

Training happened in the field. We accompanied technicians during the first stretch, watching where the application created friction and adjusting in real time. By the end of that period the crew was operating on digital work orders.

What we will not claim

No jobs-per-day lift, no same-day invoice rate, no admin-time cut. Those percentages are not in this repo. The public claim is the loop: offline work orders on the device, a live board in the office, and a draft invoice from the completed job.

If you are running field operations on clipboards and end-of-day data entry, start a build and we will map the first practical phase — or read more about our approach to custom software.