People get sick. They do. Especially my colleagues with kids. They run around with snotty noses, what feels like, every other week. (Whether I'm talking about my colleagues or their kids, I'll leave up to you.) For a software developer like me, that's not much of a problem. But in jobs where employees are carefully scheduled, one sick person can destroy a whole schedule.

Schedule disruption

When someone falls ill, you need to reshuffle the schedule. The difficulty here is that employees make plans around their original shifts, sometimes days or weeks in advance.

Changing someone's shifts the day before they have to come into work isn't uncommon, but can easily lead to annoyances. If my dad's shift gets rescheduled and he can't go play cards with his buddies because of it, he'll be moping about it for at least a week.

So what if we can keep schedule disruption to a minimum? That's where our disruption rules come in.

Disruption rules let you define what counts as a disruption in your operation. Not every schedule change is equal, replanned shifts seven weeks from now, or seven hours from now have vastly different impacts. Disruption rules give you a way to draw a line, so you're not treating every small tweak as a crisis, and you're not letting real disruptions slip through the cracks either.

Replanned or disrupted

Generally speaking, any shift whose employee changes during replanning, can be counted as a replanned shift. But that replanned shift isn't necessarily disrupted.

That may seem counterintuitive, so here's an example. Say you have 2 overlapping shifts:

• Shift A requires Skill 1 and Skill 2. Ann is originally assigned to this shift.
• Shift B requires only Skill 1. Ann gets reassigned to this shift because a colleague called in sick.

The shifts run at the same time. Ann has the skills for both. Should this count as disrupted?

1. No, because from Ann's perspective the shifts start and end at the same time, and she's fully qualified to do either shift.
2. Yes, because Ann's doing different work, because Skill 2 isn't needed in Shift B.
3. Yes, because Shift A and Shift B are two different shifts and any reassignment is a disruption.

All three answers can be right, it just depends on your own operation or understanding of what "disruption" means.

More control over how you count disruptions

That's exactly why we recently added new configuration options to our disruption rules. You can now define whether shifts that overlap, or start/end within a set amount of time (e.g. 30 minutes) of each other should be counted as disrupted.

You can read more about that in our documentation.

If you have a specific use case in mind, reach out. We're always happy to extend the feature to fit your requirements.

Most planning problems fit neatly into one of two camps: you're either using @PlanningVariable to assign a single value to an entity, or @PlanningListVariable to build an ordered sequence. But real-world problems aren't always that tidy.

Sometimes a production line needs both an assigned operator and a queue of jobs to process. Sometimes you've got two different kinds of planning entities that each need their own variable type. And sometimes, the items inside a list are complex enough to need their own variables too. That's where mixed models come in.

A quick refresher on variable types

Before we get into mixed models, it helps to understand what we're mixing.

A basic planning variable holds a single value. Think assigning a Shift to an Employee, or a Room to a Meeting. It maps one entity to one value from a defined value range.

A list planning variable holds an ordered sequence of planning values. Think building a route for a Vehicle by assembling an ordered list of Visits. The solver decides both which values go in the list and in what order.

Mixed models let you use both in the same solution.

Pattern 1: Both variables on the same entity

The simplest form of a mixed model is a single planning entity that carries both a basic variable and a list variable.

@PlanningEntity
public class Line {

   @PlanningVariable
   private Operator operator;
   
   @PlanningListVariable
   private List<Job> jobs;
   // ...
}


Here, Line needs to know two things: which Operator is running it, and which Jobs it's processing (and in what order). Neither variable type alone could express this — you'd lose either the assignment or the sequence.

This pattern is useful any time a single resource needs both an assignment and a workload. A manufacturing floor is the obvious example: each production line is staffed by a single operator, but processes a variable list of jobs throughout the day. The operator assignment affects skill-based constraints (can this operator run this type of job?), while the job list drives throughput and scheduling constraints (do we have enough time? are dependencies respected?).

The same structure applies to a surgical theatre that needs an assigned anaesthetist and an ordered list of procedures for the day, or a cloud VM assigned to a physical host and running an ordered queue of batch jobs. One entity, two concerns, two variable types.

Pattern 2: Multiple entities, each with their own variable

The second pattern splits things across multiple planning entities. Each entity defines its own variable type independently.

@PlanningEntity
public class Line {

   @PlanningListVariable
   private List<Job> jobs;
   // ...
}

@PlanningEntity
public class LineOperation {

   @PlanningVariable
   private Operator operator;
   // ...
}


This works well when two decisions have genuinely different cadences or ownership: different lifecycles, different constraints, or different parts of the model that don't need to be tightly coupled on a single object.

Weekly staff rostering (assigning nurses to wards) combined with daily task scheduling (ordering tasks within a shift) is a natural fit. The roster changes weekly, the task list changes daily, and keeping them as separate entities means you can re-solve either without touching the other. Fleet assignment (which truck covers which region) paired with route planning (which stops that truck makes) follows the same logic: one decision is strategic, the other is operational, and conflating them in a single entity makes both harder to reason about.

Pattern 3: A child entity with its own variable

The third pattern goes one level deeper: the items inside a list variable are themselves planning entities, each carrying their own basic variable.

@PlanningEntity
public class Vehicle {

   @PlanningListVariable
   private List<Visit> visits;
   // ...
}

@PlanningEntity
public class Visit {

   @PlanningVariable
   private DropoffPoint dropOffBefore;
   // ...
}


Here, Vehicle owns an ordered list of Visits, that's your standard vehicle routing setup. But each Visit is also a @PlanningEntity in its own right, carrying a dropOffBefore variable that links it to a DropoffPoint.

