Most logistics teams evaluating AI start with the hardest question: can it decide? Can it price a lane, pick a carrier, route around a delay. The larger and safer win sits underneath that. It is the copying — the same shipment details typed into a transportation management system, then into a customer email, then into a broker’s portal, then checked line by line against an invoice six weeks later. Nobody’s title is “retype things,” but for a lot of coordinators it is most of the day.
That work is worth attacking first for a reason that has nothing to do with ambition. When automated decision-making is wrong, you often find out late and expensively. When automated copying is wrong, you find out immediately, because the wrong number is sitting in front of someone who knows what it should have been.
Where does the day actually go?
Into moving the same facts between systems that do not talk to each other.
Take one international shipment. A booking confirmation arrives as an email. The rate confirmation arrives as a PDF with the numbers in a different order than the last carrier used. Somebody keys the container and vessel details into the transportation management system, or TMS. An arrival notice comes in, formatted differently again, and the ETA gets updated by hand. The customer asks where their freight is, and answering means opening the TMS, a carrier’s tracking page, and someone’s inbox. The packing list and commercial invoice go to the customs broker, usually by email, sometimes retyped into a portal. Six weeks later a carrier invoice shows up with three accessorial charges on it — the extra fees for detention, storage, redelivery and the like — and someone compares it against the original quote to work out whether two of them are legitimate.
None of those steps is difficult. Every one of them is a person reading something and typing it somewhere else. On a team running a few hundred shipments a month, that is not a rounding error. It is the reason your coordinators are working late and your exceptions get caught a day after they mattered.
Count how many separate systems one shipment’s data gets entered into between booking and invoice. If the answer is four or more and nothing is syncing them, the copying is your largest recoverable cost, and it is almost certainly larger than you think.
Why did this fail the last time you tried it?
Because the tools needed clean, consistent input, and logistics input is never consistent.
This matters because a lot of logistics teams have already bought automation once and watched it decay. The usual story: someone set up templates or scripted rules to pull fields out of arrival notices and rate confirmations. It worked for the carriers it was built for. Then one carrier moved a field, another started sending a scanned document instead of a generated PDF, a new customer arrived with their own format, and each break needed a developer. Within a year the maintenance cost more than the savings and the team quietly went back to typing.
That failure was real and it was not the team’s fault. Rule-based extraction and traditional electronic data interchange, the older standard for machine-to-machine document exchange, both assume the sender behaves predictably. In freight, the sender is a different company every week.
What changed is specifically the part that used to break. Current models read a document without being told its layout, which means a new carrier format is not a project. They handle scans, inconsistent labels, and information that appears in a paragraph rather than a field. The brittleness that killed the last attempt is largely gone.
What has not changed is that these systems are probabilistic. They are usually right and occasionally confidently wrong, which means the design question is not “is it accurate” but “what happens on the occasions it is not.” That question has a good answer for some tasks and a bad answer for others, and knowing the difference is most of the work.
What should you automate first?
Anything that meets three conditions: high volume, messy input, and an output a person can check at a glance.
That last condition does the most work. If a human can verify the result in two seconds, the failure mode is caught before it costs anything, and the automation is safe even while you are still learning to trust it. Three candidates usually qualify:
Document intake. Arrival notices, rate confirmations, bills of lading, packing lists, delivery orders. Extract the fields, populate the shipment record, and show the extraction next to the source document so whoever is reviewing can confirm it without opening anything else. Volume is high, formats vary constantly, and a wrong container number is obvious.
Status communication. The “where is my shipment” email. The information already exists across your systems; what takes the time is assembling it and writing it up. Drafting that reply from the systems of record, for a person to send, removes a genuinely large amount of work without handing anyone a decision.
Invoice reconciliation. Compare the carrier invoice against the original quote and the shipment record, then surface the variances rather than the matches. Most lines agree. The value is in having the three that do not agree put in front of someone on the day the invoice arrives instead of at month end.
The pattern across all three: the machine does the reading and assembling, the person keeps the judgment, and the handoff between them is visible. That is a different proposition from an autonomous system, and it is the one that actually survives contact with an operations team.
What should you leave alone?
Anything where being wrong is both expensive and quiet.
This is the more important half of the answer and it gets skipped in most writing on the subject. A misrouted shipment announces itself. A wrong duty figure, a dropped temperature requirement, a hazardous materials classification that nobody questioned, a customs declaration with an unexamined origin on it — those fail silently and surface as a penalty, a rejected load, or a claim. Automating them means removing the person who would have noticed, which is the opposite of what you want. It is the same principle that decides where human review has to sit in a system: the failure mode matters more than the task.
| Task | How it fails | Start here? |
|---|---|---|
| Document intake | Wrong field, visible on screen | Yes |
| Status replies | Wrong detail, caught before sending | Yes |
| Invoice reconciliation | Flags a variance that is not one | Yes |
| Duty and classification | Silently, as a penalty months later | No |
| Exception handling | Silently, as a lost customer | No |
Exceptions belong to people for the same reason. When a container is rolled, when a customer needs to be told something they will not like, when a carrier relationship is worth protecting through a bad week, that is judgment, and it is usually the part of the job your best coordinators are actually good at. Automating the copying is what gives them time to do it.
There is also a timing answer. If a workflow is genuinely low volume, leave it. Twenty documents a month does not justify building anything, and the effort is better spent on the process running two hundred. The same discipline that decides when a prototype has become production software applies here: build for the volume you actually have.
How would you know it worked?
Pick something countable before you start, because “hours saved” is unfalsifiable and every vendor claims it.
Three that hold up:
- Touches per shipment. How many times a human enters or re-enters data between booking and final invoice. Count it by hand on twenty shipments now. Count it again in three months.
- Time to answer a status request. From customer email received to reply sent. This one is easy to measure and your customers feel it directly.
- Share of invoices that reconcile without manual review. Start with the percentage today, which for most teams is close to zero because everything gets reviewed.
Baseline them before anything changes. The most common reason an automation project cannot prove its value is that nobody wrote down what the old number was, and by the time anyone asks, the old process is gone and the comparison is a guess.
Where this leaves you
Not which parts of your operation AI could run, but which parts of the day your team spends moving information that a system should be moving for them.
That question is answerable this week, without a vendor, by counting. And the answer usually points at three or four workflows that have been quietly expensive for years, none of which require anyone to trust a machine with a decision.
Connecting those systems to each other is ordinary integration and engineering work. The hard part was never the technology. It was deciding which copying to stop doing first.