Automating Delivery Routing: Windows and Contingencies

Where routing problems start

Problems usually start not with “bad couriers” but with growth. When you have 10–20 addresses a day, you can keep everything in your head and tweak routes by phone. When orders grow to 50–100, manual planning breaks: one change triggers a chain of delays, and the dispatcher spends the day putting out fires.

The first symptoms appear quickly. Vehicles leave underloaded, couriers return late, and some customers get “we’ll be there in an hour” instead of a clear time. Empty runs appear: a driver crosses half the city “because that’s how it’s always done” even though another address is nearby. Overtime, fuel, complaints and cancellations rise.

Most time is eaten by small repetitive tasks repeated dozens of times per shift: sorting orders by area, confirmation calls, finding “who should take this address,” rebuilding the plan after an urgent order, refusal or change. Typical example: a client moves delivery from 14:00 to 18:00 and the dispatcher manually restructures half the day to avoid breaking other windows.

Automation pays off fastest on tasks that don’t depend on one person’s “feel”: grouping orders by zones and clear rules (weight, volume, delivery type), calculating the sequence of stops with travel times, checking constraints (time windows, capacity, working hours), quick recalculation on changes and execution control (where the courier is and what will definitely be late).

When these basics are handled by calculations and rules, the dispatcher has time for complex cases instead of endless “puzzle reassembly.”

What data is needed for automation to work

Automatic routing doesn’t start with choosing a “smart” algorithm but with clear, clean data. If an order has a wrong entrance or a weight “by eye,” the system will build a nice-looking but unworkable plan.

At minimum, each order needs a small but accurate set of fields: address in one format (street, house, building, entrance, comment), weight and volume (or at least categories), priority (urgent, standard, can be moved), contact and delivery method (door, pickup point, checkpoint), and a delivery window or preferred time.

Next are performer data. It’s important to know not only “who’s working today” but real constraints: shift, vehicle type, capacity, start location, zones, skills (e.g., carry-up delivery, document handling, access to secure facilities).

The third layer is road and warehouse constraints. Even simple things change the plan a lot: loading time, truck access restrictions, toll roads, parking and stair/climb time. If you ignore these, the schedule will start to slide after the first two stops.

Catch data errors before calculation. A practical approach: spend 5–10 minutes checking “red flags” like empty house number, a delivery window shorter than 15 minutes, weight 0, address without a city.

Example: an order lists “Abay Ave, 15” without a building. The courier arrives at a business center while the actual pickup is in an adjacent courtyard with a different entrance. Losing 20 minutes breaks the chain of windows. Data quality almost always matters more than a complex algorithm: with accurate input even simple rules give stable results.

Bundling orders cleanly

Bundling is grouping requests into clear batches so routes can be built faster and without on-the-road manual merging. The algorithm works better when orders sit in logical batches rather than one long list.

A good rule: a bundle is what a single vehicle can realistically deliver in one run without violating time or cargo rules. Start with proximity and cargo constraints, then refine by priorities.

In most operations simple criteria are enough: neighborhood or cluster (roughly 5–15 minutes between points), weight and volume (to avoid overloading the vehicle), product type (fragile, oversized, returns), client priority (penalties for lateness), and delivery type (to door, to pickup point, carry-up).

There are cases when you must not combine nearby orders: different storage conditions (refrigerated and dry), incompatible goods (strong-smelling chemicals and food), different vehicle requirements (car vs van). A common trap is making an ideal geographic bundle but ignoring that the warehouse cannot prepare some orders in time.

So consider not only travel time but also “time to start”: picking, checking, packing, waiting at the ramp. Practical order: cluster by geography, then filter by cargo and warehouse constraints, and only then build the route. If two orders are in the same courtyard but one needs 40 minutes to prepare while the other is ready now, it’s often better to separate them than make the courier wait and break other deliveries.

How to account for time windows without breaking the schedule

A delivery window isn’t just “10:00–12:00.” In planning it’s important to distinguish two types. A hard window is when the client or site accepts only within a strict interval (e.g., a warehouse with checkpoint). A soft window is a preferred time when a small shift is acceptable with notice.

The main mistake is promising a window without checking if it’s physically achievable. The system must count not only travel time but the real “cost of a stop.” Build buffers for what almost always happens on site: approach and finding the entrance, parking and passing security, carrying up to a floor and waiting for the client, checking goods, signatures, payment, returning to the vehicle and departing.

Even 5–7 minutes per stop adds up to an hour and that hour breaks the schedule.

Set priorities as rules, not “by feel.” Practical logic: satisfy hard windows first, then fixed constraints (temperature, dimensions, required driver), and only then optimize vehicle load and mileage. If a vehicle is “ideally full” but misses two hard windows, the plan is bad.

Example: you have 12 addresses, two are a clinic (strict 11:00–11:30) and an office with checkpoints (strict 16:00–16:30). Build the route around these anchors and place other stops between them with buffers.

For clients who often reschedule, discipline helps: confirm the window a few hours before dispatch, set clear limits on reschedules, move to a soft window or an appointment slot “by agreement,” and pre-agree an alternative delivery address or pickup point.

