What does last mile delivery optimization actually change?

It changes how the day is assembled. Instead of a dispatcher sequencing addresses by hand in the order they arrived, an engine assigns orders to field employees and orders the stops so that time windows, capacity and working hours are all respected. The visible results are fewer kilometres between stops, a more even workload across the team, and more completed jobs inside the same paid shift.

How is this different from a navigation app?

A navigation app answers how to drive from A to B. Optimization answers a larger question: which employee should take which orders, and in what sequence, given windows, capacity, skills and service times. Navigation optimizes one leg; routing optimizes the whole day across the whole team. In practice you need both — the plan comes from the routing engine, the driving directions from the map.

Do narrow delivery windows make optimization impossible?

Not impossible, but expensive. Every constraint removes options from the solver, and a day where every order is rigid leaves almost nothing to optimize. The practical approach is a mix: offer narrow windows as a paid, deliberately limited product, keep a share of flexible stops that the engine can move around the rigid ones, and measure adherence to windows rather than only completion.

What data do we need before automated planning is worth it?

Three things: addresses that resolve to correct coordinates, a realistic service time for each type of job, and the constraints you currently keep in your head — windows, vehicle capacity, skills, districts. A solver applied to guessed inputs produces a confident plan that fails by noon, so the data work comes first and largely determines how good the result can be.

How long does it take to move from spreadsheets to automated routes?

Less than most teams expect, if it is done in stages. itlogist is built for a launch in 7 days and works without long-term contracts, and it exchanges data with 1C, AmoCRM, Bitrix24 and Excel, so orders keep arriving from the systems you already use. The usual pattern is a two-week pilot on one district or team, compared against a baseline measured beforehand.

Last mile delivery optimization: a practical guide

Last mile delivery optimization is the work of turning a list of addresses into a plan that a real team can actually finish on a real day — with traffic, time windows, lunch breaks and a customer who is not home. It is the most expensive leg of the whole chain and the only one the end customer ever sees. This article looks at where the money in that leg is really spent, what an optimization engine does and does not solve, and how to move from a manually assembled plan to an automated one without stopping operations for six months.

Why the last mile is the expensive part

Moving a pallet across a country is a solved problem: large volumes, few stops, predictable schedules, cost spread over many units. The final leg reverses every one of those properties. Each parcel goes to a different door, each door takes a few minutes of a person's time, and the cost of that time is divided by one order instead of a thousand.

Three structural facts make this leg behave differently from everything upstream:

The cost is per stop, not per kilometre. Two addresses in the same building cost almost nothing extra; two addresses on opposite sides of a city cost an hour. Distance matters, but the sequence of stops matters more.
Capacity is people, and people are inelastic. A shift has a fixed number of working hours. You cannot add ten percent more hours at five in the afternoon, so a plan that overruns simply turns into failed visits.
It is the only leg the customer experiences. Warehouse throughput is invisible; a missed two-hour window is not. Service quality on this leg drives repeat orders in a way no other stage does.

That combination is why small planning improvements pay back quickly here. Cutting the idle time between stops does not just save fuel — it puts more completed jobs into the same paid shift, which is the number the finance team actually cares about.

Where the losses actually hide

Before buying an engine, it is worth finding out what the current day loses. In most teams the leaks are not exotic; they are the same four, and they compound.

An unbalanced plan. One courier finishes at two in the afternoon while another is still working at eight. The imbalance is invisible on a whiteboard and obvious in the completion timestamps.
Backtracking. Manually built sequences tend to zigzag across a district because the planner assembled them in the order the orders arrived, not in the order the streets allow.
The plan and the day diverge. A morning plan is a hypothesis. New urgent orders, a breakdown, a client who reschedules — by noon the paper version describes a day that no longer exists, and nobody re-plans because re-planning by hand takes an hour.
Failed visits. The most expensive line of all: the courier drove, waited, and returned with the parcel. The trip is paid twice and the customer is unhappy once.

These leaks share a cause. The planner is solving, by hand and under time pressure, a problem whose number of possible answers grows faster than anyone can evaluate. Twenty stops can be arranged in more sequences than there are seconds in the age of the universe; a person picks a plausible one and moves on. Plausible is usually far from good, and nobody ever finds out by how much, because there is nothing to compare against.

What an optimization engine actually solves

The formal name for this task is the vehicle routing problem: given a set of addresses, a set of vehicles or field employees, and a set of constraints, find the assignment and the sequence that complete the work at the lowest cost. It is a well-studied problem with mature solvers, and modern planning tools are built on those solvers rather than on hand-written heuristics.

