AI in Logistics for Small Delivery Firms: Routes, ETAs and Messages

Use a route-optimisation tool to sequence stops against time windows and service times, then let it send customers a delivery window the day before and a live ETA on the day. A language model helps around the edges: cleaning order lists, drafting message templates and summarising delivery exceptions. Never let it calculate an ETA.

The planning engine is classic optimisation software. Some vendors label it AI, but the label matters less than its three inputs: clean addresses, honest service times and sensible time windows. Fix those before paying for any tool, because a good optimiser fed bad inputs produces a confident, wrong route. The tutorial on AI route planning for small fleets explains how the optimising works; this one follows a single illustrative day from order list to proof of delivery.

Follow me on Instagram@sagnikteaches

Which jobs belong to the optimiser and which to a language model

Most of the confusion about "AI in logistics" comes from treating one tool as doing everything. In a small firm it is two or three different engines with different failure modes, so it helps to give each job to the right one.

Connect on LinkedInSagnik Bhattacharya

The principle behind the table: numbers come from systems, words come from the model. An ETA built from a driver's live location and the remaining stops is a calculation; an ETA typed by a chatbot is a guess dressed as one. Keep the model away from anything a customer could later quote back as a promise.

Subscribe on YouTube@sagnikteaches

The test case: three vans, 60 drops, one Tuesday

Take a small firm that supplies shops, offices and a few homes from one depot. Three vans leave at 08:00 with 60 drops between them. Twelve drops carry a hard window ("before 10:00", "reception shuts at 15:30"). Service times, measured from the previous fortnight's delivery records, are 6 minutes at a shop counter (20 stops), 9 at an office reception (16), 4 on a doorstep (18) and 14 for a two-person heavy drop (6), which adds up to 420 minutes across the day. Everything below is illustrative.

Last Tuesday the dispatcher split the list by area in 55 minutes and the drivers chose their own order. The same stops went through an optimiser afterwards.

The saving is 83 minutes of driving, about 11%, and the last van is back 45 minutes earlier. Put a price on driving time (assume $35 an hour for wages, fuel and wear) and 83 minutes is about $48 a day, or roughly $1,000 across 21 working days. Planning time falls by 40 minutes a day, 14 hours a month. Treat the $1,000 as the demo figure: drivers deviate, parking is never as planned, and a tool's forecast saving is never the whole of the real one. Count half until your own weeks of data say otherwise.

Cleaning the order list before the optimiser sees it

Orders reach a small firm as emails, texts, phone notes and spreadsheet rows, and the optimiser can only place stops it can geocode, which means turning an address into a point on a map. A language model is good at turning scruffy lines into tidy rows, provided you forbid guessing.

Turn each order line below into one row with these columns: order_ref, stop_name, address_line,
access_note, window_start, window_end, service_type (counter, reception, doorstep or heavy), flags, original.
Rules: never invent a street, number or time. If anything is missing or ambiguous, write NEEDS CHECK in flags
and say what is missing. If a line contains a pickup and a drop, make two rows. Copy the customer's wording
into original, unchanged.

ORDERS:
[paste the lines, with customer names replaced by order numbers]

Here is how five illustrative lines might come back, and what to fix in each:

After the rows are imported, the tool's own matching takes over. Open the map and look for lonely pins: a stop that sits 15 kilometres from every other stop is worth a second look, because the usual causes are a mistyped address or a street name that exists twice. Customers' names and phone numbers are personal data, so the prompt above uses order numbers; add the contact details back inside the routing tool, not the chatbot.

Service times and time windows: two inputs that sink a good plan

An optimiser trusts these two inputs completely. A default service time of two minutes per stop makes every route look achievable at 07:55 and impossible by 11:00, because real stops take longer, and the error compounds down the route.

Measure service times instead of guessing them. Export a fortnight of delivery records, take each stop's arrival and completion times, group them by stop type and use the median for each group (a single slow stop skews an average, not a median). In the test case that gave 6, 9, 4 and 14 minutes. Re-measure every quarter, and record a new stop type whenever a customer's drops keep running long, such as a building where the lift is shared with the tenants above.

