How Zendera plans your day

Zendera plans your transport operation automatically. As orders come in, the optimizer assigns each stop to a driver and decides the order of stops on every route — continuously, all day long. You don’t have to drag-and-drop a plan together each morning.

This article explains what the optimizer takes into account, what it tries to minimise, and when (and how) you should step in manually.

Why auto-optimization

Manually building a plan for 50, 100, or 500 stops takes hours, falls apart the moment a new order comes in, and rarely produces the cheapest route. An optimizer does the same job in seconds and keeps doing it as the day changes — when a new order arrives, when a driver runs late, when a customer cancels. Your team focuses on the exceptions instead of the plan.

With just 10 delivery stops, there are over 3 million possible route combinations. With 20 stops, over 2 quintillion. Zendera’s optimization engine solves these complex puzzles in seconds, finding results within a few percent of mathematical perfection — considering hundreds of factors at once, something no human planner could do manually.

Dynamic optimization vs. conventional “click to optimize”

Most TMS products on the market today work like this: a planner gathers the day’s orders, presses a big Optimize button, and the system returns a single static plan. After that, the plan is frozen — every change after the click is handled manually. If a new order arrives at 10:00, the planner has to either squeeze it in by hand or re-run the whole optimization (and accept whatever new plan comes out, even if half their drivers are already on the road).

Zendera works differently. The optimizer runs continuously in the background, all day, and reacts to every change as it happens — usually in seconds.

The practical effect: with a conventional system you spend the day defending a plan that’s already wrong. With Zendera the plan stays right by itself, and you spend the day on the things only a human can do.

What the optimizer uses as input

The plan is only as good as the data behind it. Zendera looks at:

Orders

• Pickup and delivery locations (addresses).
• Time windows — see Time windows below.
• Service time — how long the driver needs at the stop.
• Products — total weight, volume, and pallet count.
• Required vehicle type (e.g. refrigerated, > 3.5t).
• Required driver skills (e.g. ADR, forklift). ADR is the European standard for moving dangerous goods such as fuel or chemicals.

Drivers and vehicles

• Workshifts — when each driver starts and ends.
• Skills — what each driver is qualified for.
• Capacity — vehicle weight, volume, pallet spaces, ADR points.
• Equipment — tail-lift, cooling, crane, etc.
• Costs — per hour, per km, fixed per use.

The road network

• Real driving distances and travel times (not straight-line).
• Time-of-day traffic — the optimizer uses different travel times for rush hour vs. off-peak, and structures routes accordingly. So short, close-together stops tend to be packed into rush hour, and longer drives are scheduled outside it.

What’s actually happening today

The plan also reacts to live signals from the day itself: where each driver is, which stops they’ve arrived at, which they’ve completed, and any updates from the office. That’s how the optimizer keeps the plan matched to reality instead of to the morning’s prediction.

What the optimizer respects (constraints)

Constraints are the rules the plan can’t break:

• Capacity. Total weight, volume, and pallet count on the vehicle never exceed its limits.
• Skills. A stop that needs ADR-qualified driving is only given to ADR-qualified drivers.
• Vehicle compatibility. A refrigerated order goes on a refrigerated vehicle. An order needing a tail-lift goes on a vehicle that has one.
• Workshift hours. A driver isn’t asked to start before their shift opens or to return after their absolute close time.
• Manual locks. Anything you’ve locked in Tune routes is treated as fixed.

If a stop can’t be planned (e.g. no eligible driver, every vehicle full), Zendera flags it instead of forcing it onto a route. You’ll see it under Orders on hold or Alerts in Order Overview.

Time windows: soft and hard

Time windows have three values, not two:

• Open time — the earliest the stop can be served. (Hard.)
• Late time — when the stop should be served by. (Soft — see below.)
• Close time — the absolute latest the stop can be served. (Hard.)

The late time is treated as a soft penalty: the optimizer prefers not to be late, and being late costs more the later you get. But if there’s no way to fit a stop before the late time — say, traffic is bad — the optimizer will still serve it, marking it as Late on the timeline rather than dropping it.

The close time is the hard wall. A stop that genuinely can’t be served before its close time won’t be put on the route at all.

This split is why a stop can show as Late (red) in Order Overview but still get delivered. Without the soft late time, a small traffic jam would cause the stop to drop out of the plan entirely — clearly the wrong behaviour.

What the optimizer minimises (cost)

Within the constraints above, the optimizer chooses the cheapest feasible plan based on the costs you’ve configured:

