Ask most carriers whether they use route optimization and they'll say yes. Ask them whether they use route re-sequencing and the answer gets more complicated.
These are not the same thing. Conflating them is one of the most common operational misunderstandings we encounter when talking to dispatch teams — and it's one that has real money attached to it.
Static Route Planning: What It Is and What It's Good For
Static route planning is the process of generating optimized delivery routes from a known stop list before dispatch. You load your addresses, apply vehicle capacity constraints, set time windows, run the solver, and produce manifests. This is what tools like Routific, OptimoRoute, and the routing modules inside most TMS platforms — McLeod, MercuryGate, Trimble TMW — do well.
The underlying algorithm is typically a variant of the Vehicle Routing Problem (VRP) or its capacity-constrained form (CVRP). For operations with time delivery commitments, it's VRPTW — the VRP with time windows. These are well-studied combinatorial optimization problems. Clarke-Wright savings algorithm handles smaller instances quickly; more sophisticated Branch-and-Cut solvers (similar to what Concorde uses for TSP) handle larger instances. Google OR-Tools provides a solid open-source framework for this class of problem.
Static planning is powerful and genuinely valuable. An operation that moves from driver-intuition-based routing to optimized static planning routinely sees 10–20% mileage reduction, which translates directly to fuel savings, reduced driver hours, and better on-time delivery (OTD) rates. If you're not doing this, start there.
The limitation of static planning isn't the algorithm. It's the word "static." The route that was optimal at 4 p.m. when planning ran may not be optimal — or even executable — at 6:45 p.m. when conditions have changed.
Dynamic Re-Sequencing: A Different Problem Class
Dynamic re-sequencing operates on the live state of an already-dispatched or about-to-depart route. The inputs are different. Instead of a clean stop list, you're working with a partially-executed manifest: some stops completed, some in progress, vehicles at known positions, drivers at specific points in their HOS windows (per 49 CFR 395), and a batch of new constraints that just arrived — address corrections, volume changes, access exceptions, driver substitutions.
The computational problem is also different. Static planning typically optimizes across multiple routes simultaneously to achieve global optimality. Re-sequencing optimizes within the constraint of the current route structure — you're not rebuilding the entire day's manifest, you're finding the best modified sequence for the affected routes given what's already happened and what can't change.
This is why re-sequencing needs to run in seconds, not minutes. A static planning run for 400 stops might take 45 seconds to 3 minutes depending on solver and hardware — that's fine when planning runs at noon for tomorrow. A re-sequencing computation that takes 3 minutes at T-minus-5-minutes before vehicle departure is operationally useless. The constraint isn't algorithmic quality; it's wall-clock latency.
The approach that works for fast re-sequencing typically involves solution construction heuristics that can produce a near-optimal feasible sequence within a fixed time budget. For 200–300 stops with a realistic number of changed constraints, a well-implemented VRPTW heuristic using insertion or local-search methods can deliver results within 10–30 seconds at acceptable quality loss compared to exact optimization.
The Practical Scenario: What Happens at 6:48 p.m.
Take a mid-sized regional carrier running 14 routes out of a single depot, averaging 35 stops per route. The static planning run happened at 3 p.m. Manifests are locked. At 6:48 p.m., an e-commerce client pushes a correction batch: 11 addresses updated, 4 stops removed, 3 addresses flagged as residential access exceptions requiring a smaller vehicle code.
Static route planning cannot help here. The planning run is done. Re-running it from scratch on the live manifest would take time the depot doesn't have, and would discard optimizations already loaded on vehicles.
What re-sequencing does: it takes the 14 current routes, identifies which routes contain the 18 affected stops, runs a constrained re-sequence on only those routes (not the full 14), and outputs a revised stop order for each affected route. The 3 vehicle-code exceptions get flagged for dispatcher resolution — they can't be auto-resolved because they require a vehicle swap decision. The remaining 15 updates are re-sequenced and pushed to driver apps within 30 seconds.
The dispatcher reviews the delta view — original sequence vs. updated sequence — for the flagged vehicle exceptions, makes a decision on 3 stops (redirect, defer, or manual reassign), and vehicles depart with updated manifests within the departure window. The net dispatcher time: 4–6 minutes instead of 20–35.
The Tool Landscape: What Handles Each Problem
Most route planning platforms are clear about their scope. Routific and OptimoRoute both optimize pre-dispatch routes well. Onfleet and Bringg provide driver app management with some re-optimization hooks. Project44 and FourKites provide supply-chain visibility — they know where things are, but they don't tell you how to re-sequence them.
The gap is in the post-cutoff, pre-departure window. Very few platforms were designed around the specific constraint: live manifest state as the planning input, departure deadline as the time constraint, partial-route modification (not full rebuild) as the output mode.
We're not saying static planning tools are insufficient. We're saying they were built for a different problem. A carrier that has a strong static planning process and adds real-time re-sequencing for the post-cutoff window is addressing two genuinely separate operational failure modes. Both matter. Neither replaces the other.
Why This Distinction Matters for Your Stack Evaluation
When evaluating routing software, the question to ask isn't just "can it optimize routes." It's "can it handle a 40-stop correction batch at T-minus-8-minutes, and what does the dispatcher interaction look like when it does."
If the answer is "the dispatcher re-runs the planning tool manually and reviews all routes," that's static planning applied to a dynamic problem. It will work, but the dispatcher experience will be painful enough that it gets bypassed under pressure — which means the manual gut-feel re-sequence happens anyway.
If the answer is "the system ingests the correction batch, identifies affected routes, computes new sequences for only those routes, and pushes updates to drivers with a delta view for dispatcher awareness," that's re-sequencing. That's the architecture that fits the 6:48 p.m. scenario.
Understanding how Parcelarc handles the post-cutoff re-sequencing pipeline starts with this distinction. The platform overview covers how the constraint ingestion layer connects to your existing TMS to enable this without replacing the planning tooling you already run.