This is what makes the Capacitated Vehicle Routing Problem with intermediate stops expressible. The parent shapes the route; the child refines each stop. That separation is what makes Pattern 3 so powerful, and what makes it the hardest to model without native support.

The common thread across use cases is decisions that are scoped to an element of a list rather than to the list as a whole. Consider last-mile delivery with parcel lockers: each Visit carries a @PlanningVariable for which locker to use as a fallback if no one is home. The route is solved at the vehicle level; the fallback assignment is solved at the visit level. Two decisions, two scopes, one clean model.

Multi-modal transport works the same way. An itinerary is a list of legs on a Traveller entity, but each leg independently decides its TransportMode (train, bus, or taxi) based on time, cost, and availability constraints. Without Pattern 3, you'd be encoding that per-leg decision somewhere it doesn't belong.

Wrapping up

Mixed models are one of those features that quietly unlocks a whole class of problems that used to require awkward workarounds. If you've been shoehorning your domain into a single variable type, it's worth asking whether your model is actually mixed and if so, just saying so explicitly.

Check out the Timefold Solver docs for the full reference on planning variables and mixed model configuration.

I’ve been flying a bit more recently for speaking engagements. Dublin. CERN. A few other places in between. As fun as that sounds, it also means something else: A lot of time in airports.

Right now, as I’m writing this, I’m sitting at a gate waiting for my flight. My flight is delayed. The gate next to mine just changed. A crowd of people is collectively refreshing the airport app, hoping their boarding time magically moves forward so they don’t miss their connection.

I couldn’t help but smile and think: yep, this is a planning problem!

Over the past year, I’ve noticed something interesting about how I look at the world. I’ve written about it before, but the idea keeps coming back: Planning problems are everywhere.

I’ve joked it is sort of a curse, once you start seeing them, you can’t really unsee them. And yet people underestimate just how common they are. When you start modelling these problems, you begin to notice something interesting: they all share the same structure.

Airports: A giant optimization puzzle

Airports might be one of the best examples.

When you think about everything that has to come together, it’s really a lot! Airports are actually running several optimization problems at the same time: gate assignment, crew scheduling, aircraft turnaround planning, runway slot allocation**,** and passenger connection protection. It’s almost a wonder airports work at all.

Yet people often remember just the negative and chaotic parts: the boarding delay, the last minute gate changes or the long lines at security.

Working with planning problems on a daily basis, I see things a little differently. Just understanding the immense complexity behind creating an initial plan already makes me feel calmer about the chaos.

Think about the decisions involved:

• Which gate should each flight use?
• Which crew can legally operate a flight after delays?
• How do we minimize missed connections?
• Where should incoming aircraft be parked?
• How do we re-route passengers when things go wrong?

Every delay or mishap ripples through that system of decisions, forcing the plan to be re-evaluated.

When the chaos hits, like it has around me writing this, I realize that this is just the result of a complex system constantly trying to adapt its plan as the situation changes.

And honestly, I can’t help but admire the attempt 🙂.

Irish breakfast, but optimized

Apparently I don’t even need to be fully awake to get bitten by the optimization bug.

After a busy evening speaking at a user group in Dublin and a shorter night than I hoped for, I dragged myself to a nearby breakfast restaurant to grab a proper Irish breakfast with a fellow optimization enthusiast.

As we were talking about the different projects we’d worked on, I became fascinated with the restaurant’s open kitchen layout. And once again, my mind drifted toward optimization.

A restaurant kitchen is basically a job scheduling system. Orders arrive dynamically. Each dish requires different preparation steps. The kitchen has limited resources: burners, ovens, chefs, and time.

The staff constantly make small scheduling decisions:

• Which order should be cooked first?
• Which dishes can run in parallel?
• How do we avoid one table waiting forever?

Experienced kitchens develop an intuition for it, but under the hood it resembles a classic job-shop scheduling problem.

And I couldn’t help but think how I’d model this problem as an optimization problem.

Sure, this kitchen is at a small scale. But structurally, it’s not that different from much larger systems.

CERN

I was lucky enough to be invited to speak at Voxxed Days CERN, which came with some awesome perks, including a guided tour through the facilities. You probably guessed it by now, but even here it made me wonder about the planning challenges behind the scenes.

• Scheduling maintenance for all different facilities
• Allocating compute resources for analysis jobs
• Coordinating experiments and detector usage

Even at one of the world’s most advanced research labs, the same fundamental problem appears again and again: “How do we allocate limited resources in the best possible way?”.

And of course, my brain was already buzzing with ways to optimize it.

Seeing the pattern

If you are involved with planning optimization solutions, a pattern starts to emerge that you can’t unsee. Many everyday systems share the same underlying structure:

• Resources (gates, buses, chefs, CPUs)
• Tasks (flights, routes, orders, jobs)
• Constraints (time limits, capacity, regulations)
• Objectives (speed, cost, fairness, efficiency)

…and the challenge becomes finding the best possible plan.

Optimization problems are just amazing puzzles… and quite addictive 🙂 The only downside is that once you start thinking this way, it becomes hard to stop.

You start seeing optimization problems everywhere:

In airports. In supermarkets. In conference schedules. In traffic lights. In restaurant kitchens.

Sometimes you’re just standing in line somewhere and suddenly catch yourself thinking:

This could be optimized!

Much to the dismay of my partner and friends, who occasionally see me drift off mid-conversation.

But when things go sideways, like delays at an airport, it also brings a strange kind of calm.

Because the chaos we see in the real world often isn’t chaos at all.

It’s a plan being repaired in real time.

And if you know how to look at it…