Windows deserve the same discipline. A hard window costs efficiency because it pins a stop to a slot, so reserve them for customers who genuinely cannot receive outside one: a reception that closes, a shop that wants stock before opening. In the test case 12 of 60 stops (one in five) were hard; as a rule of thumb I would start there and treat a higher share as a reason to talk to customers, not to buy a better tool. Everything else gets a soft window, the optimiser's best effort.

One 1,260-stop month, priced on five tools

Sixty stops a day over 21 working days is 1,260 stops a month. That number matters because the tools price in different ways, and the same month costs differently under each. All prices below were read from the vendors' own pages in October 2026; confirm them before you decide.

Read the table by shape, not by headline price. Per-driver pricing (OptimoRoute) grows as you add vans and ignores how many stops they make; per-stop pricing (Routific, Spoke Dispatch) grows with volume and ignores the van count. A firm with three vans on 60 stops sits comfortably in either; a firm that spread the same 60 stops across six vans of ten stops each would see the per-driver bill double while the per-stop bill stayed put. Onfleet's entry point is well above a three-van budget, so it suits a later stage of growth. Spoke Dispatch also shows how fast names change in this market: the product was sold until late 2025 as Circuit for Teams, and some older guides still use that name.

Texts are the hidden line. Onfleet's own page gives an example rate of $0.013 per SMS segment. At three texts for each of 1,260 stops that is about $49 a month, but if you send only the on-the-way message by text and keep the rest to email or the tracking link, the bill drops to about $16. The rule I would use: email for what can wait, text for the one message that has to be seen in the moment.

Setting the window: planned arrival plus the error you actually have

A tool gives a planned arrival for each stop. The window you promise should be that time plus or minus the error your own deliveries show, not a number that sounds generous. To find it, compare last month's planned arrival with the actual completion time for every stop, then ask what share landed within 10, 20 and 30 minutes. Do it in a spreadsheet with a formula, not by asking a chatbot to do the arithmetic.

Say 400 deliveries give these results: 52% within 10 minutes, 81% within 20, 93% within 30 (illustrative). A window of plus or minus 20 minutes, a 40-minute window, will be met about four times in five; plus or minus 30 gets you nine in ten. Choose the narrowest window you can meet around 80% to 90% of the time, and say less on the day before, when the plan can still change. The promise the evening before is a two-hour block; the promise on the morning is the narrower one.

Here is how that played out on Van 2 in the test case, stop by stop (illustrative):

Now the day goes wrong in an ordinary way: the lift is out at stop 4 and the heavy drop takes 25 minutes instead of 14. That is 11 minutes lost, and every later arrival slides by 11: stop 5 to 09:52, stop 6 to 10:13. The morning window for stop 6 was 09:42 to 10:22, so on the window rule alone nothing triggers. The hard window is what matters, because reception shuts at 10:15 and the new arrival leaves only two minutes in hand. So the rule needs two triggers: tell the customer when the projected arrival falls outside the window you promised, and alert the dispatcher when a hard-window stop projects to within 10 minutes of its limit. Here the dispatcher rings the office and agrees to arrive between 10:05 and 10:15.

The five messages, and which ones the tool should send

Customers need five messages across a delivery. What each tool sends on its own varies, so check your tool's notification settings against this list. Routific lists email updates with ETAs and a live tracking link, Spoke Dispatch lists SMS and email notifications with live driver tracking, and OptimoRoute shows customer order tracking on its Pro plan.

The language model's job is to write each template once, in your voice, with every time and name left as a merge field. Ask for it like this:

Write five delivery messages for a small delivery firm: window the evening before, on the way, delay,
could not deliver, delivered. Each must be under 160 characters. Use these merge fields exactly and
never write a time or date yourself: [first name], [window start], [window end], [eta window], [new window],
[reason], [date], [depot], [phone], [link]. No emoji. No apology longer than three words.
Never blame the customer.

