Logistics companies do not have an AI problem. They have email-to-WMS gaps, exception piles, and people acting as the integration layer. The useful move is a controlled model step on those breaks.
The pile is not an AI problem
A control tower on a Tuesday morning is not short of software.
There is a TMS. A WMS. An ERP. A customer portal. A carrier portal. A shared mailbox. A WhatsApp group for the yard. A spreadsheet that still decides which truck gets which dock.
The work still leaks between them.
An email arrives about Order 4412. Someone reads it and manually enters four fields into the TMS. On the warehouse floor, a scanner records “pallet short, check aisle 4,” but the note never leaves the handheld. The official exception is raised two hours later, if it is raised at all. Meanwhile, the customer is told Friday because that is what the latest email says, while the WMS still shows Saturday.
None of that is a missing chatbot.
It is a missing bridge between messy information and the system that already owns the record.
Buying a model subscription does not close those gaps. The person is still the integration layer. The model lives in another tab. Tuesday looks the same.
The companies that get value from AI in logistics will not be the ones with the most impressive demo. They will be the ones that name the exact break, put a controlled inference step on it, and refuse to let a fluent answer become operational truth.
Break 1 : Intake is still re-keyed by a person
The most common logistics “AI use case” is also the most misunderstood.
Every day, the same class of message arrives. An order confirmation. A booking. A delivery instruction. A PDF from a shipper who will not use the portal.
“Order 4412 — 12 pallets, dock 3, ready Friday.”
A person finds the order number, the quantity, the dock, the date. They type those values into the TMS or ERP. They do this fifty, two hundred, a thousand times a week.
The side-tab version of AI looks helpful and changes nothing.
Copy the email. Paste it into a chatbot. Get a neat summary. Copy four values back. The model read the message. The person is still the pipe.
The operational version starts from the event, not from the employee.
The mailbox, EDI feed or portal upload triggers the process. The system identifies Order 4412 and loads only the information needed for that case. The model returns structured data, which is then checked against the schema, order details, dock status, workflow state and confidence thresholds. If everything is valid, the official record is updated automatically. If something is uncertain or inconsistent, the case is assigned to a named owner for review, with the original message kept alongside it.
No second truth. No vanished chat history. No “I think I already entered that.”
The model proposes. The existing system commits. That is the whole design.
Steps on this path
Side channel
Work still starts in the real system
An email, order, or warehouse event lands where the company already works — mailbox, WMS, order table. So far, nothing has changed. The model has not been involved. The official record is untouched.
01 / 05
Break 2 : Warehouse exceptions die in the note
A scanner reports something the happy path did not expect.
A pallet is short. A location is empty. A pick cannot finish. Goods are damaged.
The useful information is often a sentence a person typed with gloves on: “3 missing, maybe aisle 4, shift lead to confirm.”
Today that sentence lives on the device, in a chat, or in someone’s head. The WMS row stays green. Planning finds out when the truck is already at the dock.
A chatbot on the wall does not fix this.
The employee should not leave the floor system to explain the problem to a model. The exception should appear where exceptions are already handled.
The model’s job is narrow. Read the note. Classify the exception. Attach the order, the location, the last scan. Propose a route: recount, quarantine, short-ship, call the planner.
The model does not invent a pallet. It does not adjust stock.
Stock, location, and status stay in the WMS. Those writes are deterministic. They already have rules. AI should not get a second set of keys.
If confidence is low, or the note names the wrong order, the case fails closed. A person owns it. Waiting is cheaper than a confident lie about what is on the floor.
Exception route steps
On the case
The floor already has a case
A scanner, handheld, or dock note lands on an existing WMS row. The model is not a second system. It is about to be asked one question about this case.
01 / 05
Break 3 : The dock plan still lives in a spreadsheet
Appointments, time windows, yard status, and “who is actually on the box” often sit outside the TMS.
A carrier emails “we’ll be there around 14h, maybe later, same dock as last time.” Someone interprets that. Someone updates a sheet. Someone forgets to tell the warehouse. The truck arrives. Dock 3 is occupied. The official plan is already fiction.
This is not a job for an autonomous agent that “optimises the yard.”
Most of it is rules. Opening hours. Dock type. Vehicle length. Booked windows. Those should stay as software.
The model earns its keep on the messy message: extract a proposed arrival, a vehicle hint, a reference. Then the appointment system decides whether that slot exists.
If “the usual dock” cannot be resolved to a real loading dock, do not invent one. Send it to the planner. The sheet is not improved by a fluent guess.
Break 4 : The customer is told a story the system does not believe
Status is where logistics companies lose trust faster than they lose pallets.
Sales says Friday because the last email said Friday. The WMS says the order is not released. The carrier scan says the trailer is still at origin. Three truths. One customer.
Putting a chatbot on the portal that “answers shipment questions” is how you industrialise that lie.
If the model is allowed to narrate, it will narrate. It will smooth over missing scans. It will sound sure.
The correct architecture is boring. Retrieve the official status from the system of record. Say that. If the record is incomplete, say so. “I don’t know” is a feature.
A model may help phrase the answer, or find the right shipment from a messy customer reference. It may not invent an ETA. Dates that other people plan on are deterministic writes, not prose.
Break 5 : The POD exists. The case does not.
Proof of delivery, damage photos, CMR scans, and carrier invoices arrive as documents. The claim, the credit, or the dispute is supposed to become a case in a ticketing system or TMS.
Often it does not. Or it does, three days late, with the wrong reference.
This is extraction plus a commit gate. Same pattern as intake. Different cost of being wrong.
The model reads the POD. It proposes a delivery timestamp, a signature present/absent, a damage flag, a matching shipment. Software checks whether that shipment exists and whether a case is already open. High confidence opens or updates the case. Low confidence goes to claims.
Do not let the model close a claim. Do not let it issue a credit. Those are consequential writes. They already have owners.
Break 6 : Customs documents cannot fail open
Commercial invoices, packing lists, and certificates are unstructured enough that people want a model, and expensive enough that a wrong commit is not “we’ll fix it later.”
A misread HS code, a missing certificate, or a confident guess at origin can stop a border, not just a dashboard.
Use the model to extract. Use tables and rules to validate. Use a person for the remainder.
If the extracted code is not in the allowed list, the process stops. If two documents disagree, the process stops. If confidence is merely “plausible,” the process stops.
Fail closed is the product. Speed is what you get after the gate is real, not instead of it.
Break 7 : Inventory truth is not a prompt
This is the one to refuse most often.
Someone will ask whether AI can “keep stock correct” or “predict what is really in the aisle.” A model can comment on a photo or a note. It cannot become the stock ledger.
On-hand quantity, reservation, and location are the contract other processes trust. Purchasing, planning, and billing read them. A probabilistic write here is not a clever assistant. It is corruption.
If you use a model near inventory, keep it on the edge: interpret the exception, propose a recount, flag a photo. The WMS still posts the adjustment. A person or a scanner still confirms what is there.
The database is the contract. The model is the proposal. Nowhere is that more literal.
What to automate first
You cannot boil the network. You should not try.
Start where three things are true at once.
Unstructured information already arrives at scale through emails, PDFs, scanner notes and carrier messages.
A system of record already exists. You are not building a new TMS. You are attaching a step to the one people already trust, even if they complain about it.
A wrong commit is containable. You can fail closed, park the case, and have a named owner. You are not silently moving legally binding customs data or inventing stock.
That usually means intake and warehouse exceptions first. Docks once the appointment object is real. Status only after you are willing to tell the customer the official record, including its gaps. Claims and customs when the extraction schema is tight. Inventory last, and only at the edge.
If a proposed project cannot name the event, the row it will update, the validation, and the exception owner, it is not an operational AI project. It is a demo.
Automate first
Intake
Job: Extract
Do this
Mailbox or upload starts a handler. Structured fields. Schema. Write or queue.
Do not do this
A chatbot the clerk pastes into. The person stays the pipe.
Error cost
Containable if you fail closed
The only test that matters
After the model is in place, does Tuesday morning move differently?
Does the email become an order line without re-keying?
Does the short pick reach the planner while the truck can still be saved?
Does the customer see the status the WMS believes?
Does a bad extract stop, instead of becoming a confident row?
Can you explain six months later why the record changed?
If the answer is yes, AI has become part of the operation. If the answer is no, it is just another tool to open, and the underlying workload has not changed.