We are pleased to announce we are working on the next major release of Timefold Solver 2.0. This release represents a substantial evolution of the solver, focused on:

• delivering a cleaner API
• improved maintainability

What’s coming in Timefold Solver 2.0

1. A streamlined, future-ready API

When Timefold continued OptaPlanner, we kept a number of legacy and deprecated APIs to ensure a smooth transition for early adopters. Today, those legacy constructs limit our ability to innovate.

With Solver 2.0, we will remove all deprecated functionality. This will:

• Simplify and modernize the developer experience
• Reduce ambiguity and technical debt
• Unlock future improvements in performance, stability, and usability

2. Significant ease of use improvements

Over the past year, we’ve introduced several enhancements to reduce complexity and speed up model development, including:

• Custom Shadow Variables (replacing most custom VariableListener implementations)
• @PlanningListVariable (now fully equivalent in capability to chained variables)

Solver 2.0 continues this process by removing:

• Classic VariableListener implementations
• Chained planning variables
• Additional legacy constructs that no longer provide value, many of which have been deprecated for years.

These changes make Timefold Solver easier to adopt and significantly reduces the learning curve for new engineers.

[highlight]

Introducing Enterprise license keys

Disclaimer: Only for Timefold Enterprise Clients

Beginning with Timefold Solver Enterprise 2.0, enterprise customers will be required to configure a Timefold Enterprise license key.

This ensures:

• Proper activation and compliance for enterprise deployments
• Access to enterprise-grade features and support

Configuration is straightforward and will be documented clearly in the migration guide. The new license key mechanism is designed to minimize operational overhead while aligning with industry-standard enterprise software practices.

[highlight]

A clear and guided upgrade path

To make the transition to Solver 2.0 as smooth as possible, we will provide:

• A comprehensive migration guide outlining every required change
• OpenRewrite recipes to automate the majority of updates
• A structured plan for larger changes that cannot be automated

Our goal is to reduce risk and ensure predictable upgrade timelines for enterprise teams.

Long-term support for Timefold Solver 1.x

We recognize the importance of stability and predictability in enterprise environments. 

• Timefold Solver Enterprise Edition 1.x will continue to be supported in line with support clauses in contracts and released versions will remain available from our repository.
• Timefold Solver Community Edition 1.x will be maintained throughout 2026 with quarterly bug-fix releases and security updates.

This gives organizations ample flexibility in planning their migration window. In the case these timelines would be troublesome for your organization, please reach out to us so we can understand your situation and find alternative solutions.

How to start preparing today

You can begin preparing your codebase for Solver 2.0 now:

• Upgrade to the latest 1.x release using our OpenRewrite migration assistance
• Remove usage of all deprecated APIs
• Begin migrating larger components if they are used:
  • Custom Variable Listeners → Declarative Shadow Variables
  • @PlanningVariable(type = CHAINED) → @PlanningListVariable

Proactively adopting these changes will make the final upgrade significantly easier.

What’s next

Upon release, we will:

• Publish the full list of changes, including details about license key configuration
• Keep the migration guide continuously updated

Thank you for your partnership and continued trust. We are excited to bring you the next generation of Timefold Solver. If you have any questions, don’t hesitate to reach out to us through your enterprise contact.

Despite being children of television, internet and smartphones ourselves, my wife and I are extra protective towards our 2 year old son. We’d much rather he play outside or with his toys than watch television. To make sure we stay aligned when television is allowed, we came up with a simple decision diagram.

Raising a kid turns out to be a never-ending stream of decisions. We don’t have a diagram like this for everything. Being intentional takes time and energy, so we reserve it for the decisions that really matter.

Parenting isn’t special in that sense. Decisions are everywhere. In a restaurant, someone decides who gets served first. A manager decides who works late. A system decides what comes next in the queue.

Decisions need to be made all the time. You can’t opt out. Even not deciding is a decision.

Decision Heuristics!

Making decisions all day is exhausting. So we take shortcuts. We rely on what is called decision heuristics, simple rules of thumb that help us move fast without thinking too hard. Most of the time, they show up as “just the way we do things”.

“First-come-first-served (FCFS)” is one of these rules. It feels fair. But is it?

At a frituur (yes, the Belgian fries place, but replace this with any take-out restaurant), is it reasonable that someone ordering a single pack of fries waits half an hour because the person in front placed a party-sized order?

First-come-first-served assumes all requests are equally important. We ignore urgency, impact, or downstream cost. All for the sake of “easier to plan and execute”.

Another classic default is alphabetical ordering. Many of us experienced this in school. If your last name starts with an A, chances are you were often called on first to present your work or to answer questions. This “decision” has lingering effects. Students later in the alphabetical order often receive lower grades and get fewer chances to take the lead, which has a long term impact on their development and job opportunities.

