Catalog / Optimisation & Planning / OPT-019

Field service scheduling & technician dispatch optimisation

Assign and route service jobs to technicians in real time under skills, parts-on-van, SLA, appointment-window and working-time constraints, and re-plan automatically when the day changes.

Parts needed to run it yourselfAgents & automationLanguage modelOptimizationPrediction & time series

Heating, elevator, utility, telecom and facility-service firms send people with the right skills and parts to customers within promised windows. Dispatchers traditionally do this by whiteboard or spreadsheet and struggle when jobs overrun or emergencies arrive. A solver-based scheduler, fed with ML-predicted job durations, plans and continuously re-plans the day, cutting travel and missed appointments while keeping dispatchers in control.

Problem & value

  • Today: a dispatcher phones technicians, juggles skills, van stock, appointment promises and working-time rules, and fixes the plan by hand after every cancellation or overrun. Trades and crafts (Handwerk) firms often plan in Excel or a calendar.
  • AI value: fewer kilometres per job, more jobs per day, higher first-time-fix rate (right skill and part on the first visit), better SLA adherence, realistic customer ETAs, less dispatcher stress.
  • Evidence: vendors publish case studies on travel-time and utilisation gains, but results depend heavily on baseline planning quality and are not comparable across firms; measure your own baseline before trusting any claim [1][2].
  • Why distinct: it is a joint routing, skills-matching and SLA problem solved on a rolling horizon, not plain vehicle routing (OPT-001) or shift rostering (OPT-003).

Variants

  • Trades & crafts SMB (HVAC, electrical, plumbing): 5-50 technicians, appointment booking by customers, simple skill matrix.
  • Utilities & grid operators: meter, fault and connection work, regulated response times, outage-driven surges.
  • Facility management and lifts: contract-based preventive maintenance plus emergency call-outs, often combined with predictive maintenance (PRED-006).
  • Telecom and FTTH installers: appointment-heavy, customer-slot offering, partner subcontractor pools.
  • Medical devices and IT hardware service: parts logistics and strict SLAs dominate.
  • Home healthcare visits: closely related, but with care-continuity rules; see OPT-003.

How it works

  1. job intake (ticket, call, IoT alert, contract maintenance plan)
  2. enrichment (skills needed, parts list, duration estimate, priority/SLA)
  3. candidate slot offering to customer (appointment booking)
  4. solver: assignment + sequencing (skills, parts-on-van, time windows, travel times, working-time law, breaks, SLA penalties)
  5. dispatch to mobile app, live GPS tracking
  6. event-driven re-optimisation (cancel, no-show, overrun, emergency)
  7. dispatcher review / override
  8. learning loop on actual durations
  • Core: a constraint-based solver (VRP with time windows, skills, multi-day horizon) using metaheuristics, constraint programming or MIP. This is the established OR layer, not an LLM.
  • ML layers: gradient-boosted models predict job duration, travel-time variance and no-show probability from history; these feed the solver as realistic parameters. Time-series models forecast demand for capacity planning.
  • LLM layer (optional, supporting): turn free-text tickets or voice notes into structured job fields (skill, parts, urgency); draft customer messages; let dispatchers ask what-if questions in natural language that are translated into solver parameters (see OPT-018). The LLM never overrides hard constraints.
  • Human-in-the-loop: dispatchers approve or pin assignments, can lock jobs, and own emergency decisions; technicians can reject or swap with documented reasons.

Data preparation

Needed are work orders (type, location, duration, priority, SLA), technician master data (skills, certificates, working times, home base), spare-parts and van stock, customer appointments, asset history and travel-time data. In an SMB they sit in the ERP or a field-service tool, Excel schedules, e-mail, WhatsApp groups and paper job cards.

Typical gaps: missing or free-text skill and job-duration information, durations that are estimated rather than measured, outdated addresses and geocodes, duplicate customer and asset records, and paper service reports that are never digitised. Technician data is personal data with access restrictions.

Preparation steps: (1) define a skills catalogue and job types (PREP-019), (2) harvest real durations from closed work orders (PREP-020), (3) clean addresses and duplicates (DATA-003), (4) capture reports digitally at source (PREP-008) or scan them (PREP-006), (5) pull data from the ERP via export or API (PREP-005). Tools: geocoding service, pandas, n8n for exports. Expect around 40 percent of the effort in data preparation.

