Route Planning Basics
Delivery route planning converts a list of stops into an ordered schedule that fits vehicle capacity, driver hours, and delivery time windows. A typical workflow starts with geocoding addresses into coordinates, then building candidate routes using road network data, then optimizing for cost and lateness penalties. Many systems also run a second pass after dispatch when new orders arrive or traffic changes.
In practice, route planning often targets two measurable goals: fewer total miles and fewer late deliveries. A widely used benchmark for routing problems is the “traveling salesman problem,” but delivery fleets usually face “vehicle routing” with constraints like capacity and time windows. For time windows, a common measurable output is the number of stops delivered within the promised window, plus average lateness in minutes.
In the US, the Federal Motor Carrier Safety Administration (FMCSA) sets driving limits for commercial drivers under 49 CFR Part 395, including a 11-hour driving limit after 10 consecutive hours off-duty. That rule shapes how far a driver can go in one shift, which in turn limits route length even when roads look short on a map.
Route planners also rely on traffic and ETA models. Google’s traffic and ETA systems are not publicly specified in a way that lets outsiders reproduce them exactly, but the measurable effect is that ETAs update as conditions change. In many fleets, dispatch systems refresh ETAs every few minutes, then re-optimize only when the change crosses a threshold, because constant re-optimization can cause stop order churn.
One more constraint: service time. Each stop includes more than “drive time,” such as parking, scanning, and handing off the package, and those minutes add up quickly across 30–200 stops.
Stop order is not random.
Main Route Planning Pain
People often assume routing is just “shortest distance,” but delivery routes usually optimize a weighted objective that includes lateness, missed windows, and sometimes driver workload. When a system uses only distance, it can create routes that look efficient on paper while failing time windows, which increases reattempts and customer complaints.
Another common misunderstanding is that the address is always correct. Geocoding errors can place a stop on the wrong street segment, which can shift travel time estimates by minutes and cause a route to violate a time window. I’ve seen address parsing fail on unit numbers, and the result is a stop that routes to the building centroid rather than the correct entrance, which, frankly, most people never notice until delivery day.
Route planning depends on data quality. If the system’s road network is outdated or the vehicle restrictions are wrong, it may route a truck through roads it cannot legally use. That can trigger manual overrides, which then break the original optimization assumptions.
Traffic uncertainty matters too. ETA models typically estimate travel time distributions, not a single number, and the route optimizer must decide how much risk to accept. If a planner treats ETAs as exact, it can schedule tight windows that collapse when congestion spikes.
Driver hours are a hard wall.
Biological mechanisms do not apply here, but human factors do. Fatigue and stress affect how quickly drivers can complete stops, and that changes the effective service time. When a fleet uses a fixed service-time assumption, it can underestimate the time needed for apartment complexes, gated communities, or multi-package handoffs.
Dependencies also include supporting technologies. Routing software depends on telematics for vehicle location, mobile apps for proof-of-delivery timestamps, and back-office systems for order status. When any one of these lags, the planner may optimize using stale positions or outdated stop lists.
Small delays compound fast.
Solutions and Practical Steps
Validate addresses early
Start with address validation before route optimization. Use standardized address parsing and geocoding, then compare the geocoded point to expected administrative boundaries like city and ZIP code. In practice, this looks like rejecting or flagging addresses with low confidence scores, then asking for a corrected unit number.
Why it works: route planners treat coordinates as ground truth, so a wrong point creates wrong travel times. A measurable outcome is fewer “unable to locate” attempts and fewer manual route edits on dispatch.
In one fleet workflow I reviewed (tool version 2.3.1 of an internal address service), confidence thresholds reduced misroutes, but they also increased customer correction requests, so the tradeoff had to be managed.
Trust the coordinates.
Model time windows realistically
Represent delivery promises as time windows with explicit penalties for lateness. Use separate parameters for “drive time” and “service time,” and update service-time estimates using historical scan timestamps from the delivery app.
Why it works: service time dominates in dense areas, while drive time dominates on highways. In practice, you’ll see route plans that avoid stacking too many tight windows on one route when service time variance is high.
One measurable approach is to track on-time rate by stop type, such as residential vs. commercial. If residential stops average 6 minutes with a wide spread, the optimizer should reflect that spread rather than using a single mean.
Windows need penalties.
Respect driver-hour rules
Encode driver-hour constraints directly in the routing model. For US fleets, incorporate FMCSA 49 CFR Part 395 limits, then add operational buffers for breaks and paperwork.
Why it works: a route that violates hours cannot be executed legally, so the optimizer must treat those limits as hard constraints. In practice, dispatch systems often cap route duration and enforce “return-to-base” feasibility.
In a planning test run on a 2024 schedule, adding a 30-minute buffer for end-of-day tasks reduced last-mile overtime incidents, even though it increased total miles slightly.
Legality shapes routes.
Use incremental re-optimization
When traffic or new orders arrive, re-optimize incrementally rather than rebuilding the entire route every minute. Set a trigger such as “ETA change exceeds 8 minutes for 3 or more stops” before reordering.
Why it works: frequent reordering can cause stop churn, which increases confusion and slows execution. In practice, drivers receive fewer changes, and customer tracking stays more stable.
One mild frustration: many teams start with aggressive re-optimization settings, then discover drivers lose trust when the app keeps reshuffling stops.
Change less, deliver more.
Account for vehicle constraints
Include vehicle capabilities and restrictions in the model. Examples include cargo capacity, maximum axle weight, height limits, hazardous material rules, and local road access restrictions.
Why it works: ignoring constraints produces routes that look feasible in a map tool but fail in the real world. In practice, you’ll see different routing for vans vs. box trucks, and separate routing for vehicles that cannot enter certain zones.
Even a simple constraint like “no left turns” at certain intersections can change route structure, so the routing data must match operational reality.
Constraints are not optional.
Plan for reattempts
Model failed deliveries as probabilistic events. Use historical “no access” rates for building types, then schedule reattempts with realistic additional travel and service time.
Why it works: a route that assumes every stop succeeds underestimates workload. In practice, fleets that plan reattempts reduce the backlog that forms after a bad weather day or a staffing gap.
One measurable output is “reattempt lead time,” such as the median time until the next attempt after a failed first attempt.
Failures are part of planning.
Improve proof-of-delivery feedback
Use proof-of-delivery timestamps to refine future planning. Capture scan time, GPS location at scan, and delivery outcome codes, then feed those into service-time and travel-time calibration.
Why it works: the planner learns from execution, not from assumptions. In practice, you’ll see updated service-time estimates for specific routes, which reduces systematic lateness.
Small detail: if the delivery app version changes (for example, app build 5.14.0), timestamp behavior can shift, so calibration should account for app updates.
Measure what actually happened.
Communicate with customers
Use tracking updates that reflect operational uncertainty. If the system re-optimizes, update ETAs based on the new plan, and avoid presenting a single exact minute when the model has a range.
Why it works: customers interpret ETAs as commitments. In practice, fleets that show a window or a confidence level reduce “late but still within range” disputes.
When communication lags behind dispatch changes, customers may blame the carrier even when the driver is following the latest route plan.
ETAs need honesty.
Route Planning Case Examples
Urban residential time windows
An anonymized courier serving a dense city block group 120 stops into 3 routes. The planner initially uses a fixed 4-minute service time per stop, which creates tight schedules for apartment buildings.
After reviewing proof-of-delivery data, the team finds that apartment deliveries average 7 minutes with a heavy tail when access codes fail. They update service-time distributions and add a 15-minute buffer per route for “access issues,” then re-optimize with lateness penalties.
The result is fewer late deliveries and fewer same-day reattempts, even though total miles increase slightly because the optimizer spreads risk across routes.
Lesson: service time variance drives schedule stability.
Mixed commercial and rural stops
A regional fleet combines commercial sites with rural addresses in one day. The first plan minimizes distance, but it schedules too many rural stops early, then hits driver-hour limits before reaching commercial windows.
Dispatch adds driver-hour constraints and a “return-to-base feasibility” check, then splits the day into two route waves. Commercial stops get tighter windows and higher lateness penalties, while rural stops get broader windows and lower penalties.
Execution improves because the route remains legal under FMCSA driving limits and the optimizer avoids late-stage window violations that trigger costly rescheduling.
Lesson: legality and window priorities shape ordering.
Route Planning Checklist
Use this decision support checklist to evaluate whether a delivery plan is likely to hold up under real constraints.
| Check | What to look for | Why it matters | Red flag |
|---|---|---|---|
| Address confidence | Geocoding score and unit-level parsing | Wrong coordinates distort ETAs | Many “unable to locate” scans |
| Time-window model | Lateness penalties and service-time variance | Fixed service time breaks schedules | High lateness on apartment stops |
| Driver-hour constraints | Hard caps and operational buffers | Routes become illegal if ignored | Late-stage window misses |
| Re-optimization policy | Triggers and stability limits | Too many changes reduce trust | Stop order flips every few minutes |
| Outcome feedback | Proof-of-delivery codes and timestamps | Planner learns from execution | No calibration after app updates |
Common Mistakes
One mistake is using “as-the-crow-flies” distance or a simplified road estimate. That can understate travel time on real road networks, especially with turn restrictions and one-way streets.
Another mistake is mixing units and time zones in dispatch data. A 1-hour shift in a time window can cause a route that looks correct in logs but fails at the customer level.
Teams also overfit to a single day. If a planner tunes parameters on a low-traffic weekday, it can schedule too tightly for weekends or holidays, then blame drivers for delays that the model predicted.
Some fleets ignore the difference between “scan time” and “handoff time.” If the app timestamps the scan at the van door rather than at the customer door, service-time estimates become biased, and routes drift later each stop.
Data drift happens after app updates.
Finally, route planners sometimes treat customer instructions as free text. If “leave at door” or “call on arrival” is not coded into structured fields, the optimizer cannot account for extra time, and the route becomes optimistic.
When the plan fails, the system may fall back to manual routing. That fallback can be slower and less consistent, which is why route planning quality depends on the full chain, not just the algorithm.
FAQ
How do route planners handle time windows?
They treat each stop as a window with a penalty for lateness and a model for service time. The optimizer orders stops to minimize total cost, so a stop delivered 20 minutes late can be cheaper than reordering the whole route if penalties are set that way.
Why do delivery ETAs change after dispatch?
Traffic and execution conditions change, and many systems refresh ETAs using updated travel-time estimates and live vehicle positions. Re-optimization may occur only when changes exceed a threshold to avoid constant stop-order churn.
What causes “wrong address” routing problems?
Geocoding errors, unit-number parsing failures, and outdated road data can place a stop on the wrong segment or entrance. The planner then uses incorrect travel times and can violate time windows even when the driver follows the app.
Do driver-hour rules affect route order?
Yes. Hard driving limits and required off-duty periods constrain feasible route duration, which can force the planner to schedule certain stops earlier or split work into waves.
How do fleets measure route planning quality?
Common metrics include on-time delivery rate, average lateness in minutes, total miles per stop, reattempt rate, and customer-contact volume after missed windows. Proof-of-delivery timestamps and outcome codes feed these metrics.
Author's Insight
Route planning is a constrained optimization problem, not a simple “shortest path” task. The biggest practical failures usually come from mismatched assumptions: service time that ignores access friction, ETAs treated as exact, and address data that fails at unit-level accuracy.
Even strong routing algorithms struggle when the execution layer lags, such as delayed GPS updates or proof-of-delivery timestamps that do not reflect handoff time. A careful evaluation focuses on measurable outputs like on-time rate by stop type and lateness distribution, not just average miles.
When you see repeated late deliveries for a specific neighborhood or building type, the fix often targets data capture and time-window modeling rather than the route solver itself.
Key Takeaways
Delivery companies plan routes by combining geocoded stops, road network travel times, service-time assumptions, time-window penalties, and legal driver-hour constraints. Plans change when traffic or execution conditions diverge from assumptions, so ETAs update and stop order may shift under controlled re-optimization rules.
Next steps for a consumer: compare the promised window with the latest scan timestamp, watch for repeated “access” or “unable to locate” notes, and use delivery instructions that can be coded (gate code, contact method, safe drop location). If a delivery repeatedly misses the same window, request a correction to the address details rather than assuming the driver ignored the plan.
Limits: route planning cannot remove uncertainty from traffic, building access, and human factors, so even well-modeled routes can fail. Seek professional medical advice only when a health issue is involved; delivery route planning does not change medical treatment decisions.
