Field Service Scheduling and Route Optimisation

Ask a field service vendor how their scheduling engine works and you usually get a demonstration rather than an answer: a map, a set of pins, a progress bar, then a tidy set of routes with a percentage saving printed on top. What you are watching is a solver attacking a vehicle routing problem with time windows, plus a stack of side constraints specific to your business, under a time budget of a few seconds. It returns a good answer, not the best answer, and the gap between those two words is where most of the disappointment in this category lives. Understanding the problem shape is what lets you specify the software properly, judge the results, and tell when the schedule it produced is unachievable rather than ambitious.

The message up front: optimisation quality is bounded by constraint fidelity and data truth, not by the algorithm. A solver given accurate durations, accurate skills data and honest travel times will beat a good dispatcher on a large territory. The same solver given optimistic durations produces a confident, beautifully packed plan that collapses by ten in the morning, and the operation blames the software rather than the input.

1. The problem shape: this is a vehicle routing problem, not a sorting exercise

Be clear first about what class of problem you are asking the software to solve. Field service scheduling is a variant of the vehicle routing problem, or VRP, which in its basic form asks: given a set of locations to visit and a fleet of vehicles starting from a depot, what set of routes visits every location at least total cost? Field service adds layers, and each one makes the problem harder.

• Time windows turn it into VRPTW. A job may only start within a window: a promised morning slot, a site accessible only between certain hours, an SLA response deadline. This is the constraint that most changes the character of the problem, because it removes the freedom to reorder.
• Heterogeneous resources with skills make it a multi-skill VRP. Engineers are not interchangeable vehicles: a gas-safe engineer cannot substitute for a high-voltage-authorised one, so each job has an eligible subset rather than the whole fleet.
• Individual start and end locations break the single-depot assumption. Most engineers start and end at home, so each effectively has their own depot, and that position constrains which territory they can serve economically.
• Priorities and optional visits mean not all jobs must be served today. Real operations routinely have more demand than capacity, so the solver chooses which jobs to schedule as well as how to sequence them. That prize-collecting variant is the one most operations face.
• Parts and capacity add a loading dimension. A job needing a part not on the van is not schedulable for that engineer today, whatever the map says.

Stack those together and you have a rich, constrained, multi-objective problem. The consequence is computational: the VRP is NP-hard, and time windows plus skill eligibility make it harder still. No known method finds the guaranteed optimal answer for a realistic instance in usable time. A hundred jobs and fifteen engineers is already far beyond exhaustive search.

2. Why solvers return good answers rather than optimal ones

Because exact optimisation is out of reach at operational scale, every commercial scheduling engine uses heuristics and metaheuristics: a fast constructive heuristic to build a feasible starting schedule, then local search or a metaheuristic such as tabu search, simulated annealing, large neighbourhood search or a genetic algorithm, running until a time limit expires. Open-source solvers like Google OR-Tools and Timefold, and the engines inside Salesforce Field Service, IFS, ServiceMax, Oracle Field Service and Microsoft Dynamics 365 Field Service, all sit somewhere in this family even where the implementation is proprietary.

Two practical implications follow. First, the answer depends on the time budget: two seconds returns a decent schedule, two minutes usually returns a better one. That is why a nightly batch run on tomorrow's work can beat in-the-moment reoptimisation, and why you should ask a vendor how long their engine runs rather than only how good the result looks in a demo with twelve jobs. Second, the answer is not reproducible in the way people expect. Run the same data twice through a randomised metaheuristic and you get two different schedules of similar quality. Dispatchers notice, and it looks arbitrary. Explain it up front: the engine is searching, not calculating.

3. The constraint set that must be modelled honestly

This is the heart of a scheduling implementation. Output is only credible if the model matches operational reality, and the commonest cause of a rejected schedule is a constraint that exists in the field but not in the model. The table below is the checklist I would walk through with an operations lead before any engine is configured.

Two notes on using that list. Distinguish hard from soft deliberately: statutory skills, committed windows, site access and permits are hard, while travel minimisation, engineer preference and territory familiarity are soft and tradeable. Configure everything as hard and the solver will frequently find no feasible solution and leave jobs unscheduled, which operations reads as the system failing. And capture the constraints you have, not the ones a reference model says you should have: eight accurate constraints beat twenty of which half are guesses.

4. Objective functions and why one objective produces a schedule nobody accepts

Once the constraints are in place you have to tell the engine what "better" means. This gets the least attention in implementation and causes most of the friction afterwards, because different parts of the business want different things and the objective function is where that argument gets settled, whether or not anyone realises they are settling it.

