What actually happens when a route plan is built?
Route planning looks simple from the outside. This article explains the decisions happening between input and output — how assignment decisions are made, what “optimal” actually means in practice, why constraints make planning harder, and what dropped jobs are telling you.
7 min read
Route planning looks simple from the outside. You put jobs and vehicles in, routes come out. But the decisions being made between those two steps — whether by a person or a planning tool — are more layered than they appear.
Understanding that process doesn't require technical knowledge. But it does help explain why your plans look the way they do, why certain jobs get dropped, and why small changes in data can produce unexpectedly different results.
The inputs that shape every decision
Every planning decision is made in the context of what needs to be done and what's available to do it.
On the task side: each job has a location, a duration, capacity requirements, and usually some time constraints. On the resource side: each vehicle or driver has a starting point, an availability window, a capacity limit, and often restrictions on the types of work they can handle.
Travel connects them. The time and distance between locations isn't just a logistics detail — it has a compounding effect across the entire plan. A route that works with 25-minute average travel times can break down when that average becomes 35 minutes. Small inaccuracies in inputs ripple through the whole plan. This is why data quality matters more than most people expect.
How assignment decisions are actually made
When a planning system — or an experienced planner — assigns a job to a route, they're making a trade-off: does adding this job keep the route achievable? Is there a better option that creates less overall disruption? If two routes could accommodate this job, which one produces better outcomes overall?
These aren't simple calculations. With even a modest operation, the number of possible arrangements is enormous. Planning tools work through these combinations much faster than a human can, but they're making the same kind of trade-offs: completing more work, minimizing travel, protecting time commitments.
An important thing to understand: not every task will make it into the final plan. When a job is dropped or unassigned, that's not a failure — it's a signal. It usually means the task is too constrained relative to what's available, or that including it would significantly disrupt everything around it. Which jobs get dropped, and why, is often more informative than looking only at what made it in.
Why constraints make planning harder, not just more strict
Every constraint you add reduces the number of valid solutions. That's the point: to enforce a rule that matters operationally.
But constraints interact with each other in ways that aren't always obvious. A time window that's slightly too tight, combined with a skill requirement that limits vehicle options, combined with a cluster of nearby jobs — can produce a plan that's unexpectedly fragmented, or that drops a job you expected to be assigned.
This is why reviewing your constraints is as important as reviewing your data. Constraints that are stricter than necessary — added as a precaution rather than based on a real requirement — reduce planning flexibility without providing operational benefit. Over time, they make plans harder to build and harder to trust.
What 'optimal' actually means
A common assumption is that planning tools produce the 'optimal' plan — the single best solution. In practice, 'optimal' depends on what you're optimizing for.
Minimizing distance? Minimizing overtime? Maximizing job completion rate? Protecting specific time commitments? These objectives often pull in different directions, and the best plan depends on which trade-offs matter most to your business.
Understanding what your planning process is prioritizing — and whether that matches your actual operational priorities — is one of the most useful things you can examine when plans don't behave as expected.
| What this means in practice: |
|---|
| Data accuracy has a compounding effect — small input errors create larger plan distortions than expected |
| Dropped or unassigned jobs are diagnostic signals — understand why they're being excluded |
| Every constraint reduces flexibility — each rule should earn its place in the planning logic |
| What's being 'optimized' matters — plans reflect their objectives, not just the data |
| Plan complexity grows with volume and constraint count — this is expected, not a sign something is broken |
You don't need to understand the mathematics to improve your planning. But understanding that the plan is a direct reflection of your inputs — data, constraints, and priorities — puts you in a much better position to diagnose why plans look the way they do, and what to change when they don't.