You start seeing optimization problems everywhere.

We recently announced Timefold Solver 2.x, slated for somewhere later this month. It’s our first real major version since the fork (1.x was largely a package rename from the old OptaPlanner days) which means it’s finally time to address some issues we’ve been wanting to tackle for ages. One of them was modularity.

Java's public challenge

In Java, classes have a few visibility options. private, package-private, protected, and public. Large libraries often end up marking internal classes as public so different packages inside the library can interact. That’s exactly what happened in Timefold over the years.

As the codebase grew, some classes were technically public but never meant to be used by consumers. You’ve probably seen them:

ai.timefold.solver.core.*impl.*

Those packages contain implementation details of the solver. But since the classes were public, they were sometimes used anyway. From a user’s perspective, the reasoning is understandable: "If it’s public, why shouldn’t I use it?"

For years, Java lacked a visibility level that meant “public within this codebase, but not part of the supported API.” That changed with the introduction of Java Platform Module System (JPMS), which we will formally be supporting starting with Solver 2.0.

With JPMS we can explicitly choose which packages are exported and which remain internal.

module ai.timefold.solver.core {

   exports ai.timefold.solver.core.api.domain.common;
   exports ai.timefold.solver.core.api.domain.entity;
   exports ai.timefold.solver.core.api.domain.solution;
   exports ai.timefold.solver.core.api.domain.solution.cloner;
   
   // rest of file excluded
}


Exported packages are the supported API. Everything else stays internal. In other words:

public no longer means “public to the world.”

(If you run everything on the classpath instead of the modulepath, JPMS boundaries can still be bypassed. But for Solver 2.x, exported packages define the supported API.)

Why does this matter?

This change is mostly about clarity and long-term stability.

With explicit API boundaries we can:

• avoid accidental dependencies on internals
• refactor internal code more freely
• make upgrades less risky

Internal classes may change or disappear without notice. Exported packages are the stable API.

If you depend on internal classes

If your code imports packages containing .impl., you’re probably using internals.

Sometimes that happened because certain advanced use cases required it (e.g. Custom Moves). We’re actively working on replacing those patterns with supported public APIs.

If you have a legitimate use case that depends on internals, we’d like to hear about it. The goal isn’t to block anything, it’s to provide stable ways to do what you need without relying on implementation details.

If you’re using Timefold Solver and have concerns about internal classes you depend on, now is a great time to let us know.

Over the past decade, enterprises have invested heavily in understanding their data. Enterprises that have learned how to work with their data are in a strong position to forecast future needs, spot efficiencies, and act on opportunities.

If your field service organization has reached that point (or is getting close) there is one more door that structured, accessible data unlocks: optimization.

Not the vague, aspirational kind of optimization. The kind where you feed your technician availability, customer appointments, and job locations into an engine that produces the best schedule for the day - respecting every shift limit, skill requirement, time window, and lunch break - and returns it in seconds. 

Optimization can be a key differentiator for many enterprises, but it is only as good as the data it consumes. In this post, we will walk through the data prerequisites for field service scheduling optimization, and explain why data readiness matters, which specific data you need (and where it typically lives), what opportunities open up once it is structured, and how to put it to work.

Why data readiness determines optimization success

A scheduling optimization engine is, at its core, a constraint solver. It takes a precise description of your planning problem (every technician, every job, every rule) and finds the best feasible assignment of work to people across time and space.

The operative word is precise. The engine cannot infer what it does not know. If a technician's lunch break is not in the data, the optimizer will schedule visits straight through it. If a customer's availability window is missing, the engine has no reason to avoid sending someone at 7 AM. If locations are inaccurate, travel time calculations fall apart, and the beautifully optimized route becomes fiction the moment a technician starts driving.

The quality of the output is bounded by the quality of the input. Organizations that have invested in structuring and owning their operational data are already past the hardest part. The remaining step is understanding which data optimization requires, and mapping it from where it already lives.

Which data do you need?

Field service optimization consumes three categories of data, each representing a different dimension of your operation. If you are familiar with spreadsheet-based scheduling, think of these as the tabs in your planning workbook. The difference? Instead of a planner manually cross-referencing them, an engine processes them all simultaneously.

1. Employee and vehicle data (the supply side)

This describes your workforce: who is available, when they work, what they can do, and when they need a break.

In the optimization model, each vehicle represents a technician and their transport for a given day. A vehicle record includes an id, the operating date, shift boundaries (minStartTime and maxEndTime), an optional maxSoftEndTime for overtime flexibility, the technician's skills, their startLocation and endLocation (typically home or a depot), a technicianRating, and any requiredBreaks for that day.

Breaks are defined within each vehicle's shift. Each break includes an id, a type (floating for a lunch that can slide within a window, or fixed for something like a medical appointment that cannot move), the date, a minStartTime and maxEndTime defining when the break can occur, and optionally a locationId if the technician needs to be somewhere specific for it.

Here is a simplified example of what this looks like as structured data:

{
"id": "vehicle-1",
"date": "2025-06-10",
"minStartTime": "08:00",
"maxEndTime": "17:00",
"skills": ["HVAC", "electrical"],
"startLocation": "loc-depot-01",
"endLocation": "loc-depot-01",
"requiredBreaks": [
  {
    "id": "break-1",
    "type": "floating",
    "minStartTime": "11:30",
    "maxEndTime": "13:30"
  }
]
}


This data typically lives across your HR or workforce management system (for shifts, skills, and PTO), your fleet management tool (for vehicle assignments), and sometimes a separate time-and-attendance platform. The key is being able to extract it per day, per technician, in a structured format.