Read that table as a set of tensions rather than a menu. Every objective in it is legitimate, and optimising any single one produces a schedule some part of the operation will refuse. The practical approach is a weighted composite objective, with the weights written down and agreed by operations, account management and field leadership before go-live, then revisited after a month of real running. What I would recommend is starting with SLA attainment and committed windows heavily weighted, travel moderately, and utilisation lightly with a deliberate slack allowance, then tightening once durations have proven accurate.

The other half is measuring the trade-off rather than asserting it. Drive utilisation up three points and on-time arrival down five and you have made the operation worse while improving the metric that was easiest to report. The field service KPIs and SLAs pillar is the companion to this section, and the SLA matrix design pillar covers how the response and resolution targets feeding the objective should be structured in the first place.

5. Dynamic versus static scheduling, and the churn problem

There are two broad operating modes, and most organisations need a considered blend rather than a choice.

Static scheduling optimises a fixed horizon, typically tomorrow, in a batch run. Overnight the engine has all known demand, a generous compute budget and no moving parts, and the plan is published before engineers start. Planned work, inspection rounds and pre-booked appointments fit this naturally, and the plan is stable enough that engineers can prepare: check the parts, read the asset history, load the van. Dynamic scheduling reoptimises during the day as reality arrives: reactive calls, overruns, no-access outcomes, sickness, a breakdown. A genuinely reactive workload needs it, because a plan that ignores what has happened by eleven in the morning is fiction by noon.

The failure mode of dynamic scheduling is churn. If the engine reoptimises everything each time anything changes, an engineer's remaining work is rewritten several times a day. The consequences are predictable and I have watched them play out more than once.

• The engineer cannot prepare, because the next three jobs at eight are not the next three at ten. Parts do not get picked, asset history does not get read, and first-time fix drops.
• The van is loaded for the wrong work, since loading happens once and the schedule changes afterwards.
• Customers get retimed repeatedly, which is worse than a single honest window.
• Trust goes. Engineers stop treating the schedule as real and negotiate informally with the dispatcher, reintroducing exactly the manual coordination the system was bought to replace.
• The metrics look fine throughout, because churn is not measured by default.

The pattern that works is to make stability an explicit objective and protect a horizon. Freeze the current job and the next one, so an engineer always knows their immediate future with certainty. Allow reoptimisation beyond that frozen horizon, but penalise change in the objective function so the engine only moves a visit when the gain clearly exceeds the disruption cost. And measure churn: count how many times an average visit is rescheduled after publication. Above one, you have a churn problem regardless of what the efficiency dashboard says.

Which jobs are eligible for dynamic reassignment at all is a design decision, not a technical default. Committed appointments should not be moved by an algorithm; unbooked reactive work can be. Where the human dispatcher fits around this, and the discipline the dispatch board itself needs, is the subject of the work order dispatch and scheduling software pillar, the operational counterpart to this technical one. Where machine learning is applied to the dispatch decision itself, the AI workforce and route dispatch optimisation pillar takes it further.

6. Appointment booking: offering slots the schedule can actually keep

Appointment booking is where scheduling becomes customer-facing, and where an over-tuned engine does the most reputational damage. The question is a capacity question asked in reverse: given everything already committed, which slots can I offer that I will genuinely be able to serve? Three approaches, in increasing order of sophistication and fragility:

• Fixed grid with counted capacity. Divide the day into slots per territory and allow a set number of bookings per slot. Crude, transparent, hard to beat when demand is homogeneous. It fails when durations vary widely, because one slot is not one unit of work.
• Feasibility-checked offers. For each candidate slot, ask the engine whether the job could be inserted into some engineer's route without breaking a hard constraint, and offer only the slots that pass. The right default for most operations, and honest by construction.
• Cost-ranked offers. Rank the feasible slots by marginal cost of insertion and steer the customer toward the cheap ones, for instance a wider window or a small incentive where an engineer is already nearby. Widely used in high-volume domestic service, but it needs volume and it is easy to over-steer into slots customers do not want.

Two rules I would hold to regardless of approach. Offer the widest window the customer will accept rather than the narrowest you can theoretically hit, because a four-hour window you keep is worth more than a one-hour window you miss. And hold back a defined reserve of same-day capacity for emergencies, or every genuine emergency becomes an overtime call.

The tension worth naming: every appointment booked is a fixed point constraining tomorrow's optimisation, so a day full of narrow committed windows cannot be routed efficiently however good the engine is. Booking flexibility and routing efficiency are the same resource spent twice.

7. Capacity planning versus daily scheduling