In some parts of academia, authors are listed in alphabetical order (and not by size of their contribution), which disincentivises people later in the alphabet to co-author, as their name will be swallowed by their arch nemesis: “et al.”

These are just two decision heuristics. Others include hard-coded priorities in software systems, automatic functions in spreadsheets nobody understands anymore and the king of accidental decisions: “We’ve always done it this way”.

From Accidental to Intentional

The real risk of sticking with accidental decisions isn’t that they’re wrong. It’s that they quietly block better options. For some critical decisions, we need to become more intentional. Deliberate. Just starting with planning optimization forces clarity. It’s a thinking tool, and with it, you can no longer dodge the hard questions:

• What do we want to optimize for?: Employee happiness? Throughput? Endless heaps of $$$?
• What constraints do we have?: Availability? Maximum capacity of our warehouses and vehicles?
• What trade-offs are we willing to make?: e.g. Do we accept more overtime, if that enables us to give people more days off?

Simply answering these questions already improves the quality of your decisions.

Second, a good planning optimization tool unlocks scenarios that are otherwise practically impossible to reason about with pen and paper or a thousand post it notes.

• A take-out service optimized for lower average wait time can prevent a single large order from blocking many small orders.
• Work rosters that respect employee preferences (in addition to availability) suddenly become manageable.

These options often get ignored not because they lack value, but because they’re too hard to reason about.

Decision Intelligence, Not Decision Delegation

Becoming more intentional doesn’t mean handing decisions over to algorithms. It means refusing to hide behind them.

The role of a good planning optimization tool isn’t to replace human judgment, but to support it. By making trade-offs visible, constraints explicit, and alternatives comparable, it turns vague instincts into conscious choices.

Not just delivering a solution, but providing the context needed to question it, adjust it, and ultimately stand behind it.

Accidental decisions have a kind of gravity. Once in place, they keep pulling everything back to “this is how we do things.”

Decision intelligence gives us the leverage to push back against that gravity so we can decide deliberately, instead of drifting by default.

Life recently threw a wrench in the well-oiled machine that is my household. Due to some health issues, my partner needs to rest, meaning the domestic duties that usually land on her plate have shifted to mine.

This includes my nemesis: Cooking.

Give me the "dirty jobs": Taking out the trash, changing diapers and I’m content. But making dinner? That does not spark joy for me. My partner is the chef; I’m usually just the guy who eats the result.

I am stepping up now (like any good partner should)! As she was guiding me through a complex recipe the other day, I had an epiphany: this feels a lot like an integration project… and I’ve seen many of those in my career!

Let me explain.

Shopping (data hunt)

When you cook, you need ingredients. In the AFK world, you walk into one supermarket, buy everything, and leave. Integrating a planning solution should work the same way. Ideally, your data is neatly stored in a single database, or ERP, ready to be used.

In reality however, your "ingredients" are scattered across a logistical nightmare of many different locations.

• The Grocery Store: Your main ERP.
• The Specialty Shop: That legacy HR system from 1998.
• The Garden: Sticky notes on a monitor.
• Foraging in the Woods: The brain of that one planner who "just knows" which trucks have maintenance issues.

Just like you can’t make a stew without finding the beef, you can’t run an optimization without locating your data. Even if it’s currently living on a piece of paper in someone’s back pocket.

Mis-en-place (data prep)

After you’ve gathered your ingredients, any good chef (this includes my darling wife) knows what comes next: mis-en-place: Washing vegetables, chopping onions…. putting everything in its place. It’s the quiet work that pays off later, sparing you from stress when the kitchen gets hot.

The biggest issues I had while cooking came from a lack of preparation, I’d just started cooking, then suddenly read “peel 8 potatoes and slice them into bits” while I already had 2 other pans on the stove.

When integrating systems, mis-en-place is the stage where you gather, clean, standardize, and reshape your data before your optimizer even touches it!

Quite often, you’ll want to:

• Resolve Formats: Is 2026-02-01 February 1st or January 2nd? (You usually don’t know until you find a row saying 2026-01-31).
• Validate Constraints: Ensure birthdates aren’t in the future and Country Codes are actually ISO standard.
• Map Identifiers: ensuring CC in one system matches CREDIT_CARD in the other.

This step isn’t fancy or flashy, but it’s essential. Without it, you are making the job much harder for yourself. Just like trying to cook while searching for the garlic you swear you chopped ten minutes ago.

Sizzling pans and boiling water!

Now comes the part everyone thinks of when they hear “cooking”: the pots, the pans, the boiling water transforming sticks into spagethi. This is where raw ingredients become dinner.