Step by step: setting up automatic routing

So routing doesn’t become a black box, start with basics: make sure the system actually understands where to go. The problem is often data, not algorithms.

First, normalize addresses and geocode them. Then spot-check coordinates on a map: at least the 20–30 most frequent points. If a warehouse, business center or new residential complex falls on the neighboring street, travel-time calculations will lie.

Next set realistic constraints. The algorithm should know courier shifts, capacity, service zones, order types (oversize, fragile), and immovable rules: client requirements, checkpoint access, opening hours.

After that configure bundling rules and priorities. For example: combine orders from one neighborhood but don’t mix refrigerated and regular; prioritize urgent orders but don’t violate others’ windows.

Practical workflow:

• Normalize addresses and verify coordinates.
• Enter courier, zone and capacity constraints.
• Define bundling rules and priorities.
• Build draft routes and review them visually.
• Add time buffers and mandatory stops.

A sanity check is mandatory. If a courier from the center suddenly drives to the suburbs and back twice, zones or priorities are missing. Then add buffers (e.g., +10 minutes for parking) and mandatory tasks (document pickup, return of packaging).

Finally approve the plan and assign tasks so each courier has a clear route and stop order. In practice the dispatcher reviews a draft, adjusts 1–2 disputed points and then sends assignments.

Contingency plan: what to prepare in advance

Contingencies happen daily: traffic jams, vehicle breakdowns, client not answering, address changes or cancellations, returns. Without a pre-defined plan B any automation quickly turns into manual firefighting.

A good plan starts with simple rules understood by couriers, dispatchers and support. And don’t try to save every delivery at any cost: sometimes it’s cheaper and more honest to reschedule or cancel.

What should be in plan B

Document in advance what the team does in each typical case:

• Backup: who substitutes the courier (standby driver, driver from a neighboring zone, partner) and how many minutes to confirm readiness.
• Alternate routes: acceptable detours and zone boundaries so a courier doesn’t drive too far and break later stops.
• Window shifts: how many minutes a window can move without client confirmation and when confirmation is required.
• Reallocation: which orders can be passed to another courier (e.g., non-cash, no temperature control, non-fragile).
• Returns and refusals: where to take returns and when to close an order as “not delivered.”

How to avoid chaos during reallocation

Keep a single place to record decisions: who accepted it, who was reassigned, the new window and the reason. Example: a courier breaks down on stop 3 of 12. The system suggests transferring the 4 nearest orders to the backup courier and postponing the rest to the evening with agreement. The key is that rules trigger the same way every time.

Also assess the load on the hotline. In bad weather calls increase, so prepare short message templates, operator scripts and clear limits after which the system automatically offers a window shift or cancellation with status.

Quality control and tuning rules based on reality

Launching routing is not the end. To actually save time and reduce lateness you need daily numbers and clear actions when indicators slip.

Each day monitor a small set of metrics: delays (how many orders arrived after the window and by how many minutes), mileage (per courier and per shift), idle time (at warehouse, at point, in traffic if tracked), first-attempt delivery rate, and the share of manual dispatcher edits (the higher, the worse the logic).

For each route measure deviation from the plan: did it start on time, where did the schedule start to erode, and how much does the actual sequence differ from the calculated one. Tag reasons consistently: “long warehouse pickup,” “client not present,” “address error,” “overweight,” “window breach.”

Bottlenecks usually hide not in the algorithm but in a concrete spot: one warehouse, one city zone, a specific shift or several couriers. If delays pile up in one area after 16:00, bundling rules may be too “greedy” and ignore evening traffic.

Review bundling rules and windows on a schedule: small tweaks weekly, larger changes monthly or when tariffs, delivery zones or fleet composition change. Record changes in writing: what changed, why and from which date. Add a simple compliance check (for example, forbid manual bundling without a reason).

Integrations and making dispatchers work with less effort

Routing often fails at the interfaces: an order arrives from the accounting system with a wrong address, the driver doesn’t update status, the client doesn’t receive a notification. Build integrations so data flows back and forth without manual copy-paste.

Import orders automatically from ERP/CRM and return execution statuses: “departed,” “on site,” “delivered,” “refused,” “rescheduled.” Then accounting, warehouse and call center see the same picture and the dispatcher doesn’t spend the evening compiling reports.

A single client and address directory is critical. Otherwise “Abay St 10,” “Abaya, 10” and “ABAY 10” become three points on the map and routes lengthen. Simple rule: create the address once and then always select it from the directory with suggestions and checks for city, entrance and contact.

Customer notifications are best tied to statuses and windows: window confirmation, arrival notice, reschedule. If a driver reports “15-minute delay,” the client receives an updated time and the dispatcher only sees a task if the delay breaches the window.

The dispatcher’s role is to handle exceptions, not to “draw” routes. Manual tasks usually remain: rescheduling at the client’s request, replacing a driver or vehicle, splitting or combining disputed orders, correcting an address after a call.

To prevent accidental rule changes, set access rights: who can edit directories, who can change bundling rules and windows, and who can only edit individual orders.

Example scenario: one day of city deliveries