These are separate disciplines on separate horizons, and conflating them is a common and expensive mistake. Daily scheduling allocates today's work to today's people. Capacity planning decides whether you have the right number of people, with the right skills, in the right places, weeks and months ahead. No scheduling engine solves a capacity problem; it only makes the shortfall visible, as jobs left unscheduled or breaches no sequencing could have avoided. The horizons I would separate explicitly:

• Annual and quarterly: headcount, skills mix and territory structure, driven by forecast demand, contracted PM load and the geographic spread of the asset base. This is where the recurring workload from your preventive maintenance schedule becomes a labour requirement rather than a list of tasks.
• Monthly: shift patterns, leave, training and standby rotas, levelling planned work away from predictable reactive peaks.
• Weekly: which planned jobs land in which week. Planned work is the buffer that absorbs reactive variability, and levelling it is the highest-leverage scheduling act available, precisely because it is not urgent.
• Daily and intraday: sequencing and assignment. The only horizon the optimisation engine addresses.

The diagnostic to run before buying optimisation: compare total available productive hours against total required work hours, including realistic travel, for the last complete quarter. If required exceeds available you have a capacity problem, and optimisation will recover some travel time without closing a structural gap. Buying a solver to fix a headcount deficit is a well-trodden way to spend a budget and keep the problem. The broader operating-model view sits in the field service management practitioner's guide.

8. The data the engine needs, and where it usually comes from

Optimisation is an integration project wearing an algorithm costume. The engine consumes several datasets, each owned by a different system and often a different team, and the weakest one sets the quality of the output.

Two links deserve attention. The travel matrix: straight-line distance is not travel time, and off-peak driving is not peak driving. A credible implementation uses a real road-network matrix with time-of-day profiles. Some engines cache a static matrix for speed, defensible on a rural territory and misleading in a dense city with a sharp peak, so ask which it is. And the actuals loop: the schedule must come back with actual arrival, time on site, outcome and parts used. Without it you cannot learn durations, measure churn, or tell whether optimisation helped, which is why the mobile app matters to the optimisation story and not only to the engineer. The practicalities are in the mobile field service apps pillar, and the criteria that carry these requirements into a tender are in the how to choose field service management software pillar.

9. Measuring whether optimisation actually helped

Almost every optimisation business case is built on a vendor percentage, and almost none is verified afterwards, because nobody set up the measurement before switching the engine on. Three things have to be right.

The baseline has to be honest. The comparison is not optimisation against chaos, it is optimisation against what a good dispatcher already achieves on that territory. Experienced dispatchers are genuinely good at this, holding local knowledge the model does not have: which engineer is quick on which asset type, which site is difficult after three o'clock, which customer needs handling. On a small territory with a stable team a good dispatcher is often close to what a solver achieves, and the solver's real advantage appears at scale, in territories too large to hold in one head, and in consistency when that dispatcher is on leave. Anyone who tells you the baseline is terrible has not measured it.

The measurement has to be comparable. Capture one clean period of before data: travel time per completed job, jobs per engineer-day, on-time arrival against committed window, SLA attainment by priority, first-time fix, overtime hours, and reschedule count per visit. Seasonality, weather, a mobilisation and a change in work mix all move these numbers more than the engine does, so a before-and-after across a quarter boundary proves little. Where you can, run a controlled comparison instead: two comparable territories, one optimised and one dispatched as before, over the same period. Never a clean experiment, but it controls for season and demand mix far better, and it usually costs nothing.

The metric set has to be balanced. Report travel, productivity, on-time arrival, SLA, first-time fix and overtime together, because the whole risk of this exercise is improving one at the expense of the others and declaring victory. If travel per job falls while on-time arrival falls too, optimisation did not help; it moved the cost somewhere that was not on the dashboard.

10. Where optimisation fails: data quality, above everything else

This is the honest section, and the one I would ask anyone considering route optimization software to read twice. In my experience the algorithm is almost never the problem. Commercial engines are competent. Projects fail on input data, and on two inputs in particular.

Wrong job durations. This is the dominant failure. Most organisations hold durations that are a single default applied to everything, an estimate entered once by someone optimistic, or a standard time that ignores travel within a site, parking, induction, isolation, cleanup and paperwork. A solver treats those numbers as truth. It will pack the day to the minute against a ninety-minute estimate for work that reliably takes two and a quarter hours, and it will do so with total confidence, because from the model's point of view the plan is feasible. By the third job the engineer is an hour behind and every remaining window is broken. The plan was never achievable; it only looked achievable because the input was wrong.

The insidious part is the asymmetry. A dispatcher with optimistic durations builds a loose plan anyway, knowing the numbers are soft. The solver has no such instinct. It believes you. Bad durations therefore do more damage under optimisation than under manual dispatch, which is the opposite of what people expect and the reason some operations get measurably worse immediately after go-live.

Wrong skills data. Competency registers rot quietly: certifications lapse without being updated, skills are recorded as an aspiration after a training course rather than as demonstrated competence, codes are too coarse to be meaningful ("electrical" covering both a lighting replacement and an HV switching operation), and new capabilities are never added. Under manual dispatch this is survivable, because the dispatcher knows who can really do what. Under optimisation it produces assignments that fail on arrival, and each one costs a visit, a travel leg and a piece of customer credibility.

The other recurring failures follow the same theme. Geocoding errors that put a site in the wrong district. Missing access hours. Travel matrices with no traffic profile. Engineer home addresses held as one depot for everyone. Work orders with no honest priority, so everything is urgent and priority carries no information. And unmodelled work: the ad hoc jobs, callbacks and favours that consume real hours but never enter the system, so the model believes in capacity that does not exist.

The remediation sequence is unglamorous: measure actual durations from mobile app timestamps across a representative sample of job types; rebuild the duration library from measured medians rather than optimistic means, including travel-within-site, access and paperwork; audit the competency register against real certificates and expiry dates; verify geocodes for the sites generating most visits; capture access hours where they matter; and only then turn the objective weights toward efficiency. Optimisation should be the last thing you configure, not the first.

11. A realistic implementation sequence

• Measure the baseline first. A quarter of clean data on travel per job, jobs per engineer-day, on-time arrival and first-time fix. You cannot recreate this retrospectively.
• Fix durations and skills. The longest task and the highest return. Do not proceed while either is untrustworthy.
• Write the constraint model down in plain language before configuring anything, marking each constraint hard or soft, and have operations and field leadership sign it. Most configuration arguments are disagreements about this document that nobody wrote.
• Agree the objective weights explicitly, with the section 4 trade-offs on the table. Write down what you are choosing to sacrifice.
• Run the engine in advisory mode. Let it propose, let the dispatcher accept, reject or amend, and log the overrides. That log is the most valuable artefact in the project: each override is either a missing constraint or a training gap.
• Automate the stable subset where overrides have dropped near zero, keeping human control over the rest. Full automation is a destination, not a starting configuration.
• Measure, then tune the weights against the baseline on the full balanced metric set, continuously rather than once.

Advisory mode is the step most often skipped under delivery pressure, and skipping it is why so many engines end up switched off or routinely overridden six months after go-live. It is how you find what the constraint model is missing while the cost of being wrong is still just a rejected suggestion.

The idea to walk away with

Route optimisation is a genuine engineering capability, and on a large territory with accurate inputs it beats manual dispatch consistently, at a scale no dispatcher can hold in their head. But it is bounded on two sides: it cannot be better than the constraint model you gave it, or the data you fed it. A solver is an amplifier. Give it truth and it amplifies your operational judgement; give it optimistic durations and stale skills data and it amplifies the error into a confident, unachievable plan while removing the human instinct that used to absorb the difference.

So the sequence is the opposite of the sales process. Measure the baseline honestly, because a good dispatcher is a real benchmark. Fix durations and skills first. Write the constraints down and mark them hard or soft. Agree the objective weights as a business decision rather than letting whoever configured the system set them. Protect a frozen horizon. And measure a balanced metric set afterwards, because improving travel while breaking on-time arrival is not an improvement.

Final thoughts

The most useful thing I can offer anyone about to buy route optimization software is a reordering of priorities. The engine is the easy part, and the part vendors compete on. The hard parts, the duration library, the competency register, the access data, the travel matrix, the objective weights, the frozen horizon, the override log, are all yours, and none are in the licence. Teams that do that work get most of the benefit promised. Teams that skip it get a well-presented plan the field will not follow, and a slow retreat to the dispatcher's own judgement, which was never as bad as the business case assumed.

One starting action: pull a month of mobile app timestamps and compare actual time on site against your estimated durations, by job type. The gap you find is the size of the problem optimisation would inherit, and it tells you more about readiness than any demonstration will.

Related reading: Work order dispatch and scheduling software, AI workforce and route dispatch optimisation, Field service management: a practitioner's guide, Field service KPIs, SLAs and contractor management, Mobile field service apps for technicians, AI maintenance schedule and resource optimisation.

External references: Google OR-Tools , ISO , SFG20 .