Situation
A transport company in Panevėžys, with about 90 employees, carries freight within Lithuania and to Western Europe. Orders arrive the way customers find convenient: some send a PDF order form, others free text in an email, others forward an extract from their own system with attachments. There is no single format and there will not be one: the company has several dozen customers, each with their own habits.
Two dispatch office employees spent most of their day not planning but retyping: opening an email, finding the loading and unloading addresses, dates, weight, pallets and reference numbers, entering them into the transport management system, and replying to the customer that the order was received. On peak days emails waited in a queue for several hours, and customers called to ask whether the order had been received.
Errors were the second problem. A mixed-up unloading time or a missed note about ramp height meant an empty trip or a fine. The manager calculated that there were a few such cases a month, and each cost more than a day of retyping. The company came to us with a specific question: can AI read such emails reliably, and is it safe?
What was needed
- Reading orders from email regardless of format: PDF, free text, a table in the email, attachments.
- Automatic creation of a record in the transport management system with all required fields.
- Human confirmation before every record in the first months, and always when the agent is not sure.
- No use of customer data for model training; data is processed through the API under agreed terms.
- Deployment without stopping the dispatch office and without new software for employees.
What we did
Weeks 1-2: email analysis and rules
We started not with technology but with the emails. We reviewed several months of order history and grouped it by format: about half arrived as PDF forms, a third as free text, and the rest were mixed. With the dispatchers we wrote down what is mandatory in an order, when an order counts as unclear, and who it should go to in that case. These rules became the agent’s instructions.
Weeks 3-5: the agent and integration
We built the agent on a Claude model through the API. The agent reads a new email in the mailbox, recognises whether it is an order, breaks it down into a structure (sender, route, time windows, cargo, special requirements, reference number) and checks that all mandatory fields are filled in. If they are, it creates a draft record in the transport management system through its API and marks the email as processed. If not, it writes a short summary of what it managed to read and what is missing, and passes it to a dispatcher. We write separately about how such Claude agents work in company processes.
The hardest part was not reading PDFs but addresses: customers write “to our warehouse” or give only a city. The agent compares such cases with the addresses from the customer’s earlier orders, and if the match is ambiguous it sends the order to a person instead of guessing.
Weeks 6-8: oversight and relaxing confirmations
For the first four weeks every record the agent created was confirmed by a dispatcher, with one button, seeing the email and the parsed fields side by side. We collected statistics on where the agent makes mistakes. After that we switched off confirmation for standard forms from regular customers, and kept it for free-text orders and orders from new customers. This is part of our process automation approach: automate as far as trust has been measured, and no further.
Result
Manual entry time in the dispatch office fell by about 65%. We measure it simply: how many orders per day were created by the agent and how many by a person, and how long confirmation takes on average. One of the two employees now mainly works on planning and with carriers instead of on the keyboard.
Errors in orders fell by about 40%. We count cases where a record had to be corrected after loading, and empty trips caused by wrong data. The remaining errors mostly originate in the customers’ own emails, and the agent at least flags them as a mismatch with earlier orders.
Confirmation to the customer is now sent on average within 20 minutes of receiving the email; previously, at peak times it took about 2 hours. Customer calls asking “did you receive it” have almost disappeared.
We were afraid AI would make mistakes that we would only notice at the loading ramp. It turned out the other way around: the agent is the first to notice when a customer sends a different date than a week ago.
What we would advise in a similar situation
- Start from the email history, not from choosing a model. The rules for what counts as an unclear order are the most important part of the system.
- Keep human confirmation from day one and relax it only where the statistics show the agent does not make mistakes.
- Integrate with the existing system through its API rather than building a new workplace: employees need to see the result where they already work.
- Agree on the data terms: where it is processed, how long it is stored, and that it is not used for training. It is the question your customers will ask first.