Implementation paths

Which path for whom

  • SMB: Path A. Mature field-service management products with EU hosting exist at SMB prices and cover standard dispatch, scheduling and mobile apps.
  • Enterprise: Path B. Dispatch is a core process with its own skills matrix, SLAs and systems; a build on cloud APIs and solvers integrates with ERP, CRM and asset data and avoids per-seat costs at scale.
  • Developer: Path B. Solver engines and routing APIs combined with an LLM layer are the usual way to build a dispatch product.

Path A - Buy

  • Field service management (FSM) suites with optimisation: IFS Planning & Scheduling Optimization (IFS is Swedish, EU), Salesforce Field Service, Microsoft Dynamics 365 Field Service with Resource Scheduling Optimization, ServiceMax, SAP Field Service Management (SAP is German, EU, ex-Coresystems), Oracle Field Service.
  • Specialist and SMB tools: Praxedo (France, EU) and German Handwerker/FSM software with route planning; check each for real automatic optimisation versus manual map planning.
  • Check: EU hosting, works-council-compatible GPS settings, offline mobile app, ERP/CRM connectors, appointment-booking portal, what-if simulation.
  • Choose A when: you already run or need an FSM system; building a solver rarely pays below several hundred technicians.

Path B - Build on cloud APIs

  • Routing and travel-time APIs: Google Route Optimization API / Routes API, HERE Routing and Tour Planning (HERE is Dutch, EU), TomTom, Mapbox; Azure Maps offers routing, as do other cloud vendors.
  • Optimisation as a service: Google Route Optimization API for shipment/vehicle models; Timefold Platform (Belgian, EU) offers a field service routing model as a hosted API [3][4].
  • LLM for ticket structuring: a frontier or EU model (e.g. Mistral) with structured outputs and a strict job schema.
  • Orchestration: n8n or Power Automate between FSM, ERP and map API; events trigger re-optimisation.

Path C - Self-host (open source)

  • Solvers: Google OR-Tools routing library, Timefold Solver (Apache 2.0, Java/Python), VROOM (C++ VRP engine), jsprit, OptaPlanner lineage [3][4][5].
  • Routing engines: OSRM, GraphHopper, Valhalla on OpenStreetMap data; these produce EU-hosted travel-time matrices without sending technician locations to third parties.
  • ML: scikit-learn or LightGBM for duration and no-show models; small local LLM (Qwen or Mistral-class, HW1-HW2) for ticket parsing.
  • Hardware: CPU-only server (HW1) suffices for the solver; scale cores, not GPUs.

Path D - Custom training

Reinforcement learning or learned heuristics for dispatching are still mostly research-stage; classical solvers remain the production default. Worth custom work: a job-duration and first-time-fix model trained on your own history (tens of thousands of completed jobs ideally), and learned travel-time corrections from GPS traces.

State of the art (2026)

  • Production systems run rolling-horizon, event-driven re-optimisation with continuous solving, instead of one nightly batch plan.
  • Solver plus ML hybrid is standard: ML estimates parameters (duration, no-show), the solver guarantees constraint satisfaction.
  • Customer-facing appointment optimisation: offering slots that protect route efficiency, often called "smart booking".
  • LLM copilots for dispatchers and technicians (job summary, manual retrieval, see KNOW-004; voice reporting, see SPEECH-005) are the main new layer; LLM-generated schedules without a solver remain unreliable on hard constraints.
  • Limits: poor master data (skills, stock levels), unreliable duration estimates, GPS gaps and technician acceptance are bigger failure modes than solver quality. Solutions can be locally optimal but feel unfair; fairness rules must be explicit.

Shared resources & combinations

  • Same solver and map stack: OPT-001 (delivery routing), OPT-028 (ridepooling), OPT-029 (emergency deployment), OPT-020 (disruption recovery).
  • Workforce side: OPT-003 (shift planning) provides the available-capacity input; PRED-011 forecasts workload.
  • Upstream triggers: PRED-006 predictive maintenance creates planned jobs from sensor alerts.
  • Technician support: KNOW-004 manual assistant, SPEECH-005 dictation of job reports.
  • Decision copilot: OPT-018 for natural-language what-if on the schedule.