2. Customer and work order data (the demand side)

This is every job that needs to happen: where, how long, when, and under what conditions. 

Visits are the core unit of demand. Each visit includes an id, a name, a locationId linking it to a physical address, a serviceDuration (how long the job takes on-site), any requiredSkills the technician must have (matching the skills defined on the vehicle), a latestSlaEndTime if there is a contractual deadline, a priority level, and optionally a visitGroupId for jobs that require multiple technicians on-site simultaneously.

Each visit also includes one or more time windows defining when the customer is available. A time window has an id, a date, and a minStartTime and maxEndTime. A window of 10:00 to 13:00 means the technician must arrive within that range. Some visits may have multiple windows across different days, giving the optimizer flexibility in scheduling.

The completeness of your time windows and skill requirements often determines how much optimization headroom you actually have. If the engine does not know a customer is only available in the morning, it cannot avoid scheduling an afternoon arrival.

This data typically originates in your CRM, ERP, ticketing system, or field service management application.

3. Geographical data (the physical reality)

The third pillar ties everything together spatially. Without it, the optimizer has no concept of distance or travel time.

Locations are simple but critical: each record is an id, a latitude, and a longitude. These location IDs are referenced everywhere, in visits (where the job is), in vehicles (where the technician starts and ends their day), and in vehicle breaks (where a fixed appointment takes place).

This data lives in your CRM, address databases, or GIS systems. If you are still working primarily with street addresses, geocoding them into coordinate pairs is a prerequisite. Street-level addresses introduce ambiguity, a geocoded coordinate does not.

The optimization engine uses these coordinates to compute real-world travel times and distances between every relevant pair of points. The accuracy of your locations directly determines the accuracy of every route the engine produces.

What opportunities open up

Structuring and connecting these three data pillars is not just a checkbox exercise. It is the foundation for a fundamentally different way of operating.

From manual assembly to automated optimization. Today, dispatchers and planners spend hours each morning assembling routes by hand: Cross-referencing technician availability, customer windows, skill requirements, and geography, often in spreadsheets or on whiteboards. With structured data, this entire process becomes an API call. The engine considers every constraint simultaneously and returns an optimized plan in seconds.

From static plans to real-time replanning. A technician calls in sick at 8 AM. An emergency job arrives at 11:00. A visit runs an hour over. With structured, accessible data, you update the inputs and re-solve. The engine does not carry stale assumptions from the morning schedule. It takes the current reality and produces the best schedule from this point forward.

From gut feeling to explicit trade-offs. Should you minimize mileage or minimize overtime? Is SLA compliance more important than travel efficiency? With structured data and a configurable optimization model, these become tunable parameters with measurable impact. Not judgment calls made under pressure at 6 AM.

From siloed reporting to operational KPIs. Optimization outputs include metrics like total travel time, overtime incurred, visits completed versus unassigned, and utilization per technician. When your input data is clean and complete, these outputs become trustworthy enough to drive strategic decisions.

Putting it into practice

Most organizations will not find all three data pillars neatly organized in a single system. That is normal. The integration challenge is not about migrating everything into one database. It is about building a pipeline that assembles the optimization input from your existing sources and keeps it flowing.

Step 1: Map your sources. For each data entity (vehicles, vehicle breaks, visits, visit time windows, visit groups, locations), identify which system of record holds the authoritative version. Document where gaps exist: missing coordinates, incomplete time windows, skills not yet digitized.

Step 2: Close the gaps. Geocode addresses into coordinates. Ensure every technician's shift has explicit start and end times. Capture customer availability as structured time windows, not free-text notes. Define skills as a controlled vocabulary, not ad-hoc descriptions.

Step 3: Build the extraction layer. Create repeatable, automated exports from each source system. This could be API integrations, database queries, or scheduled file exports, whatever your systems support. The goal is to assemble a complete optimization dataset on demand, not through manual effort.

Step 4: Transform and submit. Map your extracted data into the structure the optimization engine expects (each vehicle with its shifts and breaks, each visit with its time windows and skills, each location as a coordinate pair) and POST it as a JSON payload to the API. Timefold's Field Service Routing API is stateless by design: it takes the full problem description, validates the input, solves it, and returns the optimized route plan. It does not store your data between runs. Each request is self-contained.

Step 5: Integrate the results. The response contains the optimized assignments - which visits land on which vehicle shift, in what order, with arrival times, departure times, and travel durations - plus KPIs summarizing overall plan quality. Push these assignments back into your dispatch system, mobile app, or field service management platform.

This stateless architecture is a deliberate choice that keeps you in control. Your data stays in your systems and you send only what is needed for each run. Any system that can make an HTTP request can integrate. When reality changes mid-day, you update the inputs and re-solve with no stale state. And every input and output is a complete, self-describing JSON document you can version, compare, and audit.

The takeaway

Data readiness is not a prerequisite you endure before the real work begins. For many organizations, it is the highest-leverage work and the foundation that makes forecasting, analysis, and optimization possible.

If your field service operation has been investing in structuring and owning its data, you are closer to optimization than you might think. The data you need already exists in your systems. The remaining step is connecting it.

And once it is connected, the results follow: less time on the road, more visits per day, fewer SLA breaches, and dispatchers freed to focus on exceptions rather than assembly. Not because of a magic algorithm, but because you gave the algorithm something precise to work with.

If you want to see how your data maps to the optimization model, explore Timefold's Field Service Routing documentation or start a trial on the platform.

Field service engineers don't resist technology because they fear change. They resist it because they've seen what happens when tools ignore how work actually gets done.

The objection we hear most often from operations leaders: "Our FSEs self-schedule. They won't accept a system that tells them where to go."

