Assumption 1: the passenger list is fixed
Classic models take the passenger set as fixed when defining the problem to be solved. In a real operation the list changes weekly, sometimes daily: joiners and leavers, shift changes, leave, transfers.
On its own the fixed-list assumption looks harmless. Its consequence is this: the plan must be rebuilt on every change. In a hand-built plan that takes hours, so the plan usually is not updated — it stays in use in its stale form and occupancy quietly declines.
Assumption 2: travel times are constant
Most models treat the time between two points as a single number. Within a city that number varies markedly by hour; the same route can take several times as long at 07:30 as at 10:00.
A plan built on one travel time is internally consistent on paper. In the field, the vehicle that has to make the shift sits in traffic the plan never anticipated. The problem is not the algorithm but the assumption handed to it.
Assumption 3: the problem is solved once
The usual setup in the literature is: input is given, the best solution is sought, the solution is returned. Operations do not work that way. The plan is executed, the field happens, and the gap between them emerges — and that gap is the most valuable input to the next plan.
A solve-once framing cannot use that feedback. Every manual correction the planner makes is a correction that will have to be made again in the next plan. The same mistake is fixed afresh every week.
Assumption 4: constraints are independent
Capacity, ride time, walking distance and shift time are listed as separate constraints in the classic setup, and are usually handled in sequence: group first, then order, then verify.
In reality those four are a single decision set. Changing the walking limit changes the stop count, stop count changes ride time, ride time changes vehicle count, vehicle count changes capacity. A method that takes them in sequence cannot revisit its first decision in light of the later ones.
So what does work?
Criticising the assumptions is not rejecting the literature; it is knowing which method holds under which conditions. In a small, stable operation the classic approach is more than sufficient.
When scale grows and variability rises, what is needed is different: an approach that weighs the constraints together, works on the real road network with time-sensitive traffic data, and learns from every plan executed and every manual correction made. vitaRoute's own routing engine was developed for exactly this, within a TÜBİTAK-supported R&D project.
When assessing a routing method, the question to ask is not 'which problem does it solve' but 'which assumptions does it make'. If the assumptions do not match your operation, the plan will break in the field however powerful the method is.