Effort, cost & KPIs

  • Path A: weeks to a few months for configuration, master-data cleanup and training; per-user SaaS licences.
  • Path B/C: 3-9 months for a production system including integration, mobile app and change management; ongoing cost is mostly data quality and maintenance of constraints.
  • Cost drivers: master-data quality, number of constraint types, integration to ERP/FSM, mobile app.
  • KPIs: first-time-fix rate, jobs per technician-day, travel time share, SLA attainment, on-time arrival, schedule stability (re-plan changes per day), customer ETA accuracy, overtime hours, dispatcher override rate.

People & change

Involve management and the service/dispatch lead first; they define goals (travel time, first-time-fix, SLA) and trade-offs. Dispatchers and technicians are the end-users and must be part of the pilot, since they know real durations and customer quirks. IT integrates ERP and mobile devices, the DPO assesses location and performance data, and HR helps with working-time rules and training. Customers are affected by appointment windows and should be informed.

Works council: yes in practice. Scheduling tools with GPS, job times and completion data are objectively suited to monitor behaviour and performance, so §87(1) no. 6 BetrVG applies, regardless of intent (BAG). Conclude a works agreement that limits individual performance evaluation; inform under §90(1) no. 3, consider an expert under §80(3). Public bodies involve the staff council.

Data protection: a DPIA is likely (systematic location tracking of employees), plus AVV with the vendor. AI literacy: train dispatchers to read and override proposals, which supports Art. 4 AI Act. Start with one team or region as pilot, compare plans against manual dispatch, and let dispatchers keep the final say. Typical concern: "surveillance and pressure"; address with transparency about data used and no individual ranking. See GUIDE-004, GUIDE-005 and GUIDE-008.

Risks, regulation & compliance

  • EU AI Act: high risk if the system allocates tasks based on individual behaviour or personal traits and monitors or evaluates workers (Annex III point 4(b)); a pure job-and-route optimiser that uses only skills, location and availability is typically minimal risk. Classification depends on configuration; document the reasoning. Emotion recognition of technicians would be prohibited (Art. 5(1)(f)); do not add it. AI literacy (Art. 4) applies [6].
  • GDPR and labour law: GPS tracking and performance scores are employee personal data. Needs a legal basis (typically legitimate interest with proportionality test or works agreement), transparency, data minimisation (location only during working time, short retention) and consultation of the works council (in Germany, co-determination under BetrVG section 87(1) no. 6 for technical monitoring systems). Customer addresses and appointment data are personal data too.
  • Working-time law: encode the EU Working Time Directive and national rules (rest periods, breaks, driving-time rules for vans) as hard constraints.
  • Risks and mitigations: unfair workload distribution (fairness constraints, audits), safety shortcuts in emergency jobs (human override), over-reliance on bad estimates (monitor accuracy), supplier lock-in (open data model).

Getting started

  1. Baseline: jobs per day, km per job, first-time-fix rate, SLA misses and how dispatch is done today.
  2. Clean master data: skills matrix, parts stock per van, job types with realistic durations.
  3. Agree GPS and performance-data rules with works council or staff before go-live.
  4. Pilot an FSM tool (Path A) or a Timefold/OR-Tools prototype on one region with dispatcher override enabled.
  5. Review weekly: override reasons feed constraint and duration-model improvements.

Sources

  1. IFS - Planning & Scheduling Optimization (PSO) - https://www.ifs.com/solutions/field-service-management/planning-scheduling-optimization
  2. Microsoft - Dynamics 365 Field Service Resource Scheduling Optimization - https://learn.microsoft.com/dynamics365/field-service/rso-overview
  3. Timefold - Field service routing model and solver - https://docs.timefold.ai/field-service-routing/latest/introduction
  4. Timefold Solver (open source) - https://github.com/TimefoldAI/timefold-solver
  5. Google OR-Tools - Vehicle Routing - https://developers.google.com/optimization/routing
  6. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  7. Salesforce - Field Service - https://www.salesforce.com/service/field-service-management/