A typical first attempt needs three repairs. It may write "your parcel will arrive at 10:40 sharp", which hard-codes a time and promises false precision; replace it with the [eta window] field. It may run the delay message to 171 characters, which would normally be sent, and billed, as two text segments; cut the second sentence. And its could-not-deliver message may open with "As you were not in", which blames the customer when the real reason may be an access problem; use the [reason] field and let the driver's reason code fill it. Once the owner approves the five templates, nobody asks the model to write a message again; the tool fills in numbers on every send. That is the difference between this job and the one in the tutorial on cutting parcel-tracking calls with AI delivery updates, which goes deeper on the customer-contact side.

Proof-of-delivery admin: from driver photo to dispute reply

Driver apps capture the evidence: Routific lists photos, signatures, barcode scanning and notes, and Spoke Dispatch lists signature capture plus a photo-capture allowance on each plan. The admin that follows is where a language model earns its place, in two jobs.

The first is the end-of-day exceptions list. Export the day's stops, remove customer names, and ask for a sorted list of stops with no signature, no photo, a completion point more than 150 metres from the address pin (my threshold; set your own) or a driver note containing words like "neighbour", "reception" or "left". The output is a to-do list of drivers to ask, not a verdict. Check the arithmetic by counting the flagged rows in the spreadsheet yourself before you trust the totals.

The second is the dispute reply. A customer says order 4417 never arrived. Paste the delivery record into the prompt, not a description of it:

ORDER: [number]   STOP: 7   ROUTE: Van 2   DATE: [date]
STATUS: delivered 10:47 (window promised 10:20 to 11:00)
SIGNATURE: captured, typed name "[recipient name]"
PHOTO: 1 attached (not described here)
GPS AT COMPLETION: 40 m from the address pin
DRIVER NOTE: "left with reception, 2 boxes"
CUSTOMER CLAIM: "Nothing arrived and nobody at the desk knows about it."

Using ONLY this record, draft a reply of under 120 words. State what the record shows, offer the next step
(we will ask the driver and send you the photo), and ask the customer to check reception and the mail room.
Do not describe the photo: you have not seen it. Do not accuse the customer or the recipient.

A first draft might say: "Our record confirms your two boxes were handed to reception at 10:47 and the signature proves they were received, and the photo clearly shows them at your front desk." Three problems. "Confirms" and "proves" overstate a typed name on a screen. "Handed to reception" is the driver's note, not a fact about who took the boxes. And the assistant has not seen the photo, so "clearly shows" is invented. The repaired version says what the record says: delivered at 10:47, driver's note says left with reception, a signature and a photo were captured, GPS 40 metres from the address, and a person will review the photo and come back by a stated time. A person reads it before it goes. The tutorial on handling damage claims and disputes covers the harder cases, and the one on chasing missing proofs of delivery shows how the same records feed invoicing.

Handwritten paper delivery notes are the third job, if some customers or suppliers still send them. A model with image input can read a photo of a note into rows, but handwriting produces confident misreads of digits. Check every quantity against the original before anything touches stock or an invoice.

Four numbers that show whether the plan beats the dispatcher

Measure before you buy, so the tool's first month has something to beat. Take a baseline week with your current planning, then compute four numbers from the exported stop records. Do the sums with spreadsheet formulas such as COUNTIFS; the assistant can write the formulas, but the spreadsheet is the source of truth.

1. Share of stops arrived inside the promised window. In the baseline week, say 241 of 300 (80%). Three weeks on, 276 of 300 (92%).
2. Planned against actual driving time per route. This shows whether your service times and the tool's travel times are honest. A gap above about 10% is a prompt to check service times first, before blaming the roads.
3. "Where is my delivery" contacts per 100 stops. Count calls and messages. Say 11 per 100 before, 4 after, once customers have windows and a live link.
4. Proof completeness. The share of stops with a signature or photo and a completion point near the address. A fall in this number is the early sign that drivers are skipping the app at busy stops.

A sensible run-in: week one is the baseline; week two plans the same stops in the tool without driving them, so you can compare against what happened; week three runs one van on the tool's plan; week four runs all of them. At the end, set the new baseline and decide whether to keep paying.

Five ways a good plan still fails on the road

1. A pin lands on the wrong street. Symptom: one stop sits far from its cluster and the van arrives 25 minutes late. Fix: scan the map for lonely pins after every import, and save corrected addresses so the same customer never goes wrong twice.
2. Service time left at the default. Symptom: every route runs about 40 minutes behind by mid-afternoon. Fix: measured medians, per stop type.
3. The loading order is ignored. Symptom: the driver unloads half the van to reach stop 2. Fix: load in reverse stop order and print the load list from the final plan, not the first draft.
4. Windows promised from a draft plan. Symptom: a van is off the road, the plan changes and the evening-before messages are wrong. Fix: lock the plan at a fixed time, and send windows only after the lock.
5. A model-written time reaches a customer. Symptom: a customer quotes "your text said 10:40" and no system shows 10:40. Fix: merge fields only, and sample five sent messages a week.

Drivers sit behind all five. They know that a loading bay shuts at noon on Fridays and that a gate code changed, and none of it is in the system until someone asks. Give each driver a way to add a stop note from the app or on a Friday sheet, and review the notes weekly for ten minutes; the plan improves faster that way than by any tool setting.

Addresses, phone numbers and driver tracking: what stays private

Home addresses, names and phone numbers are personal data. For the cleaning job, swap names for order numbers before pasting; for dispute replies, paste the record without the customer's name and put it back on sending. On consumer plans, find the privacy setting that stops chats being used for model training and switch it off; business plans such as ChatGPT Business and Claude Team don't train on your content by default. A free assistant plan is usually enough for this volume; a paid plan at about $20 a month (ChatGPT Plus and Claude Pro list at that price) is worth it only if you use it for other work too.

Live tracking is a staff matter as well as a customer one. Tell drivers in writing what is recorded, when it stops and who can see it, and make sure the customer's tracking link shows the van's progress rather than a named person's movements. If you are unsure what rules govern monitoring staff where you operate, ask an employment adviser before switching it on.

Questions delivery owners ask before choosing a tool

Do I need AI to plan routes, or is Google Maps enough?

Google Maps on desktop takes a start plus up to nine stops and leaves the ordering to you, which is fine for a handful of drops. Once you run several vans, time windows or twenty-plus stops a van, an optimisation tool saves real driving time and can send customer ETAs for you.

Can ChatGPT or Claude calculate delivery ETAs?

They should not. A language model can write the wording of an ETA message, but the times must come from the routing tool's live data. Asked for an ETA, a model produces a plausible number with no road, traffic or driver position behind it, and the customer will hold you to it.

Should I text or email delivery updates?

Email or a tracking link suits routine updates; keep text for the one message customers must see in the moment, usually the on-the-way notice. Onfleet and Spoke Dispatch charge texts per segment, while Routific and Spoke Dispatch include email notifications.

What should I tell drivers about tracking?

Tell them in writing what is recorded (location during shifts, delivery photos), when recording stops and who can see it. If you are unsure what rules apply to monitoring staff where you operate, ask an employment adviser before switching live tracking on.

Further reads

• Can a Small Courier Firm Use AI to Plan Delivery Routes? — The shorter question-and-answer take on whether AI route planning suits a courier.
• How Can AI Help Courier Services? Quotes, Dispatch and Proof — Quotes, dispatch and proof of delivery across a courier business.
• AI Courier Quotes: Reply to Delivery Enquiries From Your Rate Card — Price delivery enquiries from your rate card before they reach the plan.
• Fleet Admin for Small Businesses: Automate Services, Checks and Fuel — Automate services, checks and fuel for the vans themselves.
• Can AI Read Delivery Notes and Update Stock Automatically? — Reading incoming delivery notes and updating stock.
• Pizza Delivery Software: Which Options Handle Dispatch and Texts? — Which delivery tools assign drivers, promise realistic times and send on-its-way texts for a pizza shop, with list prices and a Friday-night walk-through.
• Heating Oil Delivery Software: Route Winter Top-Ups With AI Help — A demo checklist for heating oil delivery software: tank-level estimates, run-out priority, route order and truck load, with worked sums and AI uses that fit.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Routific, OptimoRoute, Spoke Dispatch and Onfleet pricing pages, and Google Maps Help on multi-stop routes, all read in October 2026.