Morning, 08:30. You have 60 orders and 6 couriers. Two hard windows exist: some clients accept only 10:00–12:00, others only 18:00–20:00. The rest are flexible. The city is roughly divided into 4 districts and orders vary by weight from small packages to heavy boxes.

The system groups orders to avoid couriers crisscrossing the city: about 8–12 addresses per district, considering weight and vehicle type: light packages go to bike or car, heavy boxes to drivers with cargo capacity. A couple of border addresses go to the side with less expected traffic at that time.

Next windows are considered. 10:00–12:00 orders are distributed so each courier has no more than 3–4 such stops and can meet them without rushing. Buffers are added between stops: e.g., +10 minutes for parking and carry-up, +15 minutes for unforeseen delays in each district. This reduces risk of lateness and cuts calls.

At 11:10 one courier reports they’re out of the shift (vehicle breakdown). The plan must update in 5–10 minutes or daytime and evening windows will fall apart.

The dispatcher marks the courier unavailable and the system reclaims their remaining stops. Orders with the hard 18:00–20:00 window are reassigned first, then the rest. Two nearest couriers get 2–3 addresses each; one is given only light orders so they don’t overload time. Affected customers receive a notification with a new expected time and couriers get updated routes. The dispatcher watches where lateness risk grows and manually adds an extra buffer or moves 1–2 flexible deliveries to the next day.

Key point: recalculation must update estimated arrival times, not just shuffle addresses. Then you can see in advance which windows are at risk and warn clients and the team without panic.

Common mistakes when automating routes

A common failure scenario is when automation turns into a set of manual edits. The system builds a route and the dispatcher keeps “fixing” it in chat and mentally. You end up with a process that’s just another place for mistakes.

Typical painful issues:

• Too many exceptions without rules. If “this client is always first” isn’t codified, new staff will do it randomly.
• Not accounting for loading and unloading time. On the map everything looks tidy, but the courier misses time because of warehouse queues, checkpoint procedures or carrying up to floors.
• Windows placed back-to-back without buffers or confirmation. A client says “14:00–15:00” but realistically can accept only after 14:30.
• Using the same settings for all orders. A parcel, heavy appliance and documents need different time, vehicle and priority templates.
• No plan B. Any breakdown, traffic jam or cancellation becomes an emergency.

Simple example: a courier gets 18 stops and two hard windows in a row. One client delays acceptance by 20 minutes and the chain reaction begins: delays, calls, SLA breaches. The cure is rules, not heroics: buffer in windows, accounting for service time at points, different templates by order type and pre-made scenarios for route rebuilding.

If calculations run on your hardware, system availability is critical. The dispatcher must be able to recalculate even if external services fail.

Short checklist before launch and daily

Before enabling automatic routing, run a basic check. It takes less than an hour but saves days of complaint handling and manual fixes.

Before launch make sure the calculation base doesn’t fall apart on small things:

• Customer addresses and contacts verified: city, entrance, intercom, phone.
• Vehicles have real constraints: capacity, type (van, car), shift schedule, service zones.
• Bundling rules are clear: what can combine, what never goes in one vehicle, which orders get window priority.
• There is a short action plan for failures: who decides in case of traffic, breakdown or cancellation and how fast the route changes.
• A person is responsible for adjustments and metrics: percentage of on-window deliveries, delays, share of manual changes.

Also check infrastructure. The dispatcher needs a stable workstation and access to orders, and the system must handle the morning recalculation peak.

Daily routine is simpler but regular:

• Morning: new orders, cancellations and window changes confirmed.
• Before dispatch: couriers and vehicle readiness confirmed.
• During the day: follow the “one reason — one action” rule for failures (reschedule, reassign, return to warehouse).
• Evening: review 3–5 most common failure reasons and tweak rules.
• Weekly: check zones, shifts and constraints so the model stays current.

Next steps: how to roll out without overloading the team

Rollout is easier in small steps. If you switch the whole city and all order types to new rules at once, dispatchers will retrain on the fly, couriers will argue routes and you won’t know what broke. Start with a pilot: one zone, one warehouse or one order type (for example, B2C only).

The first 1–2 weeks of the pilot matter more than any presentations. Collect facts: how many delays, mileage per order, where and why failures occurred (traffic, closed yards, wrong address, slow customer service). If 18:00–20:00 windows fail not because of routing but because the warehouse hands out orders between 17:30 and 18:15, fix the picking process, not the routing.

Then formalize rules and train the team. Training should be short and practical: how to handle exceptions, when manual reordering is allowed, how to report problems so they appear in analytics.

First month plan:

• Week 1: pilot in one zone with minimal rules.
• Week 2: collect failure reasons and correct data (addresses, times, constraints).
• Week 3: finalize rules and short instructions for dispatchers and couriers.
• Week 4: expand the pilot and monitor metrics (delays, mileage, overtime).

If you host routing and monitoring yourself, evaluate in advance whether the infrastructure will handle recalculation peaks and how support and redundancy are organized. System integrators often help in these projects: for example, GSE.kz supplies workstations and servers and provides 24/7 support, which is convenient for dispatch centers and critical services.