The load does not fit every vehicle
Weight, volume, pallet count, and loading order constrain which vehicle can carry which shipment.
Vehicle routing
Turn shipments, vehicle capacity, and time windows into a dispatch plan people can run.
Model vehicles, drivers, loads, delivery windows, vehicle restrictions, fixed routes, and last-minute changes together. The output is a route candidate people can review, adjust, and confirm.
- Start data
- Excel, CSV, or a route table is enough for the first diagnosis.
- Decision scope
- Assign shipments and route order at the same time.
- Confirmation
- People review unassigned jobs, delays, and fixed-route changes.
Dispatch plan / Today
Candidate route set
Capacity
Weight and volume are checked per vehicle.
Windows
Delivery windows are treated before distance savings.
Compatibility
Temperature, equipment, and vehicle size constraints stay visible.
Dispatch count
On-time rate
Estimated distance
Unassigned reasons
The real problem
Drawing shorter lines on a map is not the hard part.
A route has to fit load, time, vehicle type, driver hours, depot rules, and the changes that arrive after the first plan.
Delivery windows break simple distance order
Morning reservations, receiving breaks, and service time can make the nearest stop the wrong next stop.
Vehicle compatibility matters
Frozen, chilled, tail-lift, vehicle size, and customer restrictions narrow the candidate set.
Breakdowns and urgent orders change the whole plan
A useful system repairs the remaining plan while keeping already confirmed work stable.
Vehicle routing is a combined decision: shipments x vehicles x load x time x changes = a dispatch plan that can actually run.
Model the decision
Separate mandatory rules, preferences, and improvement metrics.
Treating every rule with the same strength either creates no candidate or creates a plan people cannot trust.
Mathematical frame
min lexicographic(unassigned, late, overtime, changed fixed routes, vehicles, distance, load imbalance)
The page demo is a deterministic heuristic for explanation, not a production optimization engine and not a guarantee of optimality.
Hard
Rules that must hold
-
Capacity limits
Weight and volume stay within the vehicle limits.
-
Vehicle and temperature fit
Only vehicles with the right type, equipment, and temperature capability are considered.
-
Delivery windows
Arrival and service start must fit the allowed receiving window.
Soft
Preferences to preserve
-
Fixed routes
Keep regular customers on their usual vehicle when it is still feasible.
-
Small changes
Avoid changing already loaded, notified, or confirmed routes.
-
Balanced work
Reduce uneven mileage, load, and overtime between vehicles.
Objective
Metrics to improve
-
Unassigned shipments
Expose the shipments that cannot fit and the reason they fail.
-
Distance and drive time
Reduce travel after hard rules and high-priority shipments are handled.
-
Delay and overtime
Show when the plan creates late arrivals or work beyond the shift.
Interactive example
Change the day and see how the dispatch plan reacts.
Use the controls to simulate a vehicle breakdown, urgent order, congestion, capacity checks, and compatibility rules.
This browser demo uses fictitious data and straight-line travel estimates. It is not a production optimization engine and does not guarantee road distance, legal compliance, loadability, or optimality.
Dispatched
On time
Distance
Fixed route
Overtime
Route map
Approximate route lines
The map is a schematic. Production projects use approved map, matrix, or road-time APIs only after cost, terms, and privacy are checked.
Vehicle routes
Vehicle-by-vehicle day
Unassigned
Shipments that need a decision
Rule design
Turn dispatch know-how into an explicit data contract.
The first prototype is usually a data and rule conversation. These are the rule groups that need names, priorities, and examples.
VRP-01
Hard
Capacity limits
Weight and volume cannot exceed vehicle capacity.
VRP-02
Hard
Delivery windows
A route candidate must respect receiving windows when they are mandatory.
VRP-03
Hard
Compatibility
Temperature, equipment, and vehicle size restrict eligible vehicles.
VRP-04
Soft
Fixed route continuity
Regular customers stay with the usual vehicle when feasible.
VRP-05
Soft
Small repairs
Already loaded or notified routes can be locked before recalculation.
VRP-06
Objective
Unassigned first
Reduce high-priority unassigned shipments before optimizing distance.
VRP-07
Objective
Distance and time
Reduce drive distance after hard rules are satisfied.
VRP-08
Objective
Balanced load
Avoid concentrating mileage, load, and overtime on one vehicle.
VRP-09
Objective
Reviewable changes
Show why a shipment was moved, delayed, or left unassigned.
Explainable output
A route candidate is useful only when people can understand why it was made.
The screen should show the order, arrival time, capacity, rule warnings, and unassigned reasons before anybody confirms the dispatch plan.
Vehicle order and times
Show depot departure, arrival, service, waiting, break, and return by vehicle.
Unassigned reasons
Classify capacity, compatibility, time-window, and work-hour failures.
Plan comparison
Compare unassigned count, distance, delay, overtime, vehicle count, and load rate.
Manual locks
Let people lock confirmed routes and recalculate only the remaining work.
Delivery operations
Useful wherever vehicles and stops must be combined under local rules.
The model changes by domain, but the core decision is the same: which vehicle carries which shipments, in what order, under which rules.
Wholesale and local delivery
Store delivery windows, fixed routes, vehicle count, and multi-depot rules.
Food and cold-chain delivery
Ambient, chilled, frozen, loading, reservation, and wait-time rules.
Pickup and collection
Collection amount, intermediate facilities, vehicle capacity, and collection frequency.
Building materials and equipment
Vehicle class, lift or crane needs, site time windows, loading order, and returns.
Data
Start from current route sheets, vehicle lists, and rule notes.
A first prototype can begin with one anonymized day or week. The goal is to learn whether the rules can be represented and whether the candidate helps the dispatcher.
Shipment list
Location, delivery window, service minutes, weight, volume, temperature, priority, and fixed vehicle.
Vehicle and driver list
Capacity, vehicle type, equipment, temperature capability, work hours, and depot.
Business rules
Hard rules, preferences, objective priorities, fixed routes, lunch breaks, and outsourcing rules.
Current plan and results
Current route table, actual arrivals, waiting, mileage, unassigned shipments, and manual fixes.
Small prototype
Check whether your dispatch problem can be calculated before building a full system.
A fixed-scope prototype can compare current plans with candidate routes, expose missing data, and clarify what a production system would need.
Good fit for custom development
Rules are too local for an off-the-shelf dispatch product, and the route candidate needs explainable reasons.
Packaged service first
If routes are fixed, shipment volume is small, or conditions are simple, an existing routing tool may be the better first step.
Next paths
Connect routing with demos, evidence, and related planning problems.
Vehicle routing often touches visit scheduling, production timing, inventory, and case assignment. Keep the internal links visible.
FAQ
Questions before automating dispatch planning.
These answers clarify the demo boundary, map data, manual review, and integration scope.
Is this page demo the production optimizer?
No. The page demo is a simple deterministic heuristic for explanation. Production work chooses a solver, search method, map data, and infrastructure after scale and rules are known.
Can we start from Excel or CSV?
Yes. A first review can start from anonymized route sheets, shipment lists, vehicle lists, rule notes, and a current plan.
Can map or route APIs be connected?
Yes. Road distance, travel time, traffic, vehicle restrictions, API cost, terms, caching, and privacy must be checked before integration.
Can the dispatcher change the route manually?
Yes. The system should allow people to lock vehicles or stops, then recalculate the remaining work and compare the impact.
Will every shipment always be dispatched?
No. When capacity, vehicle type, or time is insufficient, the system should expose unassigned shipments and the reason rather than hiding them.
Check your operation
Your dispatch work may be expressible as a mathematical system.
We can review the current route table and rule notes, then identify the smallest data set worth testing.