What matters in practice is that the engine optimizes against your constraints, not against a textbook. A usable plan has to respect the things a dispatcher currently holds in their head:

Time windows. The interval agreed with the customer, and the working hours of the shift.
Capacity. What fits in the vehicle, and how many jobs a person can realistically close in a day.
Assignment rules. Skills, equipment, districts, the client who insists on the same technician every time.
Service time at the stop. A handover at a door and an installation are not the same event, and a plan that treats them alike will overrun before noon.

In itlogist the routing engine is built on OR-Tools and takes delivery windows and constraints into account when it builds the plan, alongside the operational parts of the day — order intake and dispatch to field employees, live routes on a map, and on-site confirmation that the job was done. If you want the full picture of how the pieces fit together, see Routing in itlogist.

What the engine does not solve is data. If service times are guessed, addresses are unverified and half the orders arrive by phone at eleven in the morning, an optimal plan built on that input will still fall apart — it will simply fall apart in a more organized way.

Time windows: the constraint that decides the plan

Nothing shapes a route as strongly as the promise made to the customer. A wide window gives the planner freedom to group stops geographically; a narrow one forces the sequence and can push a courier across town twice in one afternoon. This is the lever most teams tune last and should tune first.

A few practical rules follow from how solvers treat windows:

Narrow windows are a paid product, not a default. Every hour you shave off the promise costs vehicle time somewhere. Offer precision where customers value it and charge for it, rather than promising it everywhere and missing it.
Windows should be offered against a real plan. A slot the system knows is reachable is worth more than a slot an operator invented to close a call.
Mixed windows beat uniform ones. A day where some stops are flexible gives the engine room to absorb the rigid ones. If everything is urgent, nothing can be optimized.
Measure adherence, not just completion. An order delivered outside its window is a completed job and a broken promise at the same time, and only one of those shows up in a completion rate.

The second half of the promise is telling the customer where things stand. A customer portal with live statuses removes most of the calls that ask nothing but when — and those calls are what pull a dispatcher away from the work of actually managing the day.

The shift after the plan: control, exceptions, confirmation

A plan is an assumption about the next eight hours. Optimization pays off only if the assumption is monitored and corrected, which is why the planning screen and the execution screen have to be the same system. Three capabilities carry that load.

Live routes on a map. The dispatcher sees where each field employee is against the plan and notices a delay while there is still time to react — move the last two stops to a colleague, warn the customer, reschedule deliberately instead of failing silently.
Statuses updated as the work goes. The courier changes the state of each order at the stop, so the office is never reconstructing the day from a phone call.
Confirmation at the door. Photo reports and checklists in the mobile interface close the job with evidence attached to the order. In itlogist the field employee works through a mobile web interface without a mandatory app install, which matters when part of the fleet is temporary staff or subcontractors.

Exceptions deserve the same discipline as successes. A visit that ends without a handover still consumed an hour of a paid shift, and if the reason is recorded from a fixed list rather than described in free text, a month of those records tells you which districts, clients or slots generate the failures. That is the feedback loop that makes the next plan better: the engine optimizes the sequence, the exception data fixes the inputs.

How to start without a six-month project

Optimization projects stall for organizational reasons far more often than technical ones. A staged approach avoids the usual trap of rebuilding everything at once.

Fix the address data first. Nothing degrades a plan faster than coordinates that point to the wrong courtyard. This is unglamorous work and it determines the ceiling of everything above it.
Measure the current day honestly. Stops completed per shift, time between stops, share of failed visits, share of orders delivered inside their window. Without a baseline you cannot tell whether the new plan is better or merely different.
Estimate service time by job type. Ask couriers, then check against real timestamps. Solvers are only as good as this number.
Connect the order sources. itlogist exchanges data with 1C, AmoCRM, Bitrix24 and Excel, so orders arrive from the systems you already run instead of being retyped into a new one.
Pilot on one group. Run automated planning for a single district or team for two weeks against the baseline. itlogist is designed for a launch in 7 days, works without long-term contracts and fits teams of 5 to 100 field employees, so a pilot is a fortnight of attention rather than a quarter.
Review weekly at first. Look at what the dispatcher overrode by hand. Every manual correction is either a missing constraint in the model or a habit worth retiring — and both are useful to know.

Done in this order, optimization stops being a software purchase and becomes what it should be: a shorter gap between stops, a promise the customer can rely on, and a shift that ends when it was planned to end.

Last mile delivery optimization: how to plan a day that holds