• Driver cost — typically per hour, with overtime rules.
• Vehicle cost — per kilometre and/or fixed per use.
• Lateness penalty — cost of being late, scaled so a lot of small late stops is preferred over one disastrously late one.
• Workload balancing — fuller routes carry a small penalty, so the optimizer spreads work across drivers instead of cramming one truck. This deliberately leaves capacity in reserve for orders that come in later in the day.
• Route shape penalties — stops far from the rest of the route, or routes that sprawl across a wide area, carry small penalties. The result is tighter, easier-to-drive routes.

You configure the basic cost values in Drivers, Vehicles, and Settings. The penalty values for lateness, balancing, and route shape come with sensible defaults. Beyond those defaults, the cost weightings can be tailored to your priorities and to specific operating scenarios — for example favouring punctuality over distance, or tightening route shape during peak season. This tuning is done in close cooperation with the Zendera team, so talk to us before changing it.

How re-planning works

Zendera re-plans continuously, not once a day. Whenever something changes — a new order arrives, a stop gets cancelled, a driver runs late — the optimizer reassesses the affected routes and updates them.

What stays fixed:

• Already-completed stops are never moved. History is fixed.
• Locked stops stay where you put them.
• Dispatched stops — every stop already sent to the driver’s mobile app — are locked in sequence and can’t be reordered. This holds for however many stops you’ve dispatched, whether that’s the next trip or the whole route. New stops are only ever planned in after the dispatched stops, never inserted between them. Everything not yet dispatched can still be re-sequenced.
• On-board deliveries stay on the vehicle that picked them up. Pending pickups can still move between drivers if a better fit comes up.

What’s fair game:

• Future, unassigned stops — re-sequenced or reassigned freely.
• Future, assigned-but-undispatched stops — also re-sequenced if it makes the plan better.

Appointment booking awareness

If your customers book delivery slots themselves (through a portal or by phone), the optimizer takes the current plan into account when offering slots — not just a flat hours-per-day quota. A slot is only offered (and only confirmed) if it actually fits without making the rest of the day worse. The result is fewer over-promises and a tighter match between what you sell and what you can deliver.

When to override the optimizer

Most days, you don’t. The optimizer is the primary planning tool — manual edits in Tune routes are the override layer, used in cases like:

• A specific customer always wants the same driver.
• You’ve promised an arrival time stricter than the order’s time window.
• A driver knows the area or the customer better.
• You’re testing a route change.

The cost of overriding is that the plan stops being globally optimal. If you lock too many stops, the optimizer has nothing left to work with. Use sparingly. See Tune routes for how.

What this means for new customers evaluating Zendera

If you’re considering Zendera, here’s what to take from this article:

• Setup quality matters. The optimizer’s output is only as good as your driver costs, vehicle capacities, skills, and customer time windows. Plan an onboarding effort to get this data clean.
• You don’t replace your dispatchers — you change what they do. They stop building plans and start handling exceptions, customer calls, and edge cases.
• It works with your ERP. Orders typically flow in from Dynamics, Visma, or another ERP via integration, so dispatchers don’t re-key data.
• You stay in control. Auto-planning is the default, but you can lock specific stops, freeze routes, or fully manually plan when business rules require it.

How data flows through the system

Typical issues and how to fix them

1. Jobs not planned

Why it happens:

• Time window too strict
• No matching vehicle capacity or skill
• No eligible driver available within the required workshift

Fix:

• Broaden the time window
• Confirm vehicle capacity, equipment, and driver skills
• Check workshifts cover the order’s time window

2. Unbalanced routes

Why it happens:

• Vehicles with different shift lengths
• Tight time windows limit flexibility

Fix:

• Align workshift start times
• Review vehicle capacities
• Enable workload balancing

3. Late deliveries

Why it happens:

• Service durations too short
• Late departures
• Traffic or GPS data not synced

Fix:

• Adjust service time estimates
• Add a small buffer between stops
• Verify the driver app updates ETAs live

4. Jobs jumping between routes

Why it happens:

• Continuous optimization reshuffles jobs on small data changes

Fix:

• Lock stops once dispatched in Tune routes
• Remember that dispatched stops are held fixed automatically

Where to go next

• Order Overview — see the optimizer’s output live.
• Tune routes — manually override the auto-plan when needed.
• Drivers and Vehicles — configure the costs and capacities the optimizer uses.
• Settings — global rules and feature flags.