In planning solutions, this is the solving phase. The point where your planning solution takes all that carefully curated data and actually computes something meaningful. Where the chaos of real-world requirements gets melted into a delicious soup of possibilities and solutions.

When things come together, it’s a special feeling. When running an optimization on our Timefold Platform, I sometimes can’t help but stare at our score graph as the solution gets slowly better, burning away all the excessive fat and leaving just the good parts.

Serving / plating

A meal isn’t done when it leaves the pan; it’s done when it hits the plate in a way that makes people want to pick up a fork. Presentation matters. Feedback matters. And ideally, whoever eats the dish walks away happy.

Similarly, after you have a solved planning problem, you need to present it clearly. Whether you use dashboards, reports, visualizations, or API responses, stakeholders need to understand what changed, why it changed, and what actions they should take.

Basically, you conduct a taste test. This is where reality hits. You serve the plan, and the stakeholder takes a bite.

• “This is great, but…”
• “Bob can’t drive that truck, he’s allergic to manual transmissions.”
• “We actually need this delivered by 4 PM, not 5 PM.”

Just like seasoning a sauce, you take that feedback, adjust the constraints, and iterate. The first plan, like the first pancake, is rarely perfect. But by iterating, the system becomes sharper, smarter, and tastier.

The takeaway

(the lesson-y one, not the food-y one)

As I’ve been cooking more meals, it’s been clear to me there are so many similarities with integrating software. None of the phases listed above stand alone. The shopping, the prep, the cooking, the plating… each one sets up the next, each one depends on the last.

Planning systems work the same way. Good data unlocks good optimization, good optimization doesn’t say that much without clear presentation, and clear presentation fuels better feedback and iteration. When all those pieces support each other, the result feels less like a sequence of chores.

Why Field Service Scheduling and Routing is so hard to get right in 2025

Field service operations look simple from the outside: take jobs, match them to technicians, schedule routes, and send people out into the world. But anyone who has managed real field service teams knows the reality:

• Technician calendars are fragmented with “white-space gaps.”
• Travel time variation destroys efficiency.
• Skill mismatches cause failed visits.
• Strict customer time windows restrict route flexibility.
• Jobs appear, cancel, or shift constantly throughout the day.
• Dispatchers often handle far too many variables manually.

Even well-run teams lose 20-40% productivity from avoidable travel, idle time, and inefficient assignment patterns. Fuel costs, overtime, and missed SLAs compound quickly.

The core reason?

Routing + scheduling in field service is a complex optimization problem (stemming from the Vehicle Routing Problem and the Traveling Salesman Problem). It's far beyond simple “map routing” or “drag-and-drop calendar management.” It requires mathematical optimization that can balance constraints, and respond instantly to real-world changes.

This is why FSM vendors increasingly embed a high-performance routing engine like Timefold directly into their platforms.

What is a Field Service Route Scheduling API?

What does a Field Service Route Scheduling API engine actually do?

A routing & scheduling API engine is a back-end system that calculates the best possible assignment and route order for technicians. It:

• Ingests job data (location, duration, skills needed, time windows).
• Understands technician attributes (skills, shift times, home base, capacity).
• Computes optimized route plans that minimize travel, maximize utilization, and meet SLAs.
• Automatically re-optimizes schedules as jobs are added, canceled, or delayed.
• Generates technician-by-technician itineraries and ETAs.

It’s not a map, and it’s not just a calendar. It’s an optimization system that continuously balances constraints across the entire fleet.

How is a Field Service API different from typical routing software?

Traditional route planning tools were built for logistics or delivery. Field service adds complexity:

• Skills and certifications
• Parts or equipment constraints
• Customer SLA windows
• Technician familiarity or geography
• Variable job duration
• Dynamic job insertion
• Emergencies or other unforeseen circumstances

A specialized API like Timefold is built for these nuances and delivers real-time results at scale, integrated directly into your existing FSM UI or workflows.

Why Field Service Management tools embed Timefold's Field Service API

Field Service Management software companies choose Timefold because it strengthens their product without increasing their development burden. Timefold gives vendors a reliable scheduling engine they can integrate quickly, so they can enter new markets faster and compete more effectively. It helps product teams improve customer outcomes, reduce onboarding friction, and support larger and more complex field service operations with confidence. 

By relying on Timefold for routing and scheduling, FSM providers can focus on what they do best: building the workflows, user experience, and industry-specific tools that set their platforms apart. Vendors gain a stronger value proposition, more upsell opportunities, and a clear performance advantage that helps them win and retain customers.

How to evaluate a Field Service Routing and Scheduling API 

A practical vendor checklist.

Optimization quality

Look for:

• Reductions in travel distance (we see an average of about 25%)
• Balanced workload distribution
• Highly consistent on-time arrival rates

Real-time re-optimization

The engine should handle:

• New jobs dropped during the day
• Cancellations or overruns
• Emergency visits
• Technician absences or delays

APIs like Timefold re-optimizes in seconds, not minutes.

Scalability

Your API should comfortably handle:

• 100–500,000+ jobs per run
• Dozens to tens of thousands of technicians
• Complex constraints and multi-day scheduling

APIs like Timefold is engineered for enterprise-scale FSM platforms.

Constraint support

Field service needs more than basic routing. Key capabilities include:

• Skills + certifications
• Shift times and breaks
• Customer priority or SLA windows
• Time-dependent travel
• Parts or equipment constraints
• Mandatory follow-up visits
• Depot or hub rules
• Complex service durations

APIs like Timefold are is designed to encode all of these.

Performance and latency

Consider both:

• Job-to-route computation time
• Consistency under load

Developer experience

FSM vendors depend on integration speed. You might require:

• Clean REST API
• Elite documentation
• Enterprise-level support
• A clear and fast POC

Timefold’s Field Service Scheduling API at a glance

Timefold is a high-performance constraint-solving API engine that computes optimal technician schedules and routes for field service at any scale.

Differentiators

• Built on battle-tested solver technology.
• Designed specifically for API-ready product teams.
• Handles complex constraint logic better than generic routing systems.
• Performance-tuned for instant, repeated intraday optimization.

Real-world impact

FSM vendors using Timefold typically see:

• An average of 25% reduction in travel time
• 20–40% fewer missed SLAs
• 20-30% increase in technician utilization
• Happier dispatchers with dramatically reduced manual reconciliation

How Timefold compares to other routing approaches

Timefold vs. generic mapping APIs

Mapping APIs (like Google Maps routing) can compute a single route, but they cannot:

• Assign jobs across many technicians
• Respect complex skills or SLAs
• Rebalance workloads
• Produce multi-stop, multi-day plans
• Optimize across thousands of jobs
• Re-optimize continuously during the day

Timefold is an optimization engine, not a routing API in the mapping sense.

Timefold vs. legacy FSM suites

Legacy platforms often include simplistic route planners. They typically:

• Don’t scale well past a few dozen technicians
• Rely on drag-and-drop scheduling
• Struggle with complex constraints
• Have limited customization options
• Take minutes to recalculate
• Produce low-quality schedules

Timefold gives modern FSM vendors a best-in-class optimization layer without rebuilding the math internally.

What is the ROI of Timefold's Field Service Routing API

Consider a field service operation with 1,000 technicians. If each technician spends around two hours a day traveling, a 25% improvement in routing efficiency results in roughly half an hour saved per person per day. Across the full workforce, this adds up to about 500 hours saved every day, or more than 11,000 hours each month.

That volume of recovered time is equivalent to more than 1,300 technician-days every month. At typical U.S. technician wage levels, the annual impact is close to $4 million saved, which works out to roughly $4,000 in efficiency gains per technician per year.

These numbers highlight why routing optimization has become a major competitive factor for modern FSM platforms.

Savings compound with fewer missed SLAs, less overtime, CO2 emission reductions and higher throughput.

FAQ

What’s the difference between a routing API and an optimization engine?

Routing APIs find the best path between two points.

Optimization engines like Timefold assign many jobs to many technicians while respecting constraints, then compute entire route plans.

Can Timefold handle jobs without exact street addresses?

Yes. Coordinates, fuzzy locations, polygons, and grid references are all supported with longitude and latitude data.

How long does integration take?

Most FSM teams achieve a working prototype in days, and full integration in 2–4 weeks, depending on workflow complexity.

Can Timefold handle emergency jobs?

Yes. This is a core use case, Timefold excels at intraday re-optimization.

How secure is the data?

Timefold supports secure, enterprise-grade deployment models including cloud-hosted and self-managed environments.

Next Steps: Try Timefold in your own Field Service Management platform

Timefold gives FSM vendors a high-performance, API-first routing engine that handles the toughest scheduling problems with speed and precision.

Whether you’re scaling your existing platform, adding automated dispatching, or replacing a legacy planning module, Timefold gives you the optimization backbone your customers expect.

Ready to see it in action? Request a trial.

With the recent release of Java 25, we took our usual look at its performance when running the Timefold Solver. Read on to see how the solver performs on Java 25, compared to previous Java versions.

But first, a little context.

What is Java 25 and how to get it

Java 25 is the latest feature release of the Java platform, the language Timefold Solver is built on. It includes a fresh set of enhancements, previews, incubating features, and the usual reliability improvements. Read the full overview of included Java Enhancement Proposals (JEPs) here: https://openjdk.org/projects/jdk/25/

