The architecture behind AI-optimized field dispatch: the assignment model, why the optimizer must be lazy on purpose, and the two field realities — stale GPS and schedule thrash — that break every first version. Public excerpt; the full teardown lives in the Builder library.
Dispatch automation is an optimization problem embedded in a people problem. The optimizer is the easy half. Making its output something crews trust and follow — that's the build.
Part 1 — One queue, full context. Every intake channel — operator reports, office requests, inspections, monitoring alerts — lands in a single work-order queue, each job carrying location, asset history, required skills and certs, and parts. The queue kills the whiteboard; the context kills the second trip.
Part 2 — The assignment model. Jobs match to crews on skills, certifications, current location, and load; sequences respect geography and priority. The scoring is explainable on purpose — "this crew, because closest qualified with the part on the truck" — because a dispatcher who can't see why will override everything, and an optimizer that's always overridden is a whiteboard with extra steps.
Part 3 — Lazy re-optimization. The counterintuitive design rule: the optimizer must not chase the global optimum all day. Conditions change constantly — a job runs long, an urgent call lands — and a system that re-shuffles every crew's day on every event produces technically better routes that no human will follow. Re-optimization runs on triggers and thresholds: replan the affected crew, protect everyone else's day unless the gain clears a real bar. Schedule stability is a feature you trade optimality for, deliberately.
Part 4 — Mobile close-out closes the loop. The crew's day lives on a phone: ordered jobs, context, and close-out with notes, photos, parts, and time. Close-out data feeds the back office automatically — and feeds the optimizer, which learns real job durations instead of estimates. The system gets smarter only if the field uses it, which means the field app must be faster than paper or it will lose to paper.
The optimizer reshuffled a crew's afternoon four times. Each reshuffle was locally rational; the sum was a crew that stopped looking at the app by Thursday. Field crews plan their day physically — parts loaded, lunch planned, a mental map. The fix was Part 3's entire philosophy: batch changes, respect committed jobs, and never move a job a crew is en route to without a human call. Adoption recovered when the schedule stopped twitching.
Stale GPS assigned the wrong crew twice in one week. Location pings from parked-in-a-dead-zone trucks were hours old, and "closest crew" was computed from fiction. Fix: location data carries age, assignments discount stale positions, and below a freshness bar the system asks instead of assumes — a two-second dispatcher confirmation beats a ninety-minute wrong-crew drive.
The full teardown — the assignment scoring weights, the re-optimization trigger thresholds, the close-out flow that beats paper, and the adoption sequence that gets crews on board — lives in the Builder library.
Implementation detail, checklists, and the parts we'd rather not have public — for members.
Unlock with Builder