Minimizing risk of delays
When solving a routing task, one priority is to get routes that ensure the quality of service to the end customer: ensure that the courier arrives during the specified time window. This is particularly relevant for customers with a large number of orders and narrow time windows: this problem is usually faced by online stores, delivery services, and retail network suppliers.
RouteQ lets you build routes that meet hard constraints of the order time window (see Order time window). However, sometimes you might need more pessimistic routes to give the courier some more time for things like unscheduled delays at previous orders or unexpected traffic jams.
To get such routes, use the option options.minimize_lateness_risk = true.
How it works
When building routes, RouteQ forecasts the time to travel between points on the road graph. It also factors in the likely deviation from the forecasted value. The minimize_lateness_risk parameter takes the likely deviation of the resulting solution into account.
For example, the order time window is from 8:00 to 9:00 and the courier departs from the previous location at 7:30, and the mathematically expected travel time is 81 minutes (with a probability of 0.4 that they'll arrive in 75 minutes, a probability of 0.4 in 80 minutes, a probability of 0.1 in 90 minutes, and a probability of 0.1 in 100 minutes). The system will plan their arrival for 8:51.
However, there's a 0.1 likelihood that the courier will be 10 minutes late and arrive at 9:10.
If the probable deviation is outside the time window, it's included into the final solution as a probable penalty for being late at this order location. The penalty.late.fixed and penalty.late.minute parameters are used to calculate this penalty. If they are not set, the penalty.out_of_time.fixed and penalty.out_of_time.minute parameters are used.
For more information, see Penalties for order time window violation.
If the minimize_lateness_risk parameter is specified, those parameters are taken into account even when the order time window is hard and the option location.hard_window = true.
If you use the option minimize_lateness_risk, this might degrade the other solution metrics. There is a downside to improving your customer experience: you need more resources or get less optimal routes in terms of traveled distance or total time. This is why we recommend that you use this option only when absolutely necessary.
The examples below demonstrate how the solution changes when using this option.
Example 1
There are 3 orders with fairly narrow and hard windows. minimize_lateness_risk = false. The algorithm plans 1 route that arrives at point 3 at 10:59 with a time window until 11:00.
API request (JSON) ⋅ API response ⋅ View on map
Example 2
Example 1, but minimize_lateness_risk = true.
The algorithm also plans 1 route, but the sequence of points 2 and 3 are different. The route has become less optimal in terms of mileage and travel time compared to example 1, but now the courier has some more time available before the end of the order time window. This makes the route less risky in terms of possible late arrivals.
API request (JSON) ⋅ API response ⋅ View on map
Example 3
Example 2, but the values for locations.penalty.out_of_time.fixed and locations.penalty.out_of_time.minute are much lower than the defaults.
The algorithm plans the same route as in Example 1. In this case, the algorithm had a choice: set a less optimal route that involves a lower risk in terms of possible late arrivals or set a more optimal route that involves a greater risk. Since the late arrival penalty amount is very small, the system chose the option with a more optimal route.
API request (JSON) ⋅ API response ⋅ View on map
Example 4
Example 2, but the values of locations.penalty.out_of_time.fixed and locations.penalty.out_of_time.minute are much higher than the defaults.
The algorithm plans 2 routes, distributing orders across 2 vehicles: the penalty amount for possible late arrivals exceeded the cost of using another vehicle.