Java 25 became generally available in September 2025, and you can install it easily through SDKMAN, which is also how we like to manage our JDKs.

Along the way, we’ve created a powerful suite of benchmarking tools to easily compare Timefold Solver versions, configurations, and Java releases. In the rest of this post, we’ll share some of our insights with you when it comes to the performance of Java 25 with Timefold Solver.

Micro-benchmarks

We’ll start with score director micro-benchmarks, which we use regularly to establish the impact of various changes on the performance of Constraint Streams. These benchmarks do not run the entire solver; rather, they focus exclusively on the score calculation part of the solver.

They are implemented using Java Microbenchmark Harness (JMH), and they run in many Java Virtual Machine (JVM) forks and with sufficient warmup. This gives us a good level of confidence in the results. In fact, the margin of error on these numbers is only ± 2%.

As with our previous benchmarks, we configured the JVM with ParallelGC as the garbage collector (GC), instead of the default G1GC. ParallelGC has been the best GC for the solver in the past, as Timefold Solver is all about throughput and not latency.

Here is the Constraint Streams performance on Java 25 vs Java 21:

In all cases but 2, the difference between JDK 25 and 21 is within the margin of error (+/- 2%) for the benchmark. What that means is that we have observed no statistically significant change in performance between the two releases with these micro-benchmarks except for 2 cases, Nurse Rostering and Travel Tournament, where Java 25 performed around 4 percent better on these benchmarks.

We couldn’t really identify exactly why it’s better yet, but we aren’t too worried when the benchmarks return a  “significantly better” result.

Real-world benchmarks

In addition to the micro-benchmarks above, we also run larger scoped applications, where we put the entire solver to work. For our benchmark, we use the median move calculation speed as our key metric.

Move calculation speed is the engine RPM of the solver. The higher it is, the faster the solver can try alternatives and converge toward a better solution. This makes it a good candidate for comparative benchmarking.

We ran the solver across 30 JVM forks. We selected a single benchmark which is a bit closer to a real application and ran it across a couple of Java versions. Once again, we used ParallelGC as the garbage collector of choice.

Here are the results:

While we haven’t established strict confidence intervals, run-to-run variance was small enough to have confidence in the observed improvements.

In this benchmark, Java 25 is almost 8% faster when compared to Java 21!

All benchmarks with these different Java versions used the same JAR file. These results clearly show that by using a newer version of Java, you not only get new features, but also increased performance. This is just one of the reasons why we love updating our pre-built models on app.timefold.ai to a newer Java version.

Appendix A: Benchmark Details

These benchmarks use Timefold Solver 1.28.0, the latest version at the time of writing.

Machine specs:

• Intel® Core™ i9-13900 (limited to 3 dedicated CPUs for consistency)
• 64GB ram available

Micro benchmarks:

• JDKs:
  • Temurin 21.0.9+10.0.LTS
  • Temurin 25.0.1+8.0.LTS
• Flags: -XX:+UseParallelGC -Xms4g -Xmx4g
• Chart data: Micro Benchmarks

Real World example:

• JDKs:
  • Zulu 25.0.1+8
  • Zulu 24.0.2+12
  • Zulu 23.0.2+7
  • Zulu 22.0.2+9
  • Zulu 21.0.9+10
  • Zulu 17.0.17+10
• Flags: -XX:+UseParallelGC -Xmx2g
• Chart data: Real World Benchmarks

Every year, my wife and I go on a short weekend getaway with some of our university friends. Our friend group has stayed together for over a decade, and in that time, everyone got married (or is still procrastinating on the wedding itself), and most of us became parents. Despite all these life changes, our yearly trip has remained a sacred tradition. And while we genuinely enjoy each other’s company and do most activities together, there’s a funny paradox: none of us would ever say, “This was the perfect weekend.”

Why? Because “perfect” means something different to everyone.

What even is an Optimized Plan?

In any enterprise, we want to get the most out of our systems, people, and processes. “Optimized” then sounds like we’re squeezing the most juice out of a lemon. But here’s the twist: not everyone likes lemon juice. In the context of our trip, no matter how much we like each other, we all need different things. I might have had a busy conference week, so all I want is a good book and a sofa, while my desk-job friend Peter might dream of a very long walk in the forest.

For companies, this dynamic is very prevalent as well. The manager might want to schedule weekend shifts to boost revenue. Employees value their time off. Meanwhile, the sustainability officer wants to minimize travel, and HR wants everyone to stay sane and productive.

