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.

Real-time route optimizationRecompute routes instantlyInsert an emergency job and recompute schedules and routes in secondsFeatureAdvantageValueSkill-based assignmentEnsure only qualified techs are scheduledElectrician-only jobs auto-assigned based on certificationsSLA-aware schedulingMeet customer time windows“Arrive between 10–12am” constraints respectedMulti-day planningPlan tomorrow + next weekWeekly job allocation to recurring customersIntraday re-optimizationRespond to disruptionsRe-schedule what needs rescheduling at the click of a buttonGeographic clusteringMinimize long-distance travelTechs stay within assigned service zonesHigh-scale optimizationHandle large fleets & workloads500,000+ jobs and 100,000+ technicians

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.

Intro

Whether you’re building a scheduling solution for employee rosters, field services, or machines, it should be visually intuitive and smart enough to handle constraints, preferences, and changes. Don't settle for building another simple planning tool when you can implement a system that optimizes plans, does more with the same resources, and adapts to shifting scenarios.

This is exactly what we help you achieve with our Timefold x Bryntum partnership.

Timefold is an AI-driven constraint solver for scheduling, shift planning, and routing. Bryntum Scheduler is a high-performance, drag-and-drop timeline UI component that renders interactive schedules. Together, they allow you to build optimized and attractive planners.

How it works: A technical overview

Timefold and Bryntum are both modular and technology-agnostic. You can plug them into any system architecture with minimal friction, whether it's a monolithic, microservices, or hybrid setup.

Timefold

Timefold provides REST APIs that solve complex planning problems such as shift and job scheduling, enabling developers to offload constraint-heavy logic to a dedicated optimization engine. Once a scheduling request is submitted, Timefold returns an optimized solution in JSON format, making it easy to integrate with any system.

Bryntum Scheduler

Bryntum Scheduler is a powerful UI component for intuitive task and resource management.

Fully framework-agnostic, Bryntum Scheduler slots easily into any frontend stack (React, Angular, Vue, or plain JavaScript), allowing developers to build responsive, user-friendly scheduling interfaces with minimal effort.

Integration flow

Your backend system serves as the single source of truth, so that you retain full ownership and control of your scheduler. Timefold and Bryntum are powerful tools for visualization and optimization, but they are not intended to function as data stores. Supplying Timefold and Bryntum with the necessary scheduling data from your own system ensures consistency, prevents duplication, and simplifies data management.

Display data in the Bryntum Scheduler

To display a schedule to your users, the necessary data must be available in your browser.

Bryntum components support various data-loading strategies. You can use the Crud Manager or load data directly into a specific store via a URL. The Crud Manager is especially handy for loading and saving data to and from your backend. You can also integrate WebSocket connections to enable real-time data exchanges between Bryntum components and your source-of-truth system.

Bryntum manages your data using stores, which are reactive, in-memory data repositories that:

• Load and hold scheduling data (in the form of tasks, resources, and assignments)
• Support sorting, filtering, syncing, and all CRUD operations
• Bind automatically to the UI, so that any changes to the stores are instantly reflected in the interface

Note: These stores are not related to the browser's local storage. Any unsaved or unsynchronized data will be lost when the browser is closed.

The data loaded by Bryntum Scheduler doesn’t need to be a complete plan. You can add unplanned events to the UI, so users can plan them manually with Bryntum's drag-and-drop functionality.

Optimize plans with the Timefold APIs

Available as JSON REST APIs, Timefold’s optimization models do the hard planning work for you. No matter the optimization model you use (employee shift scheduling, vehicle routing, or job scheduling), all Timefold APIs follow a similar integration pattern:

1. Gather all relevant planning data: The data you need depends on your chosen optimization model and the constraints you want to enable. Timefold’s APIs only enable certain constraints if you provide the relevant data. The more data points you provide, the more constraints will be active. For example, when scheduling employees, employee costs are only taken into account when you provide the costGroup of the employees.
2. Send that data to the Timefold API to start an optimization run: The Timefold Platform then optimizes the schedule so that it complies with all activated constraints, such as employee availability and skill matching.
3. Monitor the progress of the optimization run by calling the Timefold API to retrieve its status: A single run can take anything from a few seconds to several hours, depending on the scale of the planning problem. The Timefold API always returns the current best solution found so far, along with the current status of the run.

You can implement long polling to continuously fetch updates until the optimization is complete. Alternatively, you can configure a webhook that is triggered when the optimization run finishes.

Customize your integration

Timefold and Bryntum complement each other perfectly, and you can choose how far you want to integrate with either of them. Consider a basic example of backend integration:

• A user clicks Optimize in the Bryntum Scheduler UI.
• The backend collects relevant scheduling data (such as tasks, resources, or constraints), which it then sends to Timefold.
• Timefold processes the input and returns an optimized schedule.
• The backend stores the result and updates the Bryntum Scheduler with the new data.
• The user reviews the updated schedule in Bryntum, then manually adjusts the plan and persists their changes as needed.

Users also benefit from the following optional features:

• Manual edits and score analyses: Use Timefold’s scoring API to analyze the impact of manual changes made in the Bryntum UI.

• AI-assisted recommendations: Let Timefold suggest the best match for a task, rather than leaving it up to manual guesswork.

Alternative: Frontend-only integration

An alternative approach is to call Timefold directly from the Bryntum UI. While this may at first seem easier for existing Bryntum users, it comes with some major downsides:

• The UI needs to gather all the data for the Timefold API, which is not always feasible. Sometimes, the dataset is too large to load in one go, or the data required for planning is not exposed to the frontend.
• Optimizations for large-scale planning problems can run for multiple minutes or even hours. Because your users won't be looking at the Bryntum UI for all that time, you need somewhere to store the component state.
• You would still require a proxy to check your application authorization and to hide the Timefold API keys from your end users.

Note: Frontend-only integration may be okay for demos or prototyping, but it is insufficient for robust systems.

Why trust matters

I love being a dad. It’s really amazing to see this little human learn and explore every day with that child-like curiosity. Kids are so full of “why” questions.

• "Why don’t fish drown?”
• “Why can’t I play on my video game console today?"
• “Why can’t I have ice cream for breakfast if it's made from milk?”

Sometimes we take our time to answer. Other times when parents are stressed, juggling four others things at the same time or are just plain tired, they sometimes whip out the universal catch-all answer: “Because I said so!”.

I don’t like that answer. It’s a shortcut. It ends the conversation. Worst of all, it shuts down curiosity and that is something we can’t afford to lose, especially in this age of ever-more complex systems. Yet, this is also what a lot of scheduling software does.

An algorithm spits out a schedule and the experts, human planners are left with questions:

• Why did Alina get her preferred shift but Myey didn’t?
• Why not fix Thomas’ electricity problem first before moving into the city for the other assignments?
• Why assign Pieter when Maarten lives closer?

When the only answer to those questions is “because the algorithm said so”, planners will not trust the solution. And without trust, they’ll toss the plans aside and will stick to the techniques they have been using before. Our solutions do not just need to find the best schedules… they need to be able to explain them as well.

From explainability to trust

If we want people to accept the output of our planning systems we should give them a system worthy of their trust. A big part in building a trustworthy system is being able to answer the questions mentioned above. It helps you move from blind trust to informed confidence.

In our experience building Timefold, explainability leads to 3 major benefits:

1. Clarity

Giving planners answers to all their “why” brings clarity. They are able to understand why the schedule is what it is. They gain deep insights and are not forced to blindly accept a plan.

With our Timefold solutions, we track constraint violations, how much they affect the outcome, and which decisions caused them. This transparency helps planners understand the trade-offs. At a higher level we also transform these constraints into clear-cut KPIs, making it easier to reason about them.

2. Error backtracking

If something breaks in the real world, you need to know why. In optimization systems which operate like black boxes, it can be hard to figure out exactly where things went wrong.

We have captured this in our Score Analysis functionality which allows you to analyze any schedule, even when it’s not been created by Timefold. This gives planners a powerful tool to diagnose issues and avoid future errors.

3. Insightful adjustments

Planners often make tweaks based on gut instinct. They want to make changes and see the impact of those changes on the schedule.

Next to the Score Analysis mentioned above, Timefold allows you to compare two plans. If new work needs to be assigned to a resource Timefold’s Recommendations assist the planners in making an informed choice.

4. Strategic insights

Explainability in planning systems benefits more than just end users. For decision-makers, they reveal actionable patterns that support strategic decision-making at the executive level.

We're building features in our platform that display operational imbalances and indicate room for improvement.

Clarity, Error Backtracking, Insightful adjustments, and Strategic insights all sprout from the core concept of explainability, and contribute to the trustworthiness of a system. Planners stop overriding schedules, collaborate with the planning tool and are able to solve larger problems with ease, while leaders can use the planning for better decision-making.

In short, they stop seeing PlanningAI as a threat and start seeing it as a planning partner.

Don’t let "Because I said so" kill your plans

We wouldn’t accept that answer from a parent. We shouldn’t expect people to accept it from a planning engine either. In fact, taking a moment to focus on explainability is just as important as finding the “best” possible schedule. A great schedule isn’t just optimal, it’s understandable.

So next time someone asks, “Why this schedule?”, make sure your system can answer with something better than “Because the algorithm said so?!?”.