Choosing an objective¶

~5 min read · Recipes

The objective is the only field that changes what the engine considers a good answer. Everything else in the payload describes what is possible — vehicles, windows, capacities, skills. The objective decides which of the many possible plans you get back.

{ "problem": { "fleet": [ … ], "jobs": [ … ], "objective": 1 } }

There is no universally best choice. Each objective buys one outcome by spending another, and the right one depends on what your business actually pays for: a truck, an hour, a kilometre, or a driver who won't quit.

1 — Minimize total travel time¶

The default. Produces the plan with the least total time on the road across the whole fleet.

Choose it when driving time is your dominant cost, or when you have no strong opinion — it's the sensible starting point and the baseline every other objective should be compared against.

• What you gain: the lowest statistics.times.totalHours, and usually tight, sensible-looking routes.
• What you spend: it will happily use another vehicle if that shortens total driving. Expect more routes than objective 2 on the same problem.
• Note: least time is not least distance. A longer motorway leg often beats a shorter urban one. If you're billed per kilometre rather than per hour, that difference is real money.

2 — Minimize number of routes¶

Packs the work into as few vehicles as possible. The plan uses the smallest fleet that can still serve the jobs.

Choose it when a vehicle is the expensive unit — you're deciding how many trucks to run tomorrow, sizing a fleet, or paying per vehicle per day.

• What you gain: the lowest statistics.vehicles.used.
• What you spend: distance and time go up — a tightly packed fleet drives further. The last routes filled tend to be the least tidy.
• Watch for: more work landing in unassigned. Squeezing into fewer vehicles makes tight time windows harder to satisfy, so read the unassigned list before concluding you can run the smaller fleet.

3 — Balance workload¶

Spreads the work evenly across the routes rather than making any single route as efficient as possible.

Choose it when the fairness of the day matters: drivers comparing their runs, shift-length rules, or a depot where one person finishing at 15:00 and another at 19:00 is a problem regardless of the totals.

• What you gain: routes of similar size — compare stop counts across routes[], and the spread of each vehicle's last eta.
• What you spend: total efficiency. Balancing directly opposes consolidation: evening out the work means not filling the best route first, so both total time and vehicle count are usually worse than objectives 1 and 2.
• Note: balance here is about the shape of the work across routes. It isn't a guarantee about hours, and it doesn't override capacities, windows, or skills — those remain hard constraints.

How to actually decide¶

Don't reason about it — measure it. The objective is one integer, so the comparison is cheap:

1. Submit the same problem three times, changing only objective.
2. Set configuration.statistics and configuration.unassignedTasks to true on all three.
3. Compare four numbers: vehicles.used, times.totalHours, distance.totalDistance, and the length of unassigned.

That table is the trade-off, in your own data. It's a far better basis for the choice than any description on this page — including this one.

Custom strategies¶

objective also accepts a string — the name of a strategy configured for your account. Custom strategies go beyond these built-ins: they can rank several goals in order, and encode preferences specific to your operation. They're set up by DDS Wireless with you rather than being self-serve. If none of the built-ins expresses how you actually schedule, that conversation is the next step.

Related: Enums, limits and rules · The Solution object · Capacities and demand