Given this dynamic, we should probably put an * next to the word “optimized”. Because while it might be optimized, the real question remains: *“Optimized for what?” Ask ten stakeholders and you’ll get twelve answers. That’s why I often say the hardest part of optimization isn’t the math: it’s stakeholder management. Or, put differently: figuring out what you’re actually optimizing for in the first place.

So my definition?: “An optimized plan is the best plan to achieve *, whatever * might be”.

It’s a balancing act

In academia, optimization problems are often boiled down to one clean function: a single objective, well-defined constraints, a clear answer. On the outside, it’s quite a bit more chaotic (going on a holiday with 5 couples and 8+ kids is kind of chaotic).

Nobody is going to fight over the basic necessities for a plan: the hard constraints. In the context of our trip, those include beds to sleep in, ample parking space, some sort of a playground nearby and preferably bedrooms far enough away from the living room so the parents can have some fun after the kids are asleep, but close enough that the baby monitors still work.

In an enterprise, we take into account things like employee availability, contracts, delivery time windows, and many others. Nobody cares about “optimized” if these hard constraints are not met, as that would mean the schedule is infeasible.

Then we get to the other constraints, the softer things different stakeholders will disagree on. On our trip, these include things like “who is going to cook which meal?” and “what activities will we do?”

For enterprises, this is where there will be different views on “optimality”. These differences could be profit-based, focus on employee happiness, support the company's “green” ambitions, or a mixed bag of all those and other priorities.

If it’s such a balancing act between all these different constraints… then how do we keep our balance?

How to deal with this?

There are no silver bullets to deal with this, but there are a few good habits to adopt.

• Try to improve the status quo for everyone. Optimization is a team sport. If your model improves your bottom line but is much worse for the people executing it, you’ve just automated resentment. Employees might even full-on reject the optimized schedule, as your plan broke a hard constraint you didn’t account for: “acceptance by all stakeholders”. Plans that aren’t accepted are doomed to fail.
• Don’t expect stakeholders to know what they want. Most people only realize what matters after seeing a plan that ignores it. Treat feedback not as a failure, but as calibration. Give detailed information on why the plan is what it is and iterate on the weight given to each constraint. Do this often and recalibrate when the business demands require it.
• Build for adaptability. The “optimized” plan today might be obsolete tomorrow. Markets shift, regulations change, people leave, and new priorities emerge. Being able to adapt quickly isn’t just a nice-to-have, it’s essential.

“Optimized” isn’t “Perfected”

In both business and friendship, there is no perfect plan. There are too many stakeholders for that with different concerns and priorities. There is no “one right answer”. The best we can really do is to find the trade-offs that lead to a better plan for everyone.

So the next time someone proudly announces they’ve got an “optimized plan,” don’t be distracted by the word. Ask them the only question that really matters: “Optimized for what?”

When I studied in Finland almost a decade ago, our school visited the Rolls-Royce factory in Kokkola. The entire class was buzzing! Rolls-Royce! A household name for luxury cars and price tags that make my eyes water. It was a little bit suspicious though. How come such a luxury brand had a factory in the fairly unknown village where we were studying?

The answer became clear as soon as we arrived at the very unassuming factory. As it turns out, this factory was part of the Maritime department of Rolls Royce (not even the same legal entity as the car department), which created waterjet propulsion engines, the systems that make massive ships glide across oceans. Just the engines!

We were all a bit disappointed we weren’t going to see any of the legendary cars. But the more we learned, the more appreciation I got for these engines that made even the largest ships move. A sentiment I feel at Timefold all the time.

Optimization is the engine

Whenever I talk to people about the work we do at Timefold, and the possibilities in the wider field of Optimization, I am always greeted with excitement when talking about the results.

• “Wow, you can save that much money?”
• “You mean my workforce will spend 25% less time in their cars?”
• “How many million kilogram CO2 did you save?!?”

When they hear about these gains, people want to get started immediately, integrating these technologies into their pet projects, their business and their hobbies (a friend of mine is making a optimized Karaoke Machine… planning problems sure are everywhere ;)). I share their excitement.

But then come the follow-up questions:

• “So where do I manage my employees?”
• “Do you have a full user interface for that?”
• “Can I setup special rules for my specific use case?”

To which my retort usually is:

Do you need another system to do those things? Or do you already have something?

Quite often, the companies I talk to already invested a lot in the software they already have and are quite hesitant to drag in “yet another tool”. But that’s the great thing about this part of the tech industry:

Optimization isn’t a full product. It’s an engine.

It’s not a replacement for what you have already built, it’s an upgrade. It’s a high-performant engine that turns your existing systems into something faster, cheaper and more efficient.

Then who builds the rest of the boat?

