Why AI is the Key to Fair Scheduling

Employee scheduling isn’t just a logistical puzzle - it’s about fairness, compliance, and well-being. In high-stakes industries, ensuring staff get adequate rest isn't just "nice to have"; it’s a regulatory necessity.

Smart Compliance, Better Rest

Timefold uses advanced constraint programming to move beyond simple calendars. Our AI-driven platform balances operational efficiency with the human side of work:

• Automated Time-Off: Seamlessly integrate vacation and leave requests without breaking the schedule.
• Guaranteed Rest Periods: Automatically enforce mandatory downtime between shifts to prevent burnout and ensure safety.
• Cross-Industry Precision: Whether it’s nurse rostering, airline crew management, or field service dispatch, our API adapts to your specific labor laws and union rules.

Watch the video to see how intelligent optimization keeps your team rested and your business compliant.

Stop Juggling Shifts: 

In complex industries, you can’t just assign anyone to any shift. Whether it's healthcare, aviation, or field services, compliance and skill-matching are non-negotiable.

Timefold is an enterprise-grade scheduling API that replaces manual guesswork with intelligent automation.

What are the best algorithms to optimize a Vehicle Routing Problem (VRP)?

How do you automatically assign visits to vehicles while minimizing travel time?
And which technology actually makes this possible at scale?

The Vehicle Routing Problem (VRP) sits at the core of fleet optimization  and solving it efficiently is far from trivial. From greedy approaches to advanced AI-driven methods, there are multiple ways to tackle it, each with its own trade-offs.

In this video, Geoffrey De Smet breaks down the key challenges behind fleet routing optimization and explores the different algorithmic approaches available today, including:

• Greedy algorithms
• (Meta)heuristics
• Mixed Integer Programming (MIP) solvers (with optional GPU support)
• Machine learning and AI techniques
• Emerging approaches like quantum computing

More importantly, he explains how these concepts translate into real-world solutions using Timefold Solver (open source) and Timefold’s REST APIs.

Whether you're building field service routing or solving pickup and delivery problems, this video shows how to move from theory to practical, scalable optimization.

We're running live demos across the Timefold Platform and two core models (Field Service Routing and Employee Shift Scheduling), walking through the features that matter most for engineering teams building and running scheduling systems in production.

What we'll cover:

• Platform: Timefold Platform v1.0, the new Solve Queue and configuration overrides from the UI
• Field Service Routing: Technician area preferences, co-located visit grouping, and machine-readable validation
• Employee Shift Scheduling: Shift breaks for labor law compliance, per-employee disruption rules during replanning and and the employee & shift Efficiency X-Ray
• Looking ahead: Insights into our Q2 plans and where we are headed. A first glimpse at our Pickup & Delivery Routing API. 

No slides-heavy presentations, this is a hands-on demo session.
We'll leave time for questions at the end.

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.

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:

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.

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.

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.

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.

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!