They're right to be cautious. But the choice isn't between autonomy and optimization. The best-performing field service organizations have found a third way.

The real problem with self-scheduling

Self-scheduling persists because it solves real problems. Engineers know their territories. They understand which customers need extra time. They've built relationships that smooth difficult service calls.

But self-scheduling also creates invisible costs:

• Route inefficiency compounds daily. An engineer who prefers to work east-to-west on Mondays might be adding 30 minutes of drive time without realizing it. Multiply that across a 50-person team and 250 working days.
• You have to trust blindly. The 80-20 rule applies here. Even if 80% of your employees schedule in good faith, there's always a minority that takes advantage of their freedom.
• The bigger picture stays invisible. Engineers often schedule only their immediate workload. They can't see that shifting Tuesday's route would unlock a more efficient Wednesday, or that a job they're avoiding this week will cascade into a scheduling nightmare next week. Longer planning horizons (across days, weeks, over the full team) reveal efficiencies that short-term, individual scheduling simply cannot surface.
• Skill mismatches go undetected. The best-qualified engineer for a complex repair might be in the next territory, but self-scheduling never surfaces that option.
• Preference conflicts accumulate. When three engineers all want Fridays off, or all avoid a difficult customer site, someone ends up overloaded, usually the newest team member who hasn't yet learned to game the system.

Can you afford the efficiency gap between what your team produces and what's mathematically possible?

Why FSEs push back on optimization

If optimization delivers clear efficiency gains, why the resistance?

Because most pure optimization tools treat engineers as interchangeable units to be deployed, not as skilled professionals with legitimate preferences and local knowledge.

When an algorithm assigns routes without explanation, engineers lose trust. When the schedule ignores a technician's need to pick up their child on Wednesdays, it fails the human test. When the system can't answer "why am I driving past this job to reach one further away?", it invites workarounds.

The result: engineers learn to game the system, dispatch overrides multiply, and the theoretical efficiency gains evaporate in practice.

This is a design failure, not an optimization failure.

The hybrid model: Optimal starting points, human control

The solution is not choosing between optimization and autonomy, but architecting systems that provide both.

Start with mathematically optimal schedules. The optimization engine generates routes that account for every constraint: geography, skills, time windows, equipment, SLAs, labor rules, and historical performance. This is objectively the best possible starting point, one that no human could calculate manually.