Business processes are deeply specific. A logistics platform doesn’t look like a workforce management tool. A hospital’s scheduling needs have little in common with a retail warehouse.

Even multiple companies in the same sector might looks fairly different. That’s why vendors of optimization technology rarely build full user experiences. It’s almost impossible to design one that fits every scenario.

So then who builds the other things needed to make the business tick?

Either a business has a large IT department themselves, where they build the software they require. Or they buy existing software packages for Workforce Management (WFM), Field Service or any other use case.

Quite often, these IT people have all the knowhow they need to integrate optimization into an existing system. They know:

• Where the planning data lives: in CRMs, ERPs, spreadsheets, or the classic homegrown system that’s somehow still running after fifteen years.
• How to access it: through APIs, connectors, or custom integrations that already speak the organization’s language.
• How it should look: polished interfaces, dashboards, and workflows that make sense for their industry and users.

It is up to us, optimization experts and companies, to make integrating that engine as easy as possible.

We don’t build the ship, we make It fly across the water

I remember walking into that Rolls-Royce factory excited, but puzzled. “How can a company survive by building only engines?”

Now I get it. That’s exactly what we do with planning optimization.

We build what pushes businesses forward, even if no one ever sees it. Like those engines in Kokkola, our work lives mostly below the surface… it makes what people build around it move faster and more efficient than ever before.

Engines don’t cross oceans, they power the things that do.

A few weekends ago, during the summer holiday, my wife and I had a little romantic getaway in Amsterdam. As hotels were a bit pricey in the city center, we decided to take a hotel in the harbor instead. On our walk back to the hotel one evening, I saw a container ship float by and I had one of my moments of childlike curiosity: “How did we end up using containers for shipping?”

As it turns out… “optimization” is a big part of the answer to that question.

Old days of shipping

Before shipping containers became a thing, shipping looked a lot different. Every item was shipped separately and stored on deck or in the cargo hold. While sometimes kegs or crates were used to keep items together, there was no single uniform shape.

In those days, there were also *optimization experts* called “stevedores”. Stevedores were responsible for loading and unloading cargo from boats. This wasn’t just a very physically intense job, but also one which required good insights into how to load the boat as efficiently as possible.

In essence, stevedores were solving giant 3D jigsaw puzzles to fill the boat to the max, except in this case, the puzzle pieces were all odd shapes, and the boat might capsize if they fail to balance the weight correctly.

Parents who go with their young children on a holiday know exactly what that puzzle game feels like. Minus the capsizing of course! 😊

Not only was this a difficult and dangerous job, it was also very slow. Every item had to be loaded and unloaded individually which sometimes caused them to spend more time docked than actually traveling at sea. It wasn’t much better for the rest of the logistics either, as the same inefficiencies were also present when transporting the goods by train or truck.

Despite all that, it felt “optimized” at that time, there just seemed to be no better way to transport items across the world. Especially not by adding big square boxes to the mix! That seemed like an awful idea. A square metal box couldn’t possibly compare to the artistry of a skilled stevedore who could wedge a piano next to a barrel of whiskey and three sacks of potatoes! Or could it?

Containers and throughput

What initially looked like inefficiency turned out to be revolutionary. After some early examples of containers failing to gain widespread adoption, Malcolm McLean, a US trucking entrepreneur dubbed the ‘father of containers’, came up with a prototype container in the 1950s which could be used across boats, trains, and trucks.

While the idea sounds simple, its innovation was because of its holistic approach. Where previously the focus was on *optimizing what can be loaded on a boat*, that focus shifted to *optimizing the throughput of goods.* From the narrow view of getting better at transporting items by boat to the holistic view of *transporting items as best as possible from origin to destination.*

At least initially, containers mainly reduced the transfer time between modes of transport. It wasn’t until some time later that those modes of transport began optimizing for transporting as many containers as they could in a single go, making transporting goods faster than ever before.

Optimization lessons contained in containers

The history of containers holds a simple truth about optimization: you rarely fix everything at once. In shipping, containers didn’t eliminate the stevedore’s Tetris problem, they just shrank it. Instead of balancing pianos with whiskey barrels and potato sacks on a whole ship, the challenge became fitting goods neatly into a 40-foot steel rectangle. Similar puzzle, smaller board.

And that was enough to change the world. By zooming out from “how do we cram more onto a single boat?” to “how do we move goods from origin to destination faster?”, containers unlocked opportunities across the entire supply chain.

The same applies today. You may not be able to optimize every process in your organization at once. But even tackling a small segment, a schedule, a route, a workflow, can free up time and resources that ripple outward in unexpected ways.

In the end, real innovation happens when we stop obsessing over micro-efficiencies and allow human ingenuity to focus on the bigger picture. Optimization isn’t about doing the same thing better, it’s about creating space for us to ask better questions.

