Designing better routing plans with (just enough) traffic awareness

Introduction

If you’re building routing software, you’ve probably heard a version of this request:

"Can we just pull in real-time traffic and make the routing smarter?"

It sounds simple, after all tools like Google Maps do it every day. But when you zoom out from one driver and one route to a team of dozens or hundreds, traffic data gets a lot messier. It’s not just a layer on the map, it touches everything from feasibility checks to full-blown reoptimization.

In this document, we’ll walk through the different kinds of traffic data, where they help (and where they don’t), and how you can build smarter routing features without breaking the bank, or your product roadmap.

The types of routing and traffic data that matter

Let’s start with what we’re actually talking about when we say “routing data” and “traffic data”:

  • (Static) routing data

    • Vehicle-specific data: Things like height, weight, maximum turning radius. Essential for truck-aware routing.

    • Static road data: Road types, speed limits, toll zones, legal restrictions, hazmat restrictions, planned road closures.

    • Route behavior parameter: Rules like “approach from curb side” or “depart in the same direction.”

  • (Dynamic) traffic data

    • Historical traffic patterns: Typical speeds for each road segment by time of day.

    • Live traffic information: Jams, incidents, unexpected road closures (the real-time stuff).

Some of these are fixed, and some can significantly change by the minute. That’s where the complexity starts.

Where does traffic data actually help?

Not every product needs to use traffic data in the same way. Here’s a spectrum of where it can make an impact:

  • Display only: When you show traffic information on a route map. This helps field workers prepare.

  • Recalculate: When you use traffic information to re-route a previously planned route. This helps field workers in mobile apps and during navigation.

  • For feasibility checks: When you use traffic information to monitor and validate if a previously planned schedule is doable. This helps make sure the plan will honor SLA requirements and employee contract regulations.

  • For optimization: When you assign work based on traffic patterns. This helps to optimize route plans.

The first two are common in end-user apps, when doing point-to-point routing, the last two is when traffic information helps decide the other of work and where the backend gets serious, and where many underestimate the cost and complexity.

Not all routing APIs handle traffic equally

You may work with APIs that abstract away a lot of the routing logic. Here’s a high-level guide:

API type Common use Traffic handling Complexity

Routing APIs (A→B→C)

Turn-by-turn, ETA checks

Uses real-time or predicted traffic at query time

🟡 Medium (limited region)

Distance Matrix APIs

Input to TSP/VRP solvers

Uses typical traffic for a single point in time

🟡 Medium (limited time window)

Traveling Salesman Problem (TSP) APIs

Optimize one person’s route

Needs time-aware traffic per time window of each stop

🟠 Hard, but often modeling a smaller amount of stops

Field Service Routing (FSR) APIs (like Timefold)

Plan & assign work across teams

Must model traffic per vehicle profile, per route, over time

🔴 Very hard

So while a Routing API might give you fast ETAs for a technician’s mobile app, it won’t help you decide who should do which jobs, or when, that’s a much more dynamic problem.

Why real traffic modeling breaks at scale

Here’s a real-world example. One of our customers plans 1,000+ visits across five days, using 100 technicians across multiple U.S. states. To fully model time-dependent traffic for this:

  • You’d need historical traffic for the multiple timespans of a day (e.g. every 5 minutes - or 288 traffic profiles per day).

  • For weekdays versus weekends and public holidays.

  • For the different types of vehicles they have (e.g. small and medium vans, and large trucks).

  • Across the entire United States (i.e. 10 GB graph data).

The graph data needed for this alone adds up to 17+ terabytes. That’s not just expensive, it’s operationally infeasible.

How the best providers handle it

Even the biggest names in routing (like Google, TomTom, HERE) apply optimizations:

  • Use a static traffic snapshot, not dynamic modeling.

  • Limit traffic-aware solving to small plans (e.g. 12 stops).

  • Support only one vehicle type per optimization run.

  • Keep planning windows to a single day.

  • Charge extra for traffic data, per-region or pay-per-use.

  • Let users bring their own distance matrices.

  • Use heuristics or caching to simulate traffic impact.

Often providers use a combination of these techniques.

In short: nobody does “perfect” traffic-aware optimization at scale. Everyone is trading off between accuracy, performance, and cost.

How Timefold helps today

Even with a perfect traffic forecast, things can still go wrong:

  • A technician is delayed at a job.

  • A road gets closed.

  • A thunderstorm rolls in.

  • There is an unusual traffic jam.

The best route isn’t just the one with the shortest drive time. It’s the one that additionally leaves room for things to go wrong, and has the tools to adapt and replan.

Don’t plan too tightly, plan for change

At Timefold, we’ve built features that help planners control how “tight” the routing should be:

  • Travel time multiplier: Add, for example, 20% to all durations to simulate everyday delays.

  • Fixed offsets: Add, for example, 5 - 10 minutes to each leg for predictable issues like parking or loading.

These small buffers make a big difference. They help avoid brittle schedules that fall apart at the first delay. For several use cases they might even eliminate the need for complex and costly real-time traffic data.

Real-time replanning

When the unexpected hits, our real-time replanning and recommendation engines help you move fast.

  • Reassign jobs when a technician becomes unavailable.

  • Slot in emergency jobs at the recommended time windows with minimal disruption.

  • Replan routes mid-day, preserving as much of the original schedule as possible.

This lets planners react confidently, without having to start from scratch.

Bring your own distance matrix

For self-hosted installations of the Timefold Platform, we support custom distance matrices. That means you can:

  • Use the same travel times shown in your end-user app.

  • Integrate traffic data from your preferred provider.

  • Align routing behavior with your display and UX expectations.

  • Use the Timefold Platform for non-road travel use cases (like order picking travel time in a warehouse or ship travel time on oceans).

It’s a powerful way to close the gap between planning logic and what your technicians actually see on the road.

What’s next?

We’re working on making our Maps service traffic-aware. Our implementation plan will roll out in stages:

  • Traffic snapshot selection: Make it possible for users to specify a timestamp for the traffic data snapshot used during route optimization.

  • Busy period configuration: Make it possible for users to define specific regions and timespans as “busy” (e.g. weekdays from 3 PM to 6 PM) to improve the accuracy of travel time estimates.

Additionally, we’re also working on rolling out optimization for multiple vehicle profiles. Our implementation plan will roll out in stages:

  • Non-mixed: giving you the option to solve routing problems for trucks, vans, or cars separately.

  • Mixed: where you can solve routing problems for a hybrid fleet of trucks, vans, and other vehicles.

In parallel, we’re also exploring ways to reduce the size and complexity of distance matrices which is a critical factor when working with traffic-aware routing at scale. For example, if you’re planning field service routes across the United States, it’s technically possible to compute travel times between every pair of jobs. But in reality, no technician is going to drive from New York to California in a single day.

That’s where maximum vicinity radiuses come in. By focusing only on route segments that fall within a realistic travel range, we can dramatically reduce both computational load and data costs, without compromising plan quality.

If you’re interested in traffic-aware optimization or want to be part of early access testing, please get in touch, we’d love to hear from you.

Conclusion

If you’re building routing software, ask yourself:

  • Do we need display-only traffic, or true traffic-aware planning?

  • Will our product benefit more from resilience, or from precision?

  • Can we afford to model traffic dynamically, or are heuristics and buffers a better fit?

  • How are the optimized routes presented to end-users, and is there still flexibility at that point?

At Timefold, we built our Field Service Routing API to support large-scale, real-world planning - with and without traffic data. We support dynamic replanning, constraints like visit dependencies and multi-vehicle visits, and we make it easy to adjust your tolerance for uncertainty.

Because in the end, your users don’t need perfect routes. They need plans that hold up in the real world.