The problem does not start at the inbox
A transport company receives orders, requests, and instructions by email every day. From different customers, in different formats, sometimes as plain text, sometimes as a PDF attachment, sometimes both at once. The temptation is to say: put an AI on it and you are done. But before you can feed the AI, you need to know what you actually want to execute. Which field in the TMS needs to be filled? What is a loading location and what is a delivery address when a customer calls both 'Rotterdam'? Who decides when an email contains conflicting information? Those questions existed before the AI. The AI just makes them more visible.
What AI email processing in transport does well
When the structure is clear, AI-based email processing is fast and reliable. Standardised customers who send orders in a fixed format, with fixed reference numbers and fixed locations: an AI Worker can read the email, map the fields, and stage the order for approval by a planner. The planner no longer keys in ten fields manually but checks whether it is correct and confirms. That is the human-in-the-loop approach that works in practice: the data entry disappears, the responsibility stays. The biggest gain comes from volume. If you process dozens of repetitive order emails from the same customer every day, the benefit is immediately tangible.
Where it goes wrong with transport-specific emails
Transport emails are rarely clean. A freight forwarder sends an instruction buried in the bottom reply of a six-message email chain. A customer sends a PDF with a table that looks structured on paper, but where the columns shift with each shipment. Another customer puts three orders in one email with no clear separation. Each of these variations requires a different processing strategy. The trap is thinking that a generic AI approach will solve this. It will not, without an additional layer: logic that determines what is in the email, how many orders it contains, and which message is the most current. Building that logic requires domain knowledge of transport, not just AI knowledge.
When AI email processing in transport is not the right intervention
If the real problem is unstructured customer communication, better AI will not fix it. You are just moving the chaos to a later point in the process. If customers write in free text with no fixed references, no addresses in a recognisable format, and deviations that differ every time, you have two options: either you invest in customer portals and instruction emails that enforce structure, or you build a robust extraction layer that can handle exceptions. The second option costs more time and money than most companies expect. Sometimes the most honest conclusion is to tighten up communication agreements with customers first, and only then deploy the AI.
What to take away as a learning point
AI email processing in transport works best when you treat it as a data integration problem, not an AI problem. Start with the question: which fields need to be filled, and how recognisable are they in the emails you receive today? Take a sample of a hundred recent order emails and categorise them by structure. You will find that a small portion is genuine noise, a large portion is repetitive and therefore straightforward to automate, and a middle group contains exceptions that require human judgement. Build the AI on the repetitive core. Route exceptions to a planner with a signal and context, not silently through the system. That is the approach that holds up in production.