I live about 2km away from “De Schorre” in Boom (Belgium), or as most people probably know it: the location where the Tomorrowland festival is hosted. It is genuinely one of the most beautiful festivals I’ve ever been to, and I remember thinking: “Wow, pulling all of this off must require a lot of planning”.

If there is something I love doing, it’s looking at these kinds of “close to home” (literally in this case!) planning problems and trying to figure out how I would model them. From the stage-builders, to the stewards and of course the artists and stages, everything needs a plan, a schedule to make it all work together like a symphony.

Stage and artist schedule planning

Modeling time! I don’t know a lot about organizing a festival or music concerts, so I limited my scope to just assigning artists to stages. These are a few of the constraints I came up with.

I thought this was pretty good already. I could build the model and ship it! That is, until I talked to a friend who knows a couple things about planning festivals and he made it very clear I was missing a few essential elements.

All of these make a lot of sense and I completely missed them! This is something I see a lot at Timefold. Whenever I speak to human planners, especially when it’s not a use case we’ve explored with our pre-built models, I often come back with some new or unexpected constraints.

This brings up an important point: You can’t build a good model without input and validation by the real heroes, the human planning experts. Essentially, modeling is embedding the expertise and know-how of human experts and making it scale beyond the planners own capacity.

When we create a new model, does that mean we can just talk to a human planner, “capture” their knowledge, and then produce a fully working planning system which can live without human interaction?

Balancing modeling vs human intuition

No matter how long you spend creating the ultimate model, even after talking to thousands of human experts, there will always be times when you hear the expression, “This plan doesn’t feel right.”

Quite often this means we are missing some hidden intangible constraint, perhaps something the human planner themselves can’t really put to words because it comes from a place of intuition and experience. This is a common yet tricky situation: either we figure out what’s missing, or the planner will get stuck with this feeling… and feelings are a powerful thing.

In the case of planning events (or festivals), I have heard the expression, “This doesn’t vibe well”. I have not yet figured out how to create the constraint to optimize for “vibes”.

However, while I believe feelings are always valid, they aren’t always rational. In planning, a schedule that feels better might actually be much worse if you look at it through the emotionless lens of the mathematical scoring function. Giving that young DJ a chance on a bigger stage, or putting 2 high intensity acts back-to-back might feel better but it could negatively affect the raw “score” of your schedule.

The real best solution, the golden path, is probably somewhere in between mathematically perfect and emotionally excellent. So even after using computers to optimize a plan, human planners improve the schedule further by embedding some empathy, emotion, and nuance into the schedule.

And that’s without the chaos of reality

People who have watched the news lately know where this is going. 2 days before opening the main stage at Tomorrowland, a real piece of art people work years to produce, burned down in a couple of hours. A real drama and any carefully crafted symphonic plan… well… not usable anymore.

Eventually, this happens to every plan, just to varying degrees. Whenever a plan meets reality, it’s almost never a 100% fit… and if it is, it doesn’t stay like that for long. Employees get sick. Delivery vehicles break down. Systems crash. Budgets get slashed.

The real challenge is not to plan, but to adapt when life throws a wrench into your schedule.

The Tomorrowland team quickly came up with 2 alternative solutions, but 1 of them sparked my interest the most. They had a stage at the camping ground and they could label that one “the main stage” and carry on. The problem is, the camping ground is pretty far away from the actual festival ground. The festival would essentially be split: main grounds and camping.

So what would have happened if I’d run it through my optimization algorithm? It would have probably moved some of the main stage artists to the festival ground due to the “artist minimal audience space” constraint. Without anything to avoid making too many changes (like an anti-disruption constraint) that would have been the mathematically more optimal solution.

Instead what they wanted to do was much more empathic: since the people on the camping ground would only have 1 stage, they would get all the main stage artists, aka most big names. From a planning perspective, it’s also easier as the schedule remains essentially the same. It just feels like a much better solution.

In the end, they didn’t even have to go for this solution as, due to acts that can only be described as “heroic”, they managed to clean up and build a new main stage with only a couple of hours delay.

Planning is human

Planning isn’t just about satisfying constraints or optimizing for the perfect score. It’s about translating human values, intuition, and adaptability into something machines can assist with but will probably never fully replace.

It’s clear that behind every great plan is a human making judgment calls that no algorithm can foresee. At its best, planning technology doesn’t replace the human expert, it amplifies them. It allows them to see and act on solutions they might not have seen on their own and gives them the freedom to shape those possibilities with empathy and insight.

So yes, let’s model, optimize, and automate where we can, but let’s never forget: planning is, and always will be, profoundly human.