Cloud & platform · dispatch.fieldopsCI passing

Field Service Management SaaS

Technicians who arrive in the window, with the part on the van.

Open the live demo View the code Evaluation report Demo tour Run it ›_ last push 1 day ago

91.7% vs 75.7%appointments kept (done on the booked day, inside the window) on 10 held-out regions

43% lessdriving per job (10.7 km vs 18.7)

99.6% vs 72.8%first-time fix with a van kit planned for the day vs a standard kit (90.5% with new brands)

Tomorrow: every technician's route on a map, driving, home time and the parts added for the day. Screenshot from the project's demo (synthetic data).

demo Demo tour

Screenshots from the running application, with its synthetic demo data. Select one to enlarge.

One technician's day: arrival times, windows, the most likely parts and whether the van has them.

A new job request read into skill, fault, brand and window, with the parts it is likely to need.

Evaluation: appointments kept, driving and first-time fix on held-out and shifted regions.

01 The problem

Dispatchers often build tomorrow's routes by working down the list of bookings, giving each job to the nearest free technician. Technicians end up scattered across the region, driving eats the day, and a quarter of customers wait in for a window that is missed. Vans carry a standard kit, so jobs needing a brand-specific part become two visits.

02 How it works

Job request
Catalogue fault
Window-first insertion
Routes
Van kit
First-time fix

03 What I built

A planner that places tight windows first, inserts each job where it adds the least driving without making anyone late, then moves jobs between routes; each planner's buffer for jobs running long was tuned separately so the baseline is tuned as carefully.
Van kits with a core every van carries and flexible slots picked for each route from how often each fault on each brand needed each part, smoothed towards the fault on any brand for unseen brands.
A dispatch console with tomorrow's routes on a map, each technician's day with parts and probabilities, and job requests read with Claude into the service catalogue and checked.

04 What I learned

The first region was too big and too busy for any planner, and an 8-slot van gave the standard kit no chance; both were made realistic before tuning, so neither side won by construction.

Each planner got its own tuned planning buffer: with none, the optimiser packed routes too tight and ran late.

The first-time-fix result is near a ceiling by construction (correct diagnosis, few jobs a day); the shifted regions with new brands show where it really loses ground.

05 Known limitations

Every repository documents what it doesn't do yet. The main ones:

Synthetic regions, straight-line travel, no mid-day re-planning.
Diagnosis at booking assumed correct; Claude's reading of requests is not measured.

06 Stack

PythonFastAPINumPyClaude APIDocker

The repository has the design document, operations runbook, full evaluation report and known limitations. All data is synthetic, generated by code in the repository.

run Run it yourself

Every project runs on a laptop: no cloud account and no paid API needed.

git clone https://github.com/codeROCK-IZZY/field-service-management.git
cd field-service-management
pip install -e ".[dev]" && pytest
fieldops evaluate --gate                   # writes eval/reports/report.html