General
How to Choose a Route Planner: Match the Tool to Your Binding Constraint in 2026
Choosing a route planner means identifying which constraint actually binds your operation, matching that to a class of tool, and only then comparing vendors inside that class. Most selection processes run in the opposite order and segment by fleet size or stops per route, which is the wrong axis: in our modeling, an operation with 15 stops and two-hour delivery windows needs more capable software than one with 60 stops and all-day windows. Locus, the world’s first Decision-Intelligent, Agentic TMS, plans against more than 250 real-world operating constraints, which matters only if your operation actually has constraints that bind.
Key Takeaways
- The variable that determines which class of route planner you need is constraint tightness, not fleet size or stop count. Simple sequencing tools and constraint-aware optimizers fail in different places.
- In our illustrative model, distance-first sequencing served 98% of stops inside their windows at six-hour windows and 57% at four-hour windows. The capability threshold sits between those two.
- Below that threshold a simple route planner is the correct answer, not a compromise. Buying constraint depth you do not need is a cost with no return.
- Stop count moves the answer far less than window width. At two-hour windows, distance-first sequencing served 41% of stops at 15 stops per route and 20% at 40.
- Locus sits in the third class, built for operations where multiple constraints bind at once and plans have to be recomputed during the day rather than fixed each morning.
Why Choosing by Fleet Size Gets This Wrong
Almost every route planner comparison segments by scale. Tools are grouped into small business, mid-market and enterprise, and the sorting variables are stops per route, drivers supported and vehicles under management. Those numbers are easy to publish and easy to shop against, which is why they became the convention.
They are also close to irrelevant to whether a tool will work for you. A route planner’s job is to produce a sequence that satisfies your constraints. If your only constraint is visiting every stop once and getting home, that problem is well solved by inexpensive software regardless of whether you have twelve stops or two hundred. If your stops carry two-hour appointment windows, vehicles differ in capacity, drivers hold different skills and half the orders arrive after the plan is built, you have a structurally harder problem at any size.
The stakes justify getting the match right rather than defaulting up or down. McKinsey’s out-of-home delivery work puts the last mile at 60% to 70% of total parcel delivery cost, and ATRI’s 2026 operational cost report put marginal operating cost at $2.336 per mile in 2025, so a plan that adds miles is expensive in a way that compounds daily. Conditions are also drifting: INRIX’s 2025 Global Traffic Scorecard found congestion increased in 254 of the 290 US cities it analyzed, which erodes the slack that used to absorb an imperfect plan.
One more variable belongs in the profile and rarely appears in these comparisons. AlixPartners’ 2026 Home Delivery Survey found more than 90% of executives run a mix of last-mile carriers and 32% use four or more. An operation routing across owned vehicles and contracted capacity is not solving a harder sequencing problem, it is solving a different one, because some of the capacity is not yours to sequence. That changes which class of tool applies regardless of how many stops you run.
The Threshold: When Simple Sequencing Stops Working
The clearest way to locate yourself is to ask what happens to a distance-optimized sequence once time windows exist. A simple route planner solves for a short tour and treats windows as information printed on the manifest. A constraint-aware optimizer treats windows as conditions the sequence must satisfy.
We modeled the difference. The inputs are illustrative rather than measured: 40 stops in a compact urban area, an eight-hour shift, 25 km/h effective speed, five minutes per stop, and time windows of varying width placed randomly through the day. The measure is the share of stops served inside their window.
| Time window width | Distance-first sequencing | Window-aware optimization | Gap |
|---|---|---|---|
| 8 hours, effectively all day | 100.0% | 100.0% | 0 pts |
| 6 hours | 98.2% | 100.0% | 2 pts |
| 4 hours | 57.1% | 97.8% | 41 pts |
| 3 hours | 33.4% | 96.1% | 63 pts |
| 2 hours | 19.1% | 93.6% | 74 pts |
The shape is what matters. Distance-first sequencing is not slightly worse across the range and it is not uniformly bad. It is indistinguishable from a full optimizer at wide windows and then collapses between six hours and four. That collapse is the line dividing two classes of tool, and it can be located without a vendor’s help: it is set by your own window policy.
Stop count moves the answer much less than window width does, which is the finding that most directly contradicts how these tools are sold.
| Stops per route, 2-hour windows | Distance-first sequencing | Window-aware optimization |
|---|---|---|
| 15 | 41.2% | 100.0% |
| 25 | 28.6% | 99.6% |
| 40 | 20.2% | 93.3% |
| 60 | 13.2% | 78.4% |
A fifteen-stop operation promising two-hour windows is served badly by a simple planner. A sixty-stop operation promising next-day delivery with no window is served well by one. Segment by scale and you will send both to the wrong shelf.
The Three Classes of Route Planner
| Class 1: sequencing tools | Class 2: constraint-aware optimizers | Class 3: decisioning platforms | |
|---|---|---|---|
| Core problem solved | Shortest practical tour across known stops | Feasible plan satisfying multiple hard constraints | Continuous planning against changing conditions |
| Handles time windows | As information, checked by the driver | As hard constraints in the optimization | As constraints, revised during execution |
| Vehicle and driver rules | Usually uniform vehicles | Capacity, skills, shifts, breaks, territories | The same, plus live availability |
| Replanning | Plan is rebuilt manually | Plan is rebuilt on demand | Plan is recomputed continuously |
| Typical cost profile | Lowest | Moderate | Highest |
| Right answer when | Windows are wide or absent, one depot, similar vehicles | Two or more constraint types bind at once | Constraints bind and the day changes after dispatch |
The important discipline is refusing to treat this as a maturity ladder. Class 1 is not a stepping stone to Class 3. It is the correct answer for a large number of real operations, and buying past your constraint profile means paying for optimization that has nothing to optimize against, plus an implementation your team has to absorb.
A Six-Step Procedure for Choosing
1. Write down your binding constraint before you look at any product
List every condition a plan must satisfy: time windows and their width, vehicle capacity and type, driver shifts, breaks and skills, territory rules, access restrictions, and any service-level commitment. Then mark which ones actually cause a plan to be rejected today. Most operations discover two or three bind and the rest are preferences.
2. Locate yourself against the window threshold
Take your tightest commonly promised window and read it against the table above. Above roughly six hours, sequencing quality is the whole problem and Class 1 is sufficient. Below roughly four, sequencing without constraint handling will fail in a way no amount of tuning fixes.
3. Count how many constraint types bind simultaneously
One binding constraint is usually manageable inside a simpler tool with manual adjustment. Two or more interacting constraints, such as windows plus mixed vehicle capacity, produce a problem where satisfying one breaks another, and that interaction is what Class 2 optimizers exist to resolve.
4. Measure how often the plan changes after it is published
Count the share of orders that arrive or change after the plan is built, and how often a vehicle or driver becomes unavailable mid-shift. Below roughly one in twenty, planning once a day and adjusting by hand is defensible. Materially above that, the operation is being run by the adjustments rather than the plan, which is the Class 3 case.
5. Establish where the plan has to go next
A plan that exits as a PDF or a driver app is a different integration problem from one that must return to an order management system, feed customer communications, or become a binding constraint on a checkout promise. This determines integration requirements independently of optimization quality, and it is where most implementations actually run long.
6. Only now compare vendors, and only inside one class
With the profile written down, most of the market disqualifies itself and the shortlist is usually three or four products rather than twelve. Comparisons across classes are not informative, because a Class 1 tool losing to a Class 3 platform on constraint depth tells you nothing you did not already know. Keep the profile in front of you during demonstrations: every product in this category will show a capability you do not need, and the profile is what makes it easy to say so without feeling like you are missing something.
The Procedure Applied to Three Operations
Running the six steps takes an afternoon. Here is what it produces for three operations that would be grouped very differently by a conventional comparison.
| Regional courier | Appliance retailer | Grocery and quick commerce | |
|---|---|---|---|
| Stops per route | 90 | 12 | 35 |
| Tightest promised window | Next day, no window | 3 hours | 1 hour |
| Constraint types that bind | One: shift length | Three: window, two-person crew, vehicle type | Four: window, capacity, temperature, driver shift |
| Orders changing after plan | Under 5% | Around 10% | Over 30% |
| Plan destination | Driver app | Driver app and customer messaging | Checkout promise, dispatch, customer messaging |
| Indicated class | Class 1 | Class 2 | Class 3 |
The courier has the largest fleet and the simplest problem, and buying a decisioning platform would give it optimization with nothing to optimize against. The appliance retailer has the smallest routes and a genuinely hard problem, because three constraints interact and satisfying one can break another. The grocery operation needs continuous replanning not because of its size but because most of its day arrives after the plan does.
Sorted by stops per route, that table reads in exactly the wrong order.
The Cost of Getting the Match Wrong Is Asymmetric
The two errors do not cost the same, which should influence how you resolve a genuinely borderline case.
Buying below your constraint profile produces daily operational cost that hides inside normal work. Planners adjust the output by hand, drivers resequence in the field, and the tool keeps reporting good distance numbers because it optimized the thing it could see. The failure is quiet, it grows as windows tighten, and it is usually attributed to execution rather than to the plan.
Buying above your profile produces a visible, one-time cost: license spend, a longer implementation, and configuration effort for constraints you never use. It is more embarrassing and easier to measure, which is why buyers fear it more, but it does not compound.
The practical consequence is that a borderline case should resolve toward the more capable class only when the trajectory supports it, meaning windows you expect to tighten, constraints you expect to add, or churn you expect to rise. Absent that trajectory, the simpler tool is the better commercial decision and the easier one to replace later.
What to Test Before You Buy
Run the trial on your hardest day, not a representative one. Take a historical day with peak volume, the tightest windows you promise and whatever went wrong operationally, and ask each shortlisted vendor to plan it. Software differentiates under stress and looks identical on an average Tuesday.
Check feasibility rather than distance. A plan that is 8% shorter but violates six windows is worse than a longer plan that satisfies all of them. Ask for the count of constraint violations alongside the distance figure, and ask what the tool does when no feasible plan exists: whether it reports the infeasibility, drops stops silently, or returns a plan that quietly breaks a rule.
Test the replan path explicitly. Add three orders and remove a vehicle after the plan is built, then time how long a corrected plan takes and how much it disturbs work already in progress. A replan that reshuffles every route is technically correct and operationally unusable once drivers have started.
Ask what happens at your volume ceiling rather than your average. Optimization time grows faster than linearly with stop count, so a tool that plans 200 stops in seconds may take an unusable amount of time at 2,000.
Finally, have the vendor plan the same day twice with one input changed, and compare the two plans. A small input change producing a completely different plan is a sign the optimizer is finding one of many equally good answers rather than a stable one, which matters operationally because drivers learn their areas and planners lose trust in output that moves for no visible reason.
| Also Read: How to Choose Logistics Automation Software |
|---|
Common Mistakes When Choosing a Route Planner
Shopping by fleet size. It is the most available number and one of the least predictive. Constraint tightness determines which class of tool you need.
Buying constraint depth you do not have. Paying for 250 constraint types when three bind is a cost with no return, and the configuration burden is real.
Evaluating on distance saved alone. Distance is the easiest metric to improve and the easiest to improve dishonestly, by relaxing a constraint the comparison never checked.
Treating the plan as the deliverable. If a large share of orders change after planning, the operation is run by replans, and a tool that produces an excellent morning plan solves the smaller half of the problem.
How Locus Fits This Decision
Locus, the world’s first Decision-Intelligent, Agentic TMS, sits in the third class. The route planning engine solves against more than 250 real-world operating constraints, and because the same platform holds execution, plans are recomputed as conditions change rather than rebuilt on request. The Dispatch and Capacity agents hold the live network state the plan is computed against, and the DiSCO governance mechanisms, including Explainability and Autonomy Levels, determine which changes apply automatically and which wait for a planner.
That design is the right answer for a specific profile: several constraint types binding at once, meaningful order churn after the plan is published, and a plan that has to feed promises and customer communication rather than only a driver app. It is deliberately more platform than a single-depot operation with all-day windows needs, and we would rather say so than sell into a bad fit.
Where it earns its place is at that profile. A leading North American retailer running multi-hundred stores across ocean, rail and road consolidated six legacy systems into one planning and execution layer; the multimodal automation deployment reached 99% or better on-time delivery, 95% or better route compliance, more than $1M in savings and break-even inside the first year. Route compliance is the number that validates a planning decision, because a plan that is not followed did not solve the problem. A global lottery operator running technicians across 25 or more US states, each with its own contracts, labor rules and SLA windows, is the multi-constraint case in its purest form: the field service deployment delivered 20% lower SLA penalty risk, 18% lower fuel spend and 15% less drive time.
Locus has been recognized by Gartner for seven consecutive years across multiple research categories, including the 2026 Gartner Hype Cycle for AI-powered logistics and the 2026 Gartner Market Guide for Multicarrier Parcel Management Solutions, where ShipFlex is featured as a Representative Vendor. QKS Group positions Locus as a Leader in its SPARK Matrix for Transportation Management Systems, and Locus holds the number one position on G2 for Route Planning software. The platform has run more than 1.5 billion deliveries for 360+ enterprise customers across 30+ countries at 99.99% uptime.
In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.
Choosing a route planner well comes down to one honest piece of self-assessment: how tight are your windows, how many constraints bind at once, and how much of the day survives the plan you published this morning. Answer those three and the class of tool is determined, the shortlist shrinks to a few products, and the comparison becomes tractable. If your answers put you in the third class, Locus plans against 250+ constraints inside the system that also executes. Schedule a demo to see it planned against your own hardest day.
Frequently Asked Questions
How do I choose a route planner? Identify which constraints actually cause a plan to be rejected today, locate your tightest promised time window against the capability threshold, count how many constraint types bind at once, and measure how often the plan changes after publication. Those four answers determine the class of tool you need, and only then is comparing vendors useful.
What is the difference between a route planner and a route optimizer? A route planner sequences known stops into a short practical tour and treats conditions such as time windows as information. An optimizer treats those conditions as hard constraints the sequence must satisfy. The distinction is invisible with wide windows and decisive with narrow ones.
Do I need advanced route optimization for a small fleet? Possibly, because fleet size is not the determining variable. In our model an operation promising two-hour windows served only 41% of stops inside them with distance-first sequencing at just 15 stops per route, while a 60-stop operation with all-day windows was served perfectly by the simpler approach.
When is a simple route planner the right choice? When time windows are wide or absent, you run one depot with broadly similar vehicles, drivers are interchangeable, and orders rarely change after the plan is built. Under those conditions a simple planner produces essentially the same result as an optimizer at a fraction of the cost and configuration effort.
What should I test during a route planning software trial? Plan your hardest historical day rather than an average one, compare constraint violations rather than distance saved, add orders and remove a vehicle mid-plan to time the replan, and test at your peak volume rather than your typical volume, because optimization time grows faster than linearly with stop count.
How many constraints does route planning software need to handle? Only the ones that bind. Most operations find two or three conditions actually cause plans to be rejected, and a tool handling those well beats one advertising hundreds it will never be configured to use. Constraint breadth matters when several interact, because satisfying one can break another.
General
Real-Time Visibility Across In-House and 3PL Fleets: What Breaks in Multi-Country Operations in 2026
Sep 17, 2026
An owned fleet and a contracted carrier are two different measuring instruments. Here is what that does to a unified dashboard and to country comparisons.
Read more
General
Peak Season Driver Management: Why the Exception Desk Caps Your Hiring Plan in 2026
Sep 17, 2026
Peak hiring plans are sized against the labor market. The binding constraint is usually the exception desk, and it saturates far earlier than peak requires.
Read moreInsights Worth Your Time
How to Choose a Route Planner: Match the Tool to Your Binding Constraint in 2026