Workflows by industry

How last-mile delivery teams plan around road works and closures

Roadworks and closures on a delivery route cost minutes at every stop after them. How last-mile teams check today's stops for incidents and reorder the day.

xMap Flows team · · 5 min read

Last-mile teams plan around road works by checking the day's stops, not just the depot, for closures and roadworks before routes are fixed, then ordering each route so that drivers avoid the affected streets or reach those stops at a better time. The check runs once when routes are planned and again during the day, and only new incidents near a stop are passed to the driver who will meet them.

This article is for route planners, delivery supervisors and operations managers at parcel, grocery, pharmacy and meal delivery companies. It looks at why incidents near stops matter more than incidents near the depot, how to read what the data gives you, a worked example in Bogota, and an AI employee that does the checking. For watching the roads at the depot gate itself, see the separate article on depots linked at the end.

Why the stops matter more than the depot

A closure at the depot affects the first ten minutes of every van. A closure in the middle of a delivery zone affects the stops on that street and every stop after them on the same route, because a driver who loses twenty minutes at stop six arrives late at stops seven to twenty. Last-mile work is a chain: one blocked street early in a route can push a whole afternoon past its delivery windows.

Roadworks are the most useful thing to plan around because they last. A burst water main closes a street for a morning; a resurfacing job can close a junction for a week. Once a team knows about it, it can move those stops to the end of the route, send them from another depot, or tell the customers on that street that their window has changed.

What the incident data gives you

The Traffic incidents block reads closures, roadworks and other incidents live from online maps. Set to look around each incoming place, it gives every stop two fields:

  • incidents_nearby: how many incidents are within the distance you set, from 100 m upward.
  • nearest_incident: the closest one, with its kind and how far it is, such as "Roadworks, 240 m".

Searched over an area instead, it lists each incident with its kind (road closure, roadworks or incident), its street and district, and a position good to about 150 metres. Accidents are reported as road closures for now. It does not say how long an incident will last, so a team learns that from seeing it on successive days.

A worked example: grocery delivery in Bogota

Here is a made-up case. A grocery delivery company plans tomorrow's routes in Bogota at 20:00 from the orders in its system. Before the plan is sent to drivers, a flow checks each stop for incidents within 300 m.

On a typical evening, most stops come back with nothing. A handful show roadworks on two streets in one neighbourhood. The planner moves those stops to the end of the route, so the van reaches them once the rest of the route is done, and the customers on those streets get a message that their slot moved by half an hour. At 06:30 the next morning the same check runs again; one new road closure has appeared near three stops, and the driver for that route gets a short message before leaving.

Mistakes that make planners ignore the alerts

  • Alerting on everything. Sending every incident in the city to every driver teaches them to stop reading. Send each driver only what is near their own stops.
  • Sending the same incident again. A roadworks site that lasts a week should be announced once. Only new remembers what was sent.
  • Checking only once. The evening plan cannot see the closure that appears at 07:00. A second check before departure catches it.
  • Expecting traffic volume. Incidents say where something is wrong, not how many cars are queuing. For how fast traffic is moving, add Traffic Flow, which gives live speeds and a jam factor, never car counts.
  • Reordering by hand for every route. Once a stop is flagged, let the route planner do the reordering, so the times and links stay right.

The AI employee that checks the stops

  1. Schedule: every day at 20:00, and again at 06:30.
  2. My data: tomorrow's stops, each with its address, position and route or driver.
  3. Traffic incidents: around each incoming place, within 300 m.
  4. Only new on the morning run: only incidents that appeared since the evening check.
  5. Route planner: one route per driver, from the depot, so flagged stops can be placed later in the day.
  6. Email to the planner with the flagged stops, or a message to each driver's group with their own.

What lands in the evening is a short list: the stops with something nearby, what it is and how far. In the morning, most drivers hear nothing; the few with a new closure on their route get one message naming the street. Templates that start close to this: Incidents near my drivers' zones, Road closures near my depots, every hour and Weekly road disruption report. More on the logistics and delivery page.

Questions

Can the flow reroute around a closed street?

Route planner puts the stops in the best order and gives directions links for each part of the route. It does not know about a closure on its own, so the flow flags those stops and the planner, or a rule, decides where they go in the day.

How close should a stop be to count?

For deliveries on foot from a parked van, 200 to 300 m works well. For larger vehicles that need a clear approach road, 500 m to 1 km.

Does it tell me when roadworks end?

No end time comes with an incident. A site that stops appearing in the morning check has usually cleared; Only new will tell you if it comes back.

Can drivers get the alert on their phone?

Yes. Instead of Email, end the flow with a message to a chat app the drivers use, or to each driver's own group, with their stops only.

Templates that do this

Read next

More on workflows by industry · Every article · Templates

Put it to work

An AI employee in xMap Flows does this on live data, on its own timetable. Start from a template or describe it in plain words.