AI for logistics and transport
The question a logistics operator receives most is "where is my shipment?", and it has an exact answer in a system. The problem was never knowing it: it was delivering it on time, in the channel where people ask.
Key takeaways
Most of a logistics operator’s support volume is a single question with an exact answer in the TMS. That is the case, and it is one of the most measurable there is.
Status is queried live against the system, never from an index. A stale status in the chat generates more calls than it saves.
Proactive notification is worth more than the answer: flagging the delay before they ask turns a complaint into a managed expectation.
Route optimisation is an operations-research problem, not a language one. An optimisation engine solves it, and the model explains the result.
The five problems in a logistics operation
The first three are information problems and a system solves them. The last two are optimisation problems and need a different tool.
- The data exists in the TMS and does not reach the end customer, who ends up calling.
- Status, estimated date, exception, rescheduling. High volume and an exact answer.
- Emails, calls and spreadsheets between several parties, with the exception surfacing late.
- Delivery notes, manifests and receipts retyped by hand, and every error is discovered at the delivery point.
- Real and expensive, but it is a constrained optimisation problem, not a conversational one.
Live status, and telling people before they ask
Shipment status is the most volatile data in this domain: it changes several times a day. It gets queried live against the TMS at answer time, never from an index, and the answer carries the data’s timestamp. An assistant answering with last night’s status does not reduce calls: it multiplies them, because now the customer distrusts both sources.
The second decision pays most and almost nobody implements it: invert the flow. Instead of waiting for the question, the system detects the exception — the delay, the failed delivery, the route change — and tells people. An expectation managed in time costs one message; the same fact discovered by the customer costs a call, a complaint and sometimes the account.
And a warning about route optimisation: it is an operations-research problem with hard constraints — capacity, time windows, traffic regulations — and an optimisation engine solves it, not a language model. When the case justifies it we build the engine and the model explains the result to the planner. A vendor offering "AI-optimised routes" without naming the engine is selling text.
The numbers behind a logistics operation
| What is measured | What it means | How it gets fixed |
|---|---|---|
| Status accuracy | On a sample: whether what the system said matched the TMS at that moment, with its timestamp. | Live queries, never the index. It is the failure that makes the customer stop trusting the channel. |
| Proactive notification coverage | Of the exceptions that occurred, how many were flagged before the customer asked. | Usually a missing event from the TMS or the carrier, not a system capability gap. |
| Resolution without a person | What share of status and rescheduling queries closes without escalating. | You widen what the system can do, not what it can say. |
| Document accuracy | Field by field on delivery notes and manifests, against a hand-validated batch. | An error in an address or a weight is discovered at the delivery point, which is the worst place. |
If the TMS does not expose status over API, or the operation runs on spreadsheets updated at end of day, the first project is that traceability, not the assistant. A system answering with last night’s data generates more calls than it saves.
And if what you want is route planning, we say it plainly: that is a constrained optimisation engine, not a language model. We build it when the case justifies it, but we do not sell it as conversational AI, because it is not.
Related services
Integrations and APIs
MCP servers against the systems already in operation.
View serviceAI automation
Applied where there is volume and stable rules, not where there is expectation.
View serviceAI chatbots and assistants
With the evaluation set run before it ever reaches production.
View serviceAI agents
LangGraph orchestration, durable state and human approval on steps with consequences.
View serviceMore from the blog
Frequently asked questions
Does it connect to our TMS or WMS?
Yes, over API or an MCP server against whichever system you run, and against carrier platforms when shipping is outsourced. It is the requirement rather than an enhancement: without reading live status, the assistant can explain how the process works but cannot say where a shipment is, which is the question that carries the volume.
Can it notify on its own when there is a delay?
Yes, and it is the highest-return part of all this. The system detects the exception in the TMS — delay, failed delivery, route change — and notifies through the customer’s channel before they ask. An expectation managed in time costs one message; the same fact discovered by the customer costs a call, a complaint and sometimes the account. The metric is what share of exceptions was flagged in time.
Does it optimise routes?
It can be built, with an important caveat: that is a constrained optimisation engine — capacity, time windows, regulations — not a language model. When the case justifies it we build the engine, and the model explains the result to the planner rather than producing a route out of text. If a vendor offers "AI-optimised routes" without being able to name the engine or the constraints it respects, they are selling a description.
Is this for a shipper rather than an operator?
Yes, and it is usually simpler. A company shipping its own orders needs to answer "where is mine?" and flag exceptions, against the platform of the carrier it hired. The requirement is the same: that platform has to expose status in a queryable way. If tracking lives in a shared spreadsheet, that is the first project.
Can it reschedule a delivery on its own?
It can, if the TMS allows it and you authorise it, and that is where the assistant moves from informing to resolving. We recommend explicit limits: what it can reschedule alone, up to how many days, and which cases always escalate. Those limits get defined with the operation before building and live in the system, not in a prompt that can be negotiated mid-conversation.
How long does it take and how is it priced?
Four to eight weeks to production depending on integrations, with something running from week one. It is quoted with fixed scope, price and date in a proposal 48 hours after the first call, and the price is driven by how many systems and carriers have to be connected.
Book 15 minutes
Tell us what you are building, or what stopped working. You leave the call with a concrete answer: it can be fixed, it can be built, or it isn't worth it.