PTV Logistics Product Forum

the requirement of a driver getting some kind of guaranteed “workload” / “revenue” instead of just minimizing the number of utilized vehicles? How to achieve a fair balance over a set of drivers?

When it comes to accounting for order revenue, two new feature have recently been added that offer us some options, if the goal is to account for specific order revenues:

• Orders can have “insourcingRevenue”, which is “won” when they are planned: Defines the revenue for scheduling the order on a route. The order will only be scheduled on a route when the sum of the outsourcingCost and insourcingRevenue is greater than the added route cost. When both the outsourcingCost and insourcingRevenue are omitted, the optimization will try to schedule the order regardless of the added cost.
• Vehicles can have an “unused” cost, which is “lost” when they are not used

Basic setup: we assign fixed costs to all vehicles based on their drivers’ revenue targets, and add insourcingRevenue to all orders.
Result: OptiFlow will now evaluate whether planning a set of orders with total revenue X, is worth adding the fixed route cost.
(plus the variable costs, but we can balance things based on planning priorities).

The “unused” cost is just another piece of the puzzle that we can add here if need be.

On the broader topic of creating plans with balanced routes rather than strictly minimizing the number of vehicles, we can steer the optimization in various ways.
The “trick” is always the same: we want to make it so planning tasks on routes is cheap initially, in order to “fill those buckets” first.

For this, we can use (a combination of) the following features:

Vehicles.costs: incurred when a route exceeds a certain threshold (lower than the actual max, which is a hard constraint)

• overtimes
• overdistances
• overstops
• overloads

Vehicles.preferences:

• routeDuration (preferredDuration)

Say we define a load called “revenue” and add that to each order. And we want the vehicles to each make at least 1000€ each.

Basic setup: we set the overload threshold for “revenue” for each driver to 1000, and define an extraCostPerUnit of 2 (for example).
Result: OptiFlow will now be incentivized to first give each driver their first 1000 worth of orders first, rather than giving more to work those those already “full”.

This can then again be combined with vehicle fixed costs, to further finetune the decision of starting new routes vs adding to existing ones.

Guaranteed Driver Workload / Fair Balance

The API has a built-in mechanism for this: Route Duration Balancing.

• Importance: Controls the trade-off between minimizing total cost and equalizing route durations across the fleet. At 0, pure cost minimization (some drivers get long routes, others get nothing). At 1, strong push toward equal-length routes — at the expense of higher total cost.
• Unused vehicle cost: A cost penalty for vehicles that go unused. Setting this high forces the optimizer to spread work across all available drivers rather than concentrating it on fewer vehicles.
• Fixed vehicle cost: The fixed cost per used vehicle. Lowering this relative to the unused vehicle cost further incentivizes using all drivers.

The optimizer uses cost penalties to encourage driver activation and balanced workload distribution. Together, these create a soft incentive for more even hour allocation across drivers.
For harder guarantees, you'd combine this with overtime thresholds (costs.overtimes): set a threshold at the desired maximum hours per driver, with steep extra costs above it. This caps the top end while the balancing preference lifts the bottom end.

The overloads-as-revenue trick — clever and correct. Using a "revenue" load dimension with overloads[].threshold set to the target revenue per driver is a creative and valid approach. Below the threshold, adding orders is "free" (no overload penalty); above it, the extraPerUnit cost kicks in, making the optimizer prefer to fill other vehicles first. This is a genuinely useful pattern that I didn't mention in my response — well played.
One nuance on insourcingRevenue: Your explanation is accurate, but I'd be careful positioning it as a workload-balancing tool. insourcingRevenue primarily controls the plan-or-not-plan decision — it makes optional orders worth scheduling only when the revenue justifies the added route cost. It doesn't directly steer which vehicle gets the order. For balancing across drivers, the overloads trick and routeDuration preferences are the more direct levers. insourcingRevenue is more relevant for the "is it worth adding this order at all" question.
Missing: routeDurationBalancing / routeDuration.importance. You mention preferences.routeDuration (preferredDuration) but don't highlight the importance parameter (0–1 scale), which is the most direct built-in mechanism for equalizing route durations across the fleet. It's worth calling out explicitly — it's the simplest lever for "fair balance" and doesn't require any load-dimension workarounds.
Missing: costs.unused. You mention it in passing at the top but don't integrate it into the balancing strategy. A high unused vehicle cost is one of the most straightforward ways to force the optimizer to activate all drivers rather than concentrating work on fewer vehicles. It pairs naturally with the overloads approach.