Present schedules as recommendations, not mandates. Engineers see their daily route with clear rationale. They can accept it as-is (which they probably should, since it's mathematically proven to be the most efficient solution given all constraints) or they can adjust it.

Enable controlled adjustments. If an engineer needs to be in a specific area on Wednesdays, they can set that preference. If they want to make a personal stop, they can adjust the route. If they see a better option based on local knowledge, they can make the change. Whether it's display as a drag-and-drop UI, or as re-optimize button with new constraints, engineers keep working on their terms.

Explainable AI: The trust architecture

Optimization without explanation is a black box. Engineers won't trust it, and operations leaders can't defend it.

For any scheduling decision, the system should articulate which constraints drove it: "You're assigned this job because you hold the required certification and are 12 minutes closer than the next qualified option." When trade-offs exist, show them: "Swapping these two stops would save 8 minutes of drive time but push the priority customer outside their SLA window."

When engineers can see why a schedule looks the way it does, resistance transforms into collaboration. Questions like "wouldn't it be better to go here first?" get answered in plain language, whether it's geographical clustering, skill-matching, time windows, or SLA requirements driving the sequence.

Engineers become partners in optimization rather than subjects of it.

Self-scheduling vs. optimized scheduling

Implementation without disruption

Even more than distrust, the strongest objection to any new system is disruption. Field service operations can't pause while IT rebuilds the scheduling stack. The right approach integrates optimization via API into existing dispatch systems and mobile apps. Why? Because engineers keep using familiar interfaces, and dispatchers keep their dashboards. Start with a pilot team, run optimization in parallel, compare results, and expand once the efficiency gains are proven.

A different conversation

The field service teams that succeed with optimization aren't the ones that override engineer autonomy. They're the ones that reframe the conversation.

Self-scheduling asks: "What route do I want to run today?"

Optimized scheduling asks: "Given everything we need to accomplish, what's the best version of the day I want to have?"

The second question is better. It respects engineer preferences while acknowledging that individual choices affect teammates, customers, and business outcomes.

When the optimization engine handles the combinatorial complexity, engineers can focus on what they do best: solving problems, building customer relationships, and applying the expertise that no algorithm can replicate.

That's the balance worth building toward.

[highlight]

Timefold provides scheduling optimization for field service operations through an API that integrates with existing dispatch systems. The platform produces explainable schedules with full constraint transparency, enabling teams to balance operational efficiency with workforce autonomy.

[highlight]

I like labor laws, but holy cats, they're complex to implement. The people who formulated the labor laws wanted to ensure the well-being of employees, but forgot about the poor engineers who have to implement them.

Take a look at this scheduling constraint for example:

This is what we call a (headache) Conditional Constraint. Let me show you how I solved it.

Dealing with conditional constraints

The first step is to understand the requirement. "Every seven days" means that I need to group shifts in 7 day windows we call these “rolling windows”. "If they work a night shift" means that I need to count the night shifts in this group of shifts. "Work a Maximum of 40h" is what I need to evaluate and penalize in that same group of shifts, if I detected a night shift.

Next, I want to lay out how I want my constraint to look.

1. I need to count the amount of shifts worked in a rolling window
2. I also need to track the minutes worked in that same rolling window
3. I want to filter shifts with certain tags, but independently for both previous rules, i.e. we want to count night shifts, and penalise the time worked of all shifts
4. Everything should be high performance and scale up to at least 100.000 shifts
5. The API should be minimal, clear, extensible, specific...

With the rules set, I can start working on this. Grouping the shifts for (1.) and (2.) can be difficult, but luckily I can just do a cheeky copy paste from our existing constraints. Combining them can also be pretty challenging, because I have to penalize a group of shifts, if the same group of shifts exists in the other stream. 

But the answer lies in how you formulate the problem. "... if ... exists ..." is the perfect case to use the constraint node ifExists. A benefit of using ifExists in this case, is that we ensure scalability and performance.

API design

Another difficult step is creating an easily extensible, specific, easily understandable API. During our design meeting, we settled on:

{
"rollingWindowRules": {
  "id": "max 36h worked if night shift is present",
  "window": 0,
  "minutesWorkedLimit": {
    "minutesWorkedMax": 2160 // 36 * 60 minutes
  },
  "condition": {
    "triggerLimit": 1,
    "type": "MIN_SHIFTS_WORKED",
    "includeShiftTags": [ "night shift" ],
    "shiftTagMatches": "ALL"
  }
}
}


Let's see if it meets our requirements. 

1. minimal: yes, we only added the 'condition' field.
2. extensible: yes, a type to specify what type of condition the triggerLimit will represent, for example MIN_SHIFTS_WORKED or MIN_MINUTES_WORKED. I only implemented these two, but we can easily add more.
3. specific: yes, we allow the filtering of shifts with our includeShiftTags.

Conclusion

I'm proud of how the constraint turned out. I managed to create a design for a complex problem that makes full use of the constraint stream's performance capabilities and is still readable and extensible. Creating new conditions is super easy now. So if you're interested in having a condition like "if the time off exceeds 48h then ..." or "if the amount of consecutive shifts worked exceeds 3 then..." Please do contact us, and I'll be so glad to put my hard work to good use!

Whenever I speak at a conference or just casually talk to people about what we do here at Timefold, I often get asked:

“What is the hardest part of solving the optimization problems?”.

My answer is always the same: “the human side”.

This usually leads to surprised faces. Surely, humans can’t be harder than solving an optimization problem with more possible solutions than there are atoms in the observable universe? And yet, when talking to other optimization experts, they will probably tell you the same.

The math is hard. The psychology is harder.

Cognitive Biases at Work

When we use Timefold to optimize a plan, that plan usually matches all the constraints and is by all formal definitions better than what a human planner would have created in a similar time. Yet, when shown to the stakeholders, the first things they see is usually something like:

• The one technician who now starts 20 minutes earlier.
• The one employee who has to work a different day.

Not the 98 improvements. The 2 changes. And they might hate it.

This is the status quo bias in full swing! Change feels risky, even when the plan is objectively better. “This is how we’ve always done it” is a powerful force. People tend to convince themselves that sticking with something worse but familiar is safer, until the problem grows to a scale the current problem can’t solve anymore.

Even before implementation, another bias creeps in. Stakeholders often say: “Let’s just improve what we have. It shouldn’t take long.”

That’s the planning fallacy. We consistently underestimate how long incremental fixes will take. “Just a few tweaks” turns into months of spreadsheet archaeology and fragile macros.

We underestimate the effort required to evolve a manual or semi-manual process because we imagine best-case scenarios not messy reality. That’s why software estimates quietly grow buffers. We’re compensating for our own optimism.

The planning fallacy often meets another one: the sunk cost fallacy. Instead of moving to a entirely novel way of planning their operations, they will try to improve their current solution, whether that is with some custom software development, or adding another bunch of macros to their Excel spreadsheets.

“We’ve put too much work into this to abandon it now.” So instead of moving forward, we keep patching yesterday’s solution.

Let’s say the optimized plan does go live. Drivers ignore the suggested route because “they know a faster way.” Planners manually override assignments because “this is how we usually do it.” That’s the well-travelled road effect at work. Familiar processes feel faster and better than they actually are.

People underestimate how long manual planning takes because they’ve done it for years. The friction has become invisible. And when it’s invisible, why would you ever deal with “change”?

Where Optimization Actually Breaks

None of these biases are irrational. They’re human.

Optimization is rarely blocked by math. It’s blocked by psychology.

The real constraints in planning projects are often:

• Fear of change
• Overconfidence in familiar workflows
• Emotional attachment to past investments
• Unrealistic timelines

So when people ask me what the hardest part of optimization is, I still give the same answer: “the human parts of the schedule”. An optimization tool can search millions of possibilities per second. But humans decide whether the result is accepted.

And honestly? That’s not a bug. It’s a reminder that planning education isn’t just about better models. It’s about better awareness of both the mathematical and human limitations.

Modeling hard constraints is easy. Modeling human behavior is not.

[highlight]

‍TL;DR – Key takeaways

• Field service routing optimization automatically assigns technicians to jobs and sequences their daily routes by solving a variant of the Vehicle Routing Problem (VRP).
• It satisfies hard constraints (shift hours, skill requirements, SLAs) while minimizing soft objectives like total drive time, overtime, and operating cost.
• Organizations deploying AI-based routing optimization typically see 25 – 35% less drive time, more jobs completed per day, and measurable SLA improvement (Timefold deployment data).
• Manual scheduling and rule-based dispatch cannot solve this problem at scale: the number of possible schedules for 50 technicians and 200 jobs exceeds the atoms in the observable universe.
• Modern routing optimization is delivered as an API which field service management (FSM) platforms embed as a back-end engine, not a standalone tool.

[highlight]

What is Field Service Routing Optimization?

In practical terms, a field service operation starts each day with a set of jobs that need to be completed, a workforce of technicians with different skills, availability windows, and home locations, and a set of rules governing what is and isn't a valid schedule. Routing optimization is the process of computing the best possible solution to this assignment and sequencing problem. Automatically, at scale, and fast enough to update throughout the day as conditions change.

The term "routing optimization" is sometimes used interchangeably with "route planning" or "dispatch scheduling." These are related but distinct. Route planning (as offered by tools like Google Maps or traditional mapping APIs) determines how to travel between two known points. Routing optimization determines which technician should go to which job, in what order, accounting for hundreds of real-world constraints simultaneously. It is a fundamentally more complex problem.

Key distinction: Route planning answers "how do I get from A to B?" Routing optimization answers "who should go where, in what order, given all the constraints we operate under?" for an entire workforce, for the entire day/weeks/months, updated continuously.

Why Field Service Scheduling is hard

Consider a field service operation with 50 technicians and 200 jobs to schedule. The number of ways to assign those jobs to technicians - before even considering the sequencing of routes - exceeds 10³⁰⁰ possible combinations. For context, the estimated number of atoms in the observable universe is approximately 10⁸⁰. No dispatcher, and no rule-based software, can evaluate more than a tiny fraction of the solution space.

This is why field service scheduling is classified as a variant of the Vehicle Routing Problem (VRP) one of the most studied optimization problems in operations research and first formulated in 1959. The VRP is NP-hard, meaning there is no known algorithm that can find the provably optimal solution in polynomial time for large instances. In practice, this means real-world field service operations use metaheuristic solvers:  Algorithms that search intelligently through the solution space to find solutions that are near-optimal within practical time constraints.

Field service adds additional complexity on top of standard VRP because it must also handle:

• Skill requirements: not every technician can perform every job
• Customer time windows: jobs must start within a specific availability window
• Service level agreements: priority jobs carry contractual completion commitments
• Multi-day and multi-shift planning: some jobs span multiple days or require sequenced visits
• Real-time disruptions: urgent jobs, no-shows, and traffic changes require intraday re-optimization
• Fairness and labor compliance: schedules must distribute workload equitably and comply with shift and overtime rules

How Field Service Routing Optimization works

At its core, a routing optimization engine solves what is formally known as a Capacitated Vehicle Routing Problem with Time Windows and multiple side constraints (CVRPTW+). The process follows three stages:

1. Problem encoding

The engine encodes the scheduling problem as a formal optimization model. This involves defining planning entities (technicians, shifts, visits), decision variables (which technician is assigned to which visit, in what position in their route), and constraints (the rules that define a valid and good schedule).

2. Constraint evaluation and scoring

Constraints are separated into three categories based on their weight in the scoring system:

• Hard constraints
  Must never be violated. Breaking a hard constraint makes the schedule infeasible. Examples: skill requirements, shift availability, required time windows.
• Medium constraints
  Should be satisfied where possible but can be relaxed when resources are insufficient. Example: maximizing the number of visits assigned in a day.
• Soft constraints
  Optimization targets that improve the quality of the schedule. Examples: minimize total travel time, minimize overtime, balance workload fairly across technicians.
• Preferred constraints
  Desirable but lower-priority preferences. Examples: preferred time windows, customer affinity (same technician as previous visit), coverage area alignment.

Each candidate schedule receives a score across hard, medium, and soft dimensions. A schedule that breaks zero hard constraints but has a soft score of −1,000,000 is always better than one that breaks even a single hard constraint, because the latter is simply not a valid schedule.

3. Solver search

The solver applies metaheuristic search algorithms (techniques like simulated annealing, tabu search, and large neighborhood search), to explore the solution space efficiently. Starting from an initial solution, the solver iteratively proposes modifications (moving a visit from one technician to another, swapping two visits in a route, inserting an unassigned visit) and accepts changes that improve the score. The result is a high-quality near-optimal schedule delivered within a configurable time budget.

The Constraint Model in Field Service

A complete field service constraint model covers six categories: visit dependencies, SLA compliance, shift hours and overtime, skill and seniority matching, fairness across technicians, and route optimization objectives. Each constraint group is independently configurable.

The practical value of a routing optimization engine is determined largely by the depth and accuracy of its constraint model. The following constraint categories are standard in a production field service scheduling system:

Timefold allows constraint weights to be configured, so that operators can express the relative priority of competing goals (e.g. "SLA compliance is more important than travel minimization") without modifying the underlying model. 

What results to expect: Benchmark data

Organizations deploying constraint-based routing optimization typically achieve 25-35% reductions in technician drive time, higher visit throughput with the same workforce, and measurable improvements in first-time fix rate due to better skill-to-job matching.

• 25-35% Reduction in technician drive time after optimization
• <2 mo Typical time-to-value when integrating via API (vs 15+ months for in-house builds)
• 1,000s Technicians schedulable simultaneously by a single optimization engine

A 25-35% reduction in drive time has compounding operational benefits. For a field service team with 100 technicians each spending an average of two hours per day driving, a 30% reduction recovers approximately 60 technician-hours per day - equivalent to gaining 7-8 additional technicians without hiring. Those hours can be converted into additional visits, reduced overtime, or earlier shift ends.

The improvement is achieved by simultaneously solving three problems that human dispatchers and rule-based tools handle in isolation: who goes where (assignment), in what order (sequencing), and how to respond when plans change (re-optimization). Human dispatchers are good at recognizing obviously bad schedules, but cannot hold thousands of interdependencies in mind simultaneously to find globally optimal ones.

On "the last 20%": Early-stage routing tools (basic nearest-neighbor algorithms) can capture roughly 60-70% of available efficiency gains with minimal setup. Reaching 90%+ of the theoretical optimum requires a proper constraint solver. The gap between a good greedy heuristic and a metaheuristic optimizer often represents 10-15% of total drive time, which is material at scale.

Manual scheduling vs Routing Optimization: A direct comparison

Manual scheduling by dispatchers is feasible for fleets of 10-20 technicians but degrades rapidly at scale. For operations with 50+ technicians, algorithmic optimization consistently outperforms manual dispatch on both efficiency and SLA compliance metrics.

It is worth noting that routing optimization does not eliminate the role of dispatchers. The technology empowers them to do more. Instead of spending the majority of their time constructing schedules manually, dispatchers in optimized operations review AI-generated plans, handle edge cases requiring human judgment, and manage customer escalations. The optimization engine handles the combinatorial work; humans handle the exceptions.

Real-time re-optimization

Real-time re-optimization automatically recalculates routes and assignments when disruptions occur (like urgent jobs, cancellations, traffic delays) producing an updated plan within seconds without requiring manual dispatcher intervention.

A static daily schedule, produced once in the morning, degrades throughout the day. Technicians run late, customers cancel, emergency jobs are called in. Without re-optimization, dispatchers manually insert changes and hope the rest of the schedule holds. In practice, a cascade of small disruptions can make an optimized morning schedule look like an unplanned afternoon.

Real-time re-optimization - sometimes called intraday re-scheduling - addresses this by treating the schedule as a continuously updated plan rather than a daily fixed output. When a trigger event occurs, the engine receives the current state of all ongoing and pending work, re-solves the assignment and routing problem for all unstarted visits, and returns an updated schedule. Visits already in progress are locked; the solver optimizes around them.

Key re-optimization triggers in production systems include:

• Insertion of a new urgent or emergency visit
• Technician becoming unavailable (sick, vehicle issue)
• Visit cancellation requiring workload redistribution
• Significant travel time deviation due to traffic
• Job overrun requiring subsequent visit rescheduling

The "Smart Reassignment" use case, where an unexpected technician absence triggers automatic identification of the best available backup, is a direct application of real-time re-optimization. Rather than requiring a dispatcher to manually review availability and skills, the engine re-solves the affected portion of the schedule and surfaces a recommended replacement with full route and timing context.

How Routing Optimization is delivered: The API model

Field service routing optimization is delivered via REST API. An FSM platform submits a dataset describing jobs, technicians, and constraints to the optimization engine, which returns a complete optimized route plan, typically within seconds to minutes. Timefold's Field Service Routing API can handle up to 30,000 visits in one optimization run.

Routing optimization is not a standalone application, it is an engine embedded within a broader field service management platform. FSM software handles the user interface, job management, customer communication, and mobile workflows. The routing optimization engine handles the mathematical scheduling problem as a back-end service.

The integration pattern is straightforward. The FSM platform sends a POST request to the optimization API endpoint with a JSON dataset describing the planning problem: vehicles (technicians and their shifts), visits (jobs and their constraints), and configuration parameters. The engine processes the dataset and returns an optimized route plan, the specific assignment of visits to vehicle shifts, with arrival times and route sequences for each technician.

For FSM product teams evaluating routing optimization engines, the key integration considerations are:

• Constraint coverage - does the engine's model support the specific constraints your customers operate under?
• Re-optimization latency - how quickly can the engine respond to intraday trigger events?
• Scale - what is the tested performance at the fleet sizes your enterprise customers operate?
• Deployment flexibility - is the engine available as a managed cloud service, on-premise, or both?
• Integration timeline - how long does it take to go from API access to a production-grade integration?

Frequently Asked Questions

What is the difference between routing optimization and GPS navigation?

GPS navigation determines the fastest path between two known points. Routing optimization determines the best assignment of work to a fleet of technicians and sequences their routes to minimize travel time across all technicians simultaneously, while satisfying all scheduling constraints. These are different problems: one is pathfinding, the other is combinatorial optimization.

Can routing optimization handle jobs that span multiple days?

Yes. Multi-day planning windows are a standard feature of production routing optimization models. The engine treats each technician shift as a separate planning unit and can handle jobs that require sequential visits across days, jobs with delayed dependencies (e.g. a visit that cannot happen until 48 hours after a prior visit), and rolling planning horizons that extend weeks into the future.

What happens when a technician doesn't have the required skill for an urgent job?

The constraint model enforces skill requirements as hard constraints by default. This means the engine will not assign a job to a technician who lacks the required skill, regardless of proximity or availability. When an urgent job cannot be covered by any available technician with the required skill, the engine surfaces this as an unassigned visit so the dispatcher can take manual action (e.g. calling in a specialist or escalating to an external contractor).

How does routing optimization handle customer time windows?

Time windows can be encoded as hard constraints (the visit must start within the window and violations make the schedule infeasible) or soft/preferred constraints (the visit should start within the window where possible, but can be scheduled outside it to maintain overall schedule feasibility). The engine honors the window type specified and minimizes any deviations from preferred windows when hard constraints make full compliance impossible.

Is routing optimization the same as FSM software?

No. Field Service Management (FSM) software is a broad category covering job management, mobile workforce apps, customer portals, invoicing, and reporting. Routing optimization is a specific computational capability (the scheduling and routing engine) that is typically embedded within an FSM platform. Some FSM platforms build this engine themselves; others integrate specialized routing optimization APIs to provide this capability without the internal development burden.