Field Service AI Scheduling Platform
The client was a regional utilities contractor running roughly three hundred field technicians across multiple service categories — installation, maintenance, emergency response — for a mix of residential and commercial customers. Daily scheduling was done by a small dispatch team using a whiteboard and a shared spreadsheet, which produced suboptimal routes, regular SLA misses on time-bound emergency calls, and predictable end-of-day overtime spikes during high-demand seasons.
Productivity & SaaS Tools
Logistics, Utilities
11 weeks from kickoff to first region rollout, plus a month for region waves
4 specialists
The full story
The practical problem was that scheduling at three hundred technicians with multi-skill matching, geographic routing, and SLA constraints was a combinatorial problem that no human team could solve optimally in real time. Dispatchers compensated by sticking with familiar technician-to-area patterns, which kept the system stable at the cost of leaving optimization on the table. SLA misses were forgiven by customers individually but were beginning to show up in commercial-customer renewal conversations.
We built a scheduling platform that solved the daily assignment problem as a constrained optimization, taking technician skills, geographic locations, SLA deadlines, and equipment requirements as inputs. The optimizer ran a fresh schedule continuously through the day as new jobs arrived and existing jobs slipped, and the dispatcher reviewed proposed changes rather than building the schedule from scratch. The model respected technician preferences where they did not conflict with hard constraints, which kept the team’s experience consistent with the prior dispatching approach.
What shipped was a dispatch workstation where the schedule built itself against current state, the dispatcher approved or overrode in bulk, and re-optimization happened continuously as conditions changed. SLA misses dropped, fuel costs dropped through better routing, end-of-day overtime smoothed out, and the dispatch team shifted from building schedules to managing exceptions and customer escalations. The contractor took on additional commercial accounts the following quarter because the operational headroom existed without expanding headcount.
Three hundred technicians, multi-skill matching, SLA constraints — too combinatorial for whiteboard dispatching to solve well.
Multi-skill matching plus geographic routing plus SLA deadlines was a combinatorial problem no human team could solve optimally daily.
Dispatcher familiarity with technician-area patterns produced stable schedules at the cost of leaving routing optimization on the table.
SLA misses on time-bound emergency calls were appearing in commercial-customer renewal conversations as concerns.
End-of-day overtime spikes during high-demand seasons were predictable but uncorrected because dispatchers could not see the pattern early.
Fuel costs were a meaningful operating line and visibly suboptimal under hand-built routes that minimized dispatcher complexity, not driving distance.
How we structured the engagement
Solved daily assignment as continuous constrained optimization with the dispatcher supervising rather than building.
- 01Phase 01Weeks 1-2
Discovery
Shadowed the dispatch team for one week, instrumented the existing whiteboard process for assignment patterns and SLA misses, and worked with operations on the constraints that had to be preserved. Output: a constraint specification including skills, SLAs, geography, and equipment, plus a dispatcher-supervision interaction model.
- 02Phase 02Weeks 3-4
Architecture
Designed an OR-Tools-based scheduler over the constraint specification, with continuous re-optimization on new-job arrival and existing-job status change. Built a dispatcher workstation that rendered proposed changes against the current schedule with rationale per change. Used PostgreSQL for state and FastAPI for the optimization service.
- 03Phase 03Weeks 5-9
Build
Shipped the scheduler and the dispatcher workstation first, then continuous re-optimization and rationale rendering. Implemented technician preference handling as soft constraints, and integrated with the existing field-tech mobile app for assignment notifications. Built SLA-risk alerts that fired ahead of time rather than at miss.
- 04Phase 04Weeks 10-11
Launch
Rolled out to one operational region of roughly eighty technicians for three weeks, monitored SLA performance and dispatcher acceptance rate daily, and tuned the optimizer’s preference weights based on dispatcher overrides. Expanded to the remaining regions in waves over the following month with weekly tuning passes.
What we built, component by component
- 01
Job intake
Captures new jobs with skill requirements, SLA deadlines, geographic location, and equipment needs, normalized for the optimizer.
- 02
Technician state
Live state per technician including skills, current location, current job, preferences, and equipment loadout.
- 03
Constraint solver
OR-Tools-based optimizer that produces full-day schedules respecting hard constraints with soft-constraint preferences as objective.
- 04
Re-optimization loop
Continuous trigger on new-job arrival or job-status change, produces incremental schedule changes rather than full rebuilds.
- 05
SLA-risk alerter
Fires alerts when a job’s predicted completion time exceeds its SLA deadline, so dispatchers can intervene before the miss.
- 06
Dispatcher workstation
Bulk-approve workstation with proposed changes rendered against current schedule, rationale per change, and override per assignment.
New jobs arrive at intake with structured constraints, technician state stays live as crews complete and move between jobs, and the constraint solver maintains an optimal schedule. The re-optimization loop responds to state changes incrementally, the SLA-risk alerter watches predicted completion versus deadline, and the dispatcher workstation surfaces proposed changes for bulk approval or per-assignment override.
The trade-offs we made and why
Continuous re-optimization rather than morning batch only
Morning-only optimization went stale within an hour as new emergency jobs and status updates arrived. Continuous re-optimization kept the schedule current against actual conditions throughout the day, which is where most SLA risk lived and most fuel savings came from.
Built technician preferences as soft constraints
Ignoring technician preferences would have produced optimal schedules and unhappy technicians, with attrition risk that would have erased the productivity gains. Soft-constraint preferences kept preferences respected when they did not conflict with hard constraints, which preserved the team experience.
Made the dispatcher the supervisor, not the builder
Replacing the dispatchers would have lost institutional knowledge and would have failed in the first edge case the system did not handle. Repositioning them as supervisors who reviewed and overrode kept the human judgment in the loop and let them focus on the cases that genuinely required it.
Fired SLA-risk alerts ahead of time, not at miss
Alerts at miss time were post-mortem signals. Predicting completion time against deadline let dispatchers reassign before the miss happened, which is where most of the SLA improvement actually came from — not from better initial assignments but from earlier corrections.
What changed for the client
missed SLAs
Reduction in time-bound SLA misses across the technician fleet in the first quarter after region-wide rollout.
fuel cost
Reduction in fuel cost per completed job, driven by more efficient routing across the continuous re-optimization loop.
operational efficiency
Composite measure of jobs completed per technician-day, fuel cost reduction, and overtime smoothing across all regions.
technicians scheduled
Full fleet under continuous constrained optimization at full rollout, up from whiteboard-based manual dispatch.
The tools behind the system
Built with a deliberate stack chosen for production reliability and operational velocity.
Lessons learned from the build
Soft-constraint preferences were the change-management win we did not initially scope. Hard-optimizing without preferences would have triggered field-team resistance that no productivity gain could have overcome. We would build preference handling into any human-in-the-loop scheduling system from day one.
Continuous re-optimization was where most of the value came from. We initially scoped morning-only optimization because it was simpler, and the first week of live operation showed how much value was leaking out of the day. Real-time problems need real-time solvers.
Pre-miss SLA alerts produced more SLA improvement than initial assignment quality did. Predicting completion time gave dispatchers a lever to act on, and the lever turned out to be more useful than the perfect starting schedule. We would lead with prediction surfaces on any operational system in the future.
Similar delivery work usually starts in these service areas
If you are exploring a similar product, workflow, or implementation challenge, these are the service tracks that usually fit best.
Where this project sits in the bigger market picture
Applied AI for operations, supply chains, routing, and industrial workflows.
Build a result-driven AI product with a team that has shipped before
If you are exploring a similar product, workflow, or AI use case, we can help scope the right architecture, delivery model, and first milestone.
Related case studies worth reviewing next
Have an AI idea, messy workflow, or product vision? Let's make it buildable.
Bring the problem. We'll help shape the product, define the architecture, and show the fastest path to a serious first version.
A practical first roadmap in the discovery call
Architecture, timeline, and delivery options in plain English
Security, scalability, and reliability discussed upfront
Model registry
softus-rag-v4.2
187ms
Latency
128k
Context
$0.004
Cost / req
Evaluation suite
Deploy pipeline
prod / canary 25% — healthy