How to Plan Delivery Routes With AI in a Small Business

The useful way to plan delivery routes with AI is to stop asking a chat model to do the optimisation. It is very good at turning your messy constraints into structured data, explaining a route to a driver, and handling the exceptions that break a plan at ten in the morning. It is not good at ordering twenty stops, and it will be confidently wrong in a way that costs you fuel and a missed window.

That split is the whole article. The rest is where each half goes.

What a chat model cannot do here

Route ordering is a travelling salesman problem with time windows, and it is a genuinely hard optimisation. A language model does not compute it, it produces a plausible-looking ordering. For five stops in a small town, plausible and optimal are usually the same thing and nobody notices. For twenty stops across a city with delivery windows, they diverge sharply, and the failure is quiet: you get a route that looks sensible, reads well, and is thirty minutes and eleven kilometres worse than it should be.

Two things it also gets wrong that matter in practice. It does not know current road conditions, closures or traffic unless something feeds it that data. And it will accept an impossible set of time windows without objection, producing a schedule that cannot be met, because saying yes is the more probable response.

Real routing engines exist, most of them are cheap or free at small-fleet volumes, and they solve this properly. A simple sequence of stops through a mapping provider's route optimisation, or a purpose-built route planning app, will beat any prompt.

Where AI genuinely earns its keep

The optimisation is maybe twenty percent of the work. The other eighty is gathering, cleaning and communicating, and that is where the time actually goes in a small business.

Step one: get the stops into a table

Most small operations do not have clean delivery data. They have an inbox. This is the part worth automating first, because it is the part that takes an hour every morning.

Below are today's delivery requests, copied from email and text.

Return a CSV with these columns and nothing else:
customer, full_address, postcode, phone, earliest_time,
latest_time, notes, flags

Rules:
- Leave earliest_time and latest_time blank if no window was given.
  Do not invent one.
- Put access instructions, parking notes and anything about
  who to ask for into notes, in the customer's own words.
- In flags, write ADDRESS_INCOMPLETE if the address is missing a
  street number or postcode, and TIME_CONFLICT if the window given
  is impossible or contradictory. Otherwise leave blank.
- Do not correct or guess at an address. Flag it instead.

<requests>
...
</requests>

The two rules that matter are the last two. A model asked to tidy addresses will happily invent a plausible house number, and you will find out when a driver is standing outside the wrong building. Making it flag rather than fix turns a silent failure into a two minute phone call. This is the same shape as prompting AI to extract data from a document: constrain the output, forbid invention, and make uncertainty visible.

Step two: let a solver order them

Feed the cleaned table to something that actually optimises. Google's Routes API does waypoint optimisation, most dedicated route planning apps for small fleets do it in the interface, and at under about twenty-five stops a day the free tiers generally cover it.

Two constraints worth setting properly rather than accepting defaults. Service time per stop, meaning how long the driver is actually out of the van, because leaving it at zero makes every estimate optimistic by an hour across a full day. And vehicle start and end locations, which are often not the same place, and which change the optimal order more than people expect.

Step three: write the run sheet

This is where the model goes back to work. A solved route is a list of coordinates and times, which is not what a driver needs at seven in the morning.

Turn this optimised route into a driver run sheet.

For each stop, one block:
- stop number, customer name, full address
- arrival window
- access notes, verbatim from the notes column
- anything in flags, in capitals at the top of the block

At the end, list the three stops with the tightest time windows
and the total number of stops. Keep the whole thing under one
page. Plain text, no formatting beyond line breaks.

Verbatim is deliberate. Summarised access notes lose the specific detail that makes them useful, and the difference between the gate code is on the intercom and check the intercom is the difference between a delivery and a redelivery.

Step four: the exceptions

A route survives until the first failed delivery, and then someone has to decide what to do while driving. This is the strongest AI use case in the whole process and it is the one nobody sets up.

Give the model the remaining stops, the current time and the current location, and ask for the two or three realistic options with their consequences. Not the answer, the options. Whether to attempt a redelivery at the end of the run, whether the next window is now unreachable, which customer should get a call. A dispatcher does this in their head. If your dispatcher is also the person driving, they are doing it badly, at a junction, and a straight comparison of options helps more than an instruction would.

What this is worth

For a small operation running ten to thirty stops a day, the solver saves fuel and time on the order, and the AI half saves the hour of morning data entry and most of the phone calls caused by unclear addresses. The second one is usually the bigger number, and it is the one people do not count. If you want to check whether it is worth setting up at all, run the numbers the way measuring AI return for a small business suggests: time the morning task for a week first, then compare.

Delivery routing sits alongside the other scheduling problems a small operator has, and the same constraint-gathering pattern applies to scheduling staff shifts with AI. For the wider picture of where automation pays off first, start with AI for small business.

Frequently asked questions

Can I just ask ChatGPT to order my stops?

For under about six stops in a compact area, it will usually give you something reasonable and the cost of being slightly wrong is small. Beyond that the gap between its answer and the optimal one grows quickly, and because the output looks confident either way you will not be able to tell which you got.

Do I need a paid route planning app?

Not usually at small volumes. Mapping providers offer waypoint optimisation on free or very cheap tiers, and that covers most single-van operations. Paid apps start paying for themselves when you run several vehicles or need proof of delivery and live tracking.

How do I handle time windows that conflict?

Catch them at the data stage rather than the routing stage. That is what the TIME_CONFLICT flag in the first prompt is for. Resolving an impossible window with a phone call at eight in the morning is cheap. Discovering it at two in the afternoon is not.

Will AI know about roadworks on my route?

Not on its own. A language model has no live traffic data and will not tell you it is missing. Road conditions come from the mapping provider, which is another reason the solve belongs there rather than in a chat window.

What about deliveries that need a signature or a photo?

That is a proof of delivery feature and it belongs in whatever app the driver already uses, not in the planning step. Keep the run sheet as the plan and the app as the record, and do not try to make one do both.