Field service scheduling assistant
When a technician calls in sick, it rebuilds the day in seconds and lets the planner decide what actually changes.
- For
- An Australian field-service business
- My part
- Engineer across the data pipeline, the optimisation service and the planner app
- Status
- In development
- Year
- 2026
The problem
When a technician calls in sick, somebody has to rebuild the day by hand. Who can take which visit? Who’s closest? Who’s already near overtime? Which appointments can’t move? It’s a puzzle with real customers waiting, and it always lands on the busiest morning.
How it works, in 5 parts
Read the job system
Jobs, bookings and technicians come from the business's existing job-management system. It stays the source of truth.
Keep a verified copy
Every refresh is checked (counts, ownership, fingerprints) before it replaces the last good snapshot in Dataverse.
Add what's missing
Working hours, overtime limits, days off, where each technician starts the day, and appointments that must not move.
Find better plans
An OR-Tools engine on Azure tries retimes, reassignments and whole-day rebalancing, then ranks the plans that actually work.
The planner decides
Every suggestion waits for Accept or Reject. Accepted moves are written back, read back to confirm, and can be undone.
What I built
A scheduling assistant that sits next to the business’s job system instead of replacing it. It keeps a verified copy of the schedule, adds the planning details the job system doesn’t hold, and runs an optimisation engine that suggests moves. Each suggestion shows its trade-offs (extra driving, overtime, a customer moved to another day), and the planner accepts or rejects it.
The engine grew out of a working OR-Tools prototype from the client’s side. My job was turning it into something a team can lean on: the data pipeline and its safety checks, the optimisation service on Azure, the rules for real working days, and the planner app around all of it.
The hard parts
Trust. Nothing changes on its own. Every move is a suggestion first, writes are read back to prove they happened, and there’s an undo.
Data that isn’t where you’d expect. The job system doesn’t store technicians’ working hours at all, so they had to live in the app. Recurring visits, archived jobs and a daylight-saving change each broke an assumption at least once.
Rate limits. The job system’s API allows only so many calls, so refreshes are chunked, spaced out and incremental.
Where it is now
In development, running on the business’s test data with its scheduling team. In October I added an assistant that answers planners’ questions about the schedule, with guard rails so it explains stored results instead of making things up.
What I learned
The optimisation sounds like the hard part. The real work is everything around it: knowing which records to trust, pinning down the business rules, and making every change reversible. A planner trusts a tool that shows its reasons far more than one that’s just fast.