A field-services operation ran its entire dispatch on one person's memory. We replaced that single point of failure with a scheduling system that actually understands its assets, crews, and jobs.
The problem
The operation moved crews and equipment between job sites every day, and the schedule lived almost entirely in one dispatcher's head. That person knew which crew was qualified for which work, which truck was already committed, which customer needed a morning slot, and which job was running long. None of it was written down in a form anyone else could act on. When the dispatcher was out, the operation slowed to a crawl. When the dispatcher was busy, things slipped.
The practical results were predictable. Jobs got double-booked against a crew or a piece of equipment that was already assigned somewhere else. Work fell off the calendar entirely because a verbal change never made it onto the board. Crews showed up with downtime between jobs because the day had not been sequenced tightly, while other crews ran ragged. And from the office, nobody could answer a simple question reliably: where is each crew right now, and is the job on track.
This is the pattern we see across trades and field operations. The business runs on tribal knowledge, and that knowledge is concentrated in one or two people. It works until it does not, and the failure modes are exactly the ones that cost money and customer trust: missed appointments, idle crews, and a schedule nobody else can read. We have written about why this shows up so often in operational software for construction and field businesses, where the gap between how the work actually runs and what the office can see is the core problem.
The approach
We did not start with software. We started by mapping how dispatch actually worked, decision by decision, including the parts that lived only in the dispatcher's head: how crews got matched to jobs, what made an assignment valid, and how the day got resequenced when reality changed. That model became the spine of the system. The goal was to move the operation from tribal knowledge to a system that holds the same awareness the dispatcher carried, so the schedule no longer depended on one person being present and remembering everything.
From there we built a custom dispatch and scheduling system around three kinds of awareness: assets, crews, and jobs. The system knows what equipment exists and where it is committed, which crews are available and what work they are qualified for, and what each job requires and when it is due. Because it holds all three at once, it can do the work the dispatcher used to do by memory.
- Conflict detection: the system flags an assignment the moment it would double-book a crew, a vehicle, or a piece of equipment, instead of letting the collision surface on the morning of the job.
- Automated rescheduling: when a job runs long, a crew calls out, or a customer pushes a date, the system proposes a revised sequence that respects the existing constraints rather than forcing a manual rebuild of the day.
- Customer confirmation flow: scheduled and rescheduled appointments trigger confirmations to the customer, so changes are communicated automatically and the office is not chasing phone calls.
- Mobile field updates: crews update job status from the field, marking work started, delayed, or complete, which keeps the office view current without anyone calling in.
This is the same build-vs-buy logic we walk through in choosing between off-the-shelf software and a custom internal tool. Generic scheduling tools assume a generic operation. This operation had specific rules about what made an assignment valid, and encoding those rules was the entire point. You can see how this work fits into our broader practice on the dispatch and scheduling page and our operational dashboards work.
Dispatch board: crews and assets across the day
A timeline view of every crew and major asset down one axis and the working day across the other, with each job shown as a block in its assigned slot. Conflicts are flagged inline, so a double-booked truck or an overlapping crew assignment is visible before the day starts rather than discovered in the field.
Job detail: status, crew, and customer confirmation
A single job with its assigned crew and equipment, its required window, current field status reported from the crew's mobile device, and the customer confirmation state. When a job is rescheduled, the proposed new slot and the resulting customer notification are shown together.
The outcome
The honest outcome of a build like this is operational, not a single headline number. The operation moved from a schedule that lived in one person's memory to one that lives in a system the whole team can read and act on. Dispatch became predictable: assignments are valid by construction because the system refuses to create a conflict, and the day can be resequenced without a manual rebuild when reality shifts. The dependence on tribal knowledge dropped, which means the operation no longer stalls when one person is unavailable.
The second-order effects follow the same pattern. With conflicts caught before the day starts and the day sequenced against real constraints, crews spend less time idle between jobs, which is where utilization improves. With customer confirmations and field updates flowing automatically, the office gains real-time visibility it never had and stops chasing status by phone. That is the pattern this kind of work produces, and it is consistent with what we describe in our writing on custom software for trades and construction. If you want to see the range of problems we take on, browse our selected work or read more about how Warren & Sabb approaches operational software.