AI in logistics: dispatch, exceptions and customer updates

AI in logistics is most useful where a person is currently making the same small decision hundreds of times a day under time pressure: which rider takes this order, what to do about the customer who is not answering, and what to tell the shipper whose consignment is late. Those three jobs, dispatch, exceptions and customer updates, are where logistics automation AI earns its keep. Route optimisation and demand forecasting matter too, but they are batch problems with mature tools; the three above are live, conversational and messy, and that is where an agent changes the day.

This article explains what each of the three looks like when built properly, how they connect to the dispatch platform and the driver app, where autonomy is safe and where it is not, and what a build costs. It is written for operations heads and CTOs at last-mile operators, 3PLs, hyperlocal platforms and field-service companies.

Where AI belongs in a logistics operation

Dispatch proposals, not dispatch decisions

The dispatch engine takes live inputs (orders, rider locations and capacity, time windows, vehicle types, hub rules) and proposes assignments in seconds, each with a reason a dispatcher can read: nearest available, same building as an existing stop, vehicle can carry the load. The dispatcher's job becomes reviewing exceptions to the proposal rather than building the plan from nothing. That framing matters, because dispatchers know things the engine does not (this rider is unreliable on Sundays, that gate closes early), and a system that ignores them gets switched off. The engine's core is optimisation, not an LLM; the LLM writes the explanation and lets a dispatcher ask "why not rider 14" in plain language. Our post on dispatch and routing engines goes deeper.

Shadow mode before auto-assign

For the first weeks the engine proposes and a person assigns; the two are compared. Where the proposal was accepted without change for a class of order (routine, single-parcel, in-window), auto-assign is switched on for that class only. Overrides are logged with reasons, and the reasons feed the next version of the rules. This is the same shadow mode discipline we use for every agent.

Resolving delivery exceptions on WhatsApp

A delivery exception AI handles the events that today generate a phone call: customer not available, address not found, customer requests a different slot, COD not ready, wrong item, damaged parcel, refused delivery. The agent reads the event from the driver app, looks up the order and the customer's contact preferences, and acts within a policy for that event type. Address not found: message the customer with the rider's location and ask for a landmark or a pin, pass it to the rider, log the corrected address against the order. Customer unavailable: offer the next two slots within the SLA, confirm, update the route. Damage or refusal: collect a photo from the rider, notify the customer that a person will call, and open a case with the transcript for the hub. The rules for what the agent may do alone are written per event, and anything outside them goes to a person with context. The detailed design is in exception-handling agents for deliveries.

Customer updates before anyone calls

"Where is my order" is the most common contact in last-mile logistics and the easiest to remove. Proactive updates at the moments customers care about (picked up, out for delivery, ten minutes away, delivered with proof, delayed with a new ETA) on WhatsApp, with a way to reply and get an answer from live tracking data, remove most inbound calls. The ETA has to be honest: an agent that says "ten minutes" from a stale location does more damage than silence, so updates are driven by the driver app's real location stream, and the agent says "delayed" when it is. WhatsApp's rules on template and session messages shape what can be sent proactively; the WhatsApp Business Platform documentation is the reference. For B2B shippers, the same agent answers consignment-status questions from the TMS and drafts the exception report the account manager would otherwise write by hand.

Operations alerts and reconciliation

With dispatch, exceptions and tracking events in one place, an agent can watch the operation: a hub whose out-for-delivery times are slipping, riders idle while orders wait, orders that will miss SLA on the current plan, a COD shortfall that does not match returns. These are advisory, surfaced to the operations lead on a dashboard or a morning summary, and they replace the end-of-shift discovery with a mid-morning nudge. Reconciliation anomalies (settlement, fuel, COD) are the same pattern on a daily cadence; the model side is covered in fraud and anomaly detection.

The data and integration layer underneath

None of this works without a live, consistent picture of orders, riders and events. The dispatch platform is the source of truth; the driver app streams location and events, offline-first so a rider in a basement does not disappear; the WhatsApp channel, the TMS or OMS, and the customer's own systems connect through APIs. Every agent action is written back as an event with the policy that permitted it, so the operation has one timeline per order that a human can read. If the platform is a legacy system, the agents sit behind an integration layer rather than waiting for a rewrite; see adding AI to an existing product without a rewrite.

A worked example

A last-mile operator running several city hubs dispatched by hand from a spreadsheet and handled exceptions through a call centre that spent most of its day phoning customers on behalf of riders. We built a dispatch platform with an offline-first driver app first, because without a live event stream there was nothing for an agent to act on. The dispatch engine ran in shadow mode alongside the dispatchers, then took over routine single-parcel assignments. An exception agent on WhatsApp handled address clarification and rescheduling within SLA rules, and escalated damage and refusal to the hub with photos and transcripts. Proactive status messages replaced most inbound "where is my order" calls. The call centre's work shifted to the cases that needed a person, and the operations lead got a morning summary of hubs at risk instead of an evening surprise. Outcomes are described qualitatively in the case study; we do not publish clients' numbers.

Team and timeline

A logistics AI programme is usually two builds. The first, if you lack a live event stream, is the platform and driver app: a product and platform development engagement from $42,000 / ₹28L, with the React Native mobile app from $17,500 / ₹11.2L, over twelve to twenty weeks. The second is the agents: dispatch proposals, the exception agent and customer updates, typically a multi-agent systems build from $24,500 / ₹16L, or a customer service agent build from $12,500 / ₹8L if only the WhatsApp side is needed, over six to ten weeks including shadow mode. Where the platform already exists, start with the agents. A ten-day Sprint Zero decides which of the two you need; current prices are on the pricing page, and our logistics sector page lists related work.

Before you start: a checklist

• Confirm you have a live event stream from the field; if not, that is the first build
• List exception types by volume and write the policy for each: agent alone, agent then human, human only
• Decide the dispatch rules dispatchers actually use, including the unwritten ones
• Set up the WhatsApp Business account and templates early
• Define SLA windows and reschedule rules per customer segment
• Agree the shadow-mode period and the acceptance criteria for auto-assign
• Name the operations owner who reviews overrides and escalations weekly

Questions clients ask

• Will the engine replace dispatchers? No; it removes the routine assignments so dispatchers handle the exceptions, and they keep the override.
• What if the rider has no signal? The driver app queues events locally and syncs when connectivity returns; the agent works from the last known state and says so.
• Can it handle our B2B shippers as well as consumers? Yes; the same agent answers consignment status from the TMS and drafts exception reports for account managers.
• How do we stop it over-promising ETAs? ETAs come from live location and the current plan, and the agent is instructed and tested to say "delayed" rather than guess.

Related reading

See building an offline-first driver app for the field side, logistics ERP: fleet, dispatch, settlements and reconciliation for the back office, and WhatsApp AI chatbot for business for the channel.

Put AI where the repetitive judgement is, dispatch, exceptions and updates, run it in shadow first, and the operation gets quieter without getting slower.