How to automate order entry at a freight forwarder, walked through one transport order

What exactly does the agent do when the first order email lands at 7:40 in the morning? If you want to automate order entry, that is the first thing to pin down, and "it reads the email and creates the order" is too thin to base a decision on. Between the inbox and a finished order in the TMS there are seven steps. At two of them a person still decides: the follow-up question to the customer and the release of the order.

The example below is made up. It describes how we would build an agent like this, not a job we did for a client.

Automating order entry at a forwarder with three inbound channels

Picture a forwarder in Westphalia moving part loads and groupage for around 80 regular customers and taking in roughly 60 orders a day. Some arrive as emails with a PDF or spreadsheet attached, some as plain text in the email body. A smaller share comes through the forwarder's own customer portal, a web form with fixed fields and a comments box. The TMS has an API for creating orders and looking up master data. Right now two people in dispatch key in the emails and pick up the phone whenever something is missing.

Our sample order comes from a builders' merchant who has been a customer for years. The PDF from their ERP lists eight pallets of paving stones, collection from the warehouse in Hamm, delivery to a building site in Kassel, "delivery tomorrow morning" and their purchase order number. The email body adds a line the PDF leaves out: there is no forklift on site, so the truck needs to bring a truck-mounted one.

Seven steps from inbox to TMS draft

1. Is this a new order at all?

Before extracting anything, the agent works out what kind of email it is looking at. The order inbox also collects invoice queries, delivery notices, out-of-office replies and amendments to orders already in the system. Amendments are the dangerous case. Read one as a new order and two trucks turn up at the same site. So the agent checks whether the customer's PO number or the email thread matches an existing order. Here nothing matches, so the email is treated as a new order. Anything the agent cannot place with confidence goes onto a separate list for dispatch instead of being guessed at.

2. Who sent it?

The sender address leads to the customer record. That works as long as the same person always writes. If someone new at the builders' merchant sends the order, the domain still matches, so the agent proposes the customer and flags the match as uncertain. With free webmail addresses or shared mailboxes the domain tells you nothing, and a person decides.

3. Reading the details

Now the agent goes through the PDF and the email text for what a transport order needs: pickup and delivery points, date and time window, pallet count, weight, customer reference, special instructions. A language model finds these wherever they sit on the page. For customers who have sent the same PDF layout for years, a fixed extraction rule is often quicker and cheaper, and a well built agent uses both.

"Tomorrow morning" is where it gets awkward. The date follows from the day the email arrived. What "morning" means is for the forwarder to decide, say 8 to 12. We write house rules like this down before building anything, because otherwise every dispatcher reads them a little differently, and so would the agent.

The forklift note only appears in the email body. A process that reads attachments alone drops it, and tomorrow a driver is standing in front of eight pallets of paving with no way to unload them.

4. Matching against master data

What the agent has extracted is still just text, and the TMS wants records. It knows the Hamm warehouse as a loading point with opening hours from 6 a.m., so that match is clean. The building site in Kassel is not in the address book. The agent attaches it to the order as a one-off address and suggests adding it to master data. In this setup only a person changes master data.

Then come the sanity checks. The weight is missing. Eight pallets of paving can weigh roughly eight to twelve tonnes depending on the stone, and that decides which vehicle can take the job. Guessing here would be risky, so the agent marks the field as missing. The forklift requirement maps to an existing attribute in the TMS. The agent sets it and records the source, which is that one sentence in the email.

5. The draft in the TMS

Through the API the agent creates the order with the status "to be checked". Nothing is released yet and the customer gets no confirmation. Every field carries a note on where its value came from: read from the PDF, filled in from master data, derived from a house rule, or missing. The original email is attached. Whoever reviews the draft can see at a glance which fields to trust and where to look harder.

Some TMS products have no draft status. A custom status or a review list outside the TMS does the job then. It is one of the questions to settle before the build starts.

6. The follow-up question is already written

Two gaps remain: the weight, and whether "morning" really means 8 to 12 at that site or whether nobody is there to receive goods before 9. The agent drafts a reply in the customer's email thread asking exactly those two things, with the PO number in the subject line. It does not send it. A dispatcher reads it, changes a word if needed and hits send. When the customer answers, step 1 recognises the email as a reply to that question and the agent fills the values into the draft.

7. Dispatch releases the order

Dispatch sees two lists. One holds drafts where every required field is filled and every match is certain, the other holds drafts with flags. The first list goes quickly, the second still needs work. The order confirmation goes to the customer only on release. A confirmation is a commitment, and in this setup commitments come from people.

What about the customer portal?

Orders from the forwarder's own portal look like the easy case, since the fields arrive structured. The catch is the comments box, where the instructions that matter tend to end up: "call before delivery", "pallet exchange", "use the rear entrance". At the moment either a person reads that or nobody does. The agent reads the free text as well and turns each note into the matching TMS attribute. If there is no matching attribute, it flags the note.

Portals run by large shippers, where the forwarder has to log in and collect orders, are a different matter. If the portal offers an API or an export, the agent pulls orders from there. If all you have is the web interface, we would advise against screen scraping it. That works until the shipper changes the portal, and nobody will warn you when they do. In that case the portal's notification email is the better way in, or that channel stays manual for now.

Where the agent stops

Route planning stays with dispatch, because the rules behind it mostly live in dispatchers' heads. Prices come in only when the TMS already calculates them from a rate card or framework contract. The agent will not guess a price for a special run. It also writes nothing to master data or to customers that nobody has approved. These limits are deliberately tight at the start, and you can loosen them once you know how often drafts need correcting.

Test it on your own emails before you sign

You can find out whether an agent like this copes with your orders before you commit, using your own mail. Put aside 30 to 50 real order emails from recent weeks exactly as they came in, with attachments, amendments and the messy ones. Next to each, note what ended up in the TMS. That set tells you more than any product demo, because it contains your customers and their formats. The emails include names and phone numbers of contact people, so sign a data processing agreement before handing them over.

The same set doubles as an acceptance test. Agree that the agent must classify these emails correctly, fill the required fields or flag them as missing, and never create an order twice. A provider who won't commit to that probably doesn't know how often their process gets it wrong.

Sophera Consulting builds order entry agents like this for a fixed price and without a subscription. Before building, we sit down with your dispatch team, go through real order emails and write down which house rules apply and which decisions stay with people. You get the finished agent handed over with documentation. Whether it pays off for your order mix is what the free automation check is for.

What we recommend

Start with the email inbox and have the agent create drafts only for the first few weeks. During that phase no message reaches a customer without approval, and master data stays untouched. Keep count of how many drafts are released unchanged and which fields get corrected most often. Those numbers tell you whether regular customers with a clean PDF format can later go through without individual review. Add the customer portal as the second channel. Shipper portals without an API come last, if at all.