Field-Team Scheduling: Availability, Skill and Travel Time in One Plan

A field-team schedule is built from two kinds of rule: hard constraints that may not be broken, and soft preferences that should be honoured where possible. The goal is not the cheapest plan. It is a feasible plan you can explain to the technician and the dispatcher without anybody opening the code.

What has to be defined before anything is scheduled

A schedule can never be better than the data feeding it. These are the fields without which any algorithm returns something that looks plausible and cannot be executed.

The field most often skipped is estimated duration, and it is exactly the one that makes a plan infeasible. A day holding eight jobs is neither busy nor light - that depends entirely on whether they are 30 minutes each or 110.

Why is travel time the constraint that breaks naive schedules?

Because it is not a property of a job, it is a property of a pair. A travel duration exists only between job A and job B, at a particular hour, for a particular vehicle - which is why it cannot be stored on the job.

• It depends on order. The same five jobs in a different sequence can total 70 minutes of driving or 160.
• It depends on the hour. A drive that takes 14 minutes at midday takes considerably longer after 16:00 in urban areas. A travel matrix computed once for the whole day describes a day that does not exist.
• It disappears inside the arithmetic. A quarter of an hour of uncounted travel between eight jobs is two missing hours in a working day - one and a half jobs that quietly fell out.
• It includes things that are not driving. Parking, finding the entrance, the lift, waiting at the security desk. Better to call that a buffer and declare it explicitly than to discover it as lateness.

The practical approach is to compute travel as a duration between two points at an estimated departure time, and to add a fixed buffer per stop. Both numbers are visible on the plan, and both can be tuned against what actually happened last month.

Hard constraint against soft preference

That separation is the whole difference between a system you can trust and one that produces impossible jobs:

• Hard constraints: a valid certification, the required skill, the technician's working hours, the window promised to the customer, vehicle capacity, and availability of specialist equipment. Breaking any one of these invalidates the plan.
• Soft preferences: less total driving, balanced load across technicians, keeping the same technician with a familiar customer, and less idle time. These enter the cost function and compete with each other.

The common failure is turning a hard constraint into a preference with a high weight. That works until a busy day, when the system "decides" it is worth sending a technician without a work-at-height certification because he was 12 minutes closer. A hard constraint has to filter candidates before the computation, not compete inside it.

Why a feasible, explainable plan beats an optimal one

Routing problems with time windows, skills and capacity are not solved to proven optimality in reasonable time at operational sizes, and they do not need to be. The OR-Tools routing library shows the shape of the approach: pick a first-solution strategy such as PATH_CHEAPEST_ARC, add a local-search metaheuristic such as GUIDED_LOCAL_SEARCH, and set a search limit. The documentation notes that search limits terminate the solver after it reaches a specified limit, such as a maximum length of time or a number of solutions found. Without a time limit the search simply keeps going.

Three design decisions follow:

• Set an explicit compute budget, say 20 seconds to plan a full day. What you get back is the best plan found in that time, not "the plan".
• Do not promise a percentage saving. You can compare the generated plan against the plan a dispatcher built by hand on the same day, and that is a real number. "30% less driving" is a promise with no source behind it.
• Run the same input twice. If the result changes between runs, fix the seed - a dispatcher who sees a different plan on every refresh stops believing the system.

The explanation matters as much as the result. Each assignment carries one line: "chosen for work-at-height certification, 18 minutes from the previous job, inside the 09:00-13:00 window". That sentence turns a manual override into an argument about a fact rather than a feeling.

Related: automating appointment scheduling, an Israeli holidays API for scheduling, daily field reporting over WhatsApp.

What happens when the day breaks at 11:40?

This is the real test. Take a day with three technicians and 11 jobs. At 11:40 a job estimated at 60 minutes stretches to 150, because the pump that was ordered is the wrong model.

1. Detect the overrun early. The technician reports "running long" from the app, rather than you discovering it when he fails to arrive at 12:15.
2. Freeze anything already started. A job in progress does not move. A re-plan that relocates a technician already on site is what makes crews stop opening the app.
3. Re-plan only what was hit. The next two jobs of that technician, not all 11. A full re-plan on every change produces a day nobody can follow.
4. Re-check the hard constraints. A job requiring a certification only one technician holds does not move to another, even if that one is free.
5. Tell the customer before the window breaks, not after. A 13:00-17:00 window communicated at 12:50 is an update; the same message at 17:10 is a complaint.
6. Mark what slipped to tomorrow and place it at the front of that plan, otherwise a job deferred once gets deferred again.

What the technician sees and what the customer sees

• The technician sees an ordered list for the day with address, window, estimated duration and required equipment - not a map from which a sequence has to be inferred.
• He also sees the travel time the system assumed. A persistent gap between assumption and reality is the data that calibrates the buffers.
• The customer receives a window rather than an exact time, and every change to that window is sent when it happens.
• A dispatcher's manual override is stored with a reason. After a month, that list of reasons is the list of constraints your model is missing.

Sources

• Google OR-Tools - Vehicle routing problem
• Google OR-Tools - Routing options, search limits and metaheuristics