.png)
Fleet routing is not a shortest-path problem. It is the Vehicle Routing Problem, it is NP-hard, and twenty stops on a single van already allow more than 60 quadrillion possible round trips. This is what actually makes it hard, the three properties that decide whether a solver pays for itself, and five questions worth asking before you pick one.
At 06:40 the plan is good. Eighteen vans, 340 stops, every time window respected, the depot loaded in route order.
At 09:15 a customer moves a delivery to the afternoon, a van loses a tyre outside Ghent, and three orders land from the morning cut-off. The plan that was optimal at 06:40 is now a list of promises somebody is going to break.
That is the real problem. Not finding a good set of routes once, but holding a good plan together while the day argues with it. Most writing on fleet route optimization skips straight to the benefits. This piece is about the mechanics: why the problem is hard, which three properties decide whether a solver earns its cost, and what to ask a vendor before you commit.
Shortest path is solved. One vehicle, one origin, one destination, and Dijkstra's algorithm has handled it since 1959. Your navigation app does this several times a second.
Fleet routing is a different problem with a different name: the Vehicle Routing Problem. You are not ordering one trip. You are deciding which vehicle takes which stops, in what order, while respecting everything that constrains the operation. Those decisions are coupled. Move one stop between two vans and both routes change, which changes which other stops fit.
The VRP is NP-hard, and the search space grows faster than intuition allows. One vehicle with twenty stops and no constraints at all already admits 60,822,550,204,416,000 distinct round trips. That is a single van on a quiet day. Now add seventeen more vehicles, time windows, capacities and driver hours.
The practical consequence: nobody enumerates these. A solver searches, and stops when it runs out of the time you gave it. Which means solution quality is a variable, not a given. Two solvers handed the same problem and the same three seconds will return different plans, and the difference is money.
Vendor pages advertise constraints as a checklist: time windows, capacities, skills, breaks, multi-trip. The list tells you nothing, because the difficulty is in how they interact.
A waste collection round is capacity-bound before it is time-bound. A full truck cannot take another bin until it visits a dump site, so the tipping trip is part of the route rather than an interruption to it. Plan for time windows alone and you produce a schedule that is arithmetically fine and operationally impossible.
Field service inverts this. Capacity is rarely binding, skills are. A qualified technician two hours away may beat an unqualified one ten minutes away, and a solver that treats drive time as the only cost will get that wrong every time.
So the question is never whether a solver supports a constraint. It is whether it optimizes across all of them at once, or applies them in sequence as filters. Sequential filtering is much easier to build and produces noticeably worse plans, because each stage throws away options the next stage needed.
Almost every disappointing optimization project traces to one of these being weaker than the operation required.
Drive time is the cost line. Last-mile delivery is commonly benchmarked at 40 to 55 percent of total shipping cost, and labour and fuel dominate that. Which means a few percent off total drive time is not a rounding improvement, it is the difference between a route being profitable and not.
BPS cut total drive time by 23 percent across 18 trucks after moving off manual planning. Gains of that size come from the plan being genuinely better, not from the planner being faster.
This is also why "we already have route optimization" is not an answer to the question of whether a better solver is worth evaluating. A solver that reaches 90 percent of the achievable saving is not 90 percent as good. The remaining gap is precisely the margin you were trying to capture.
Overnight batch planning made sense when the day was predictable. It is not.
When the 09:15 disruption lands, a dispatcher has perhaps thirty seconds to decide whether to push the afternoon stops, reassign them, or absorb the delay. If a full re-solve takes twenty minutes, nobody re-solves. They patch one route by hand, and the quality they paid for quietly leaks away over the course of the morning.
Speed is therefore not a separate feature from quality. It is the thing that determines whether you keep your quality after 09:00. The Solvice Sync endpoint returns a re-optimized plan in under five seconds for problems below roughly 50 jobs, which is fast enough to sit inside a dispatcher's workflow rather than beside it.
The harder version of this is re-optimizing the whole fleet rather than repairing one route. Repair is fast and local, and it gives up the cross-vehicle moves that produced the saving in the first place.
Most operations quietly shrink their problem until their tooling can handle it. They split by region, by depot, by day. Each split is a constraint given up: a stop near the boundary can no longer move to the van that should have taken it, and multi-day work cannot balance across the week.
That is a real cost, and it is usually invisible because the plan that results still looks reasonable. Solving large instances well is an active research problem, not a settled one. The work on very large scale routing (Arnold, Gendreau and Sörensen, 2019) has pushed published benchmark instances into the tens of thousands of stops, and doing that both quickly and well is still where the difficulty sits.
Solvice handles up to 20,000 orders in a single solve with 50+ constraint types. The number matters less than the principle: the fewer artificial splits you need, the more of the available saving is actually reachable.
For most of the history of this field, the three properties above traded against each other. You could have a high-quality plan overnight, or a fast answer of middling quality, or you could break a large problem into pieces and solve each piece well. Pick two.
The interesting work now is on refusing that trade: solution quality that holds at interactive speed, on problems large enough that they used to be split apart before anyone looked at them. That is the direction the next generation of solvers is moving, and it is worth knowing which of the three your operation is actually short on before you go shopping.
Is route optimization only worth it for large fleets?
No, but the threshold is about complexity rather than vehicle count. A five-vehicle operation with tight time windows, mixed capacities and skill requirements has a harder problem than a thirty-vehicle operation dropping identical parcels in one city. If a competent planner needs more than an hour a day, or routinely cannot find a plan that satisfies everything, the problem is past manual.
How is this different from what a navigation app does?
A navigation app answers "what is the fastest way from here to there" for one vehicle. A solver answers "which of my vehicles should take which stops, in what order, given everything that constrains them". The first is an input to the second.
Do I have to replace my existing planning system?
No. Solvice is a stateless API. You send jobs, resources and constraints, and you get an optimized plan back. The dispatch screen your planners already use stays where it is.
What data do I need before starting?
Stop locations, service durations, vehicle capacities, time windows and shift patterns cover most initial models. Historical travel times improve the result substantially, because plans built on straight-line estimates fail in exactly the hours that matter.
The route optimization API documentation covers the constraint model and the endpoints. If you want to know how your own operation behaves under a solver, send us a day of real data and we will model it.
.png)
