Orders from email, Excel and PDF into your WMS automatically

Automated order processing from email means a system reads the orders your clients send, as email text, Excel or PDF, and puts them into your WMS without anyone retyping them. It maps the lines to the article codes in your WMS and checks them against the agreement with that client. If everything matches, the order is ready. If the system is in doubt, the order goes to a review queue where someone on your team looks at it.

What changes in the office?

Today your office staff do that by hand. Every morning they open the shared inbox, find the attachment, retype the lines and release the order to the floor. With three clients that is manageable. With ten clients who each send their own file, it can turn into a full-time job. And you only spot a typing error once the wrong box has left the building and the client rings to ask where the other item went.

Nothing changes for your clients. They keep emailing, sending Excel files or forwarding a PDF from their own system. The change happens on your side of the inbox.

Which orders can be read automatically?

Almost anything a person can read. The messier the source, the more often an order ends up in the review queue.

• An Excel file with fixed columns is the easiest. The system learns the columns once and then reads every line.
• A PDF from your client’s ERP usually has the same layout every time. It reads almost as reliably.
• An order written in the body of an email, such as a request to send forty boxes of the blue item tomorrow, takes more. The system has to find the item itself, and an order like that goes to a person more often.
• A scan or a photo of an order form is the hardest. Reading usually works, but a smudge on a quantity turns a 3 into an 8.

If a client already sends orders through EDI or an API, there is nothing to read. That traffic belongs in a fixed connection, which is what connecting WMS, TMS and ERP covers.

Fulfilment orders often carry a consumer’s name and address. Under the GDPR that is personal data, so the mailbox and the system that reads it fall under the same rules as your WMS. With us that data stays inside the EU and is never used to train models.

What does the system check an order against?

Against the agreement you have with each client. It sits in a contract, in a service description or sometimes only in the head of your planner, who after years knows exactly which client takes no deliveries on a Friday and who orders by the box while the WMS counts single items. Before we build, we write it out line by line. After that the system asks every order the questions your planner asks today.

• Does this article code exist for this client, and is it your WMS code or the client’s own?
• Is the unit right? Six items or six boxes of six is a difference of thirty items.
• Did the order arrive before the cut-off, or does it move to the next day?
• Is the delivery address complete enough for the carrier?
• Is the same order already in, because the client sent it twice?

An order that matches on every point goes through. If it differs on one point, it goes to the queue with the reason attached. Whoever picks it up sees straight away where to look, without reading the whole order again.

What goes wrong when you process orders automatically?

Three things need settling before the system goes live.

Article codes that do not match

Your client orders with their own code, or with their supplier’s. Your WMS knows a different one. There is usually a translation table, in Excel or in someone’s head. The system uses that table and never guesses at a code it does not know. That order goes to the queue. Whatever your team chooses there goes into the table for next time.

A client who changes their format

Your client moves to a new version of their ERP, adds a column to the Excel file or sends a PDF with a different header. To a person that hardly matters. A system that reads fixed positions then picks up the wrong column, and suddenly there is a postcode in the quantity field or a line attached to the wrong order. That is why our system also checks the shape of the file. If that differs from what this client normally sends, it stops and says so.

Partial deliveries and backorders

An order for two hundred items comes in while a hundred and twenty are in stock. What should happen depends on the agreement: ship the rest later, hold the whole order or call the client. The system does not decide that on its own. It checks the order against the stock in the WMS, sees the shortage and puts the order in the queue with that question. Only when the agreement already gives the answer does it follow it.

Why does a person stay in the loop?

Because a mistake in an order is immediately a mistake on the floor. The wrong item leaves the building, and your client notices before you do.

So at the start nothing goes through on its own. For the first few weeks someone on your team sees every order the system prepares, including the ones that are right. Only once the system has shown on your own orders that it reads them well, which we measure by the number of corrections in the queue over a few weeks, do orders without a deviation go straight through. You decide that per client. One sends tidy Excel files, another sends scans.

The queue is also where the system gets better. Every choice your team makes there, about an article code, a unit or an address, becomes a rule for the next order. And the number of orders that land in the queue tells you how well it works.

How do you measure whether it pays off?

With a baseline before the build starts. Without it, all you know after three months is that things feel different. Spend a few weeks counting what you can already count.

• The number of orders each week, per client and per format
• The hours your people spend each week entering orders and chasing details
• How many orders need correcting afterwards, and why
• How often an entry error only surfaces at the customer or in a return

Then you count the same things with the system in place, plus the share of orders that lands in the queue, so you can see whether the work has really left the inbox or has only moved to another screen. Put the error rate before and after next to the hours. A system that saves hours and lets more errors through is not an improvement.

With us that target is on paper before the build begins, with a fixed price agreed up front. If the system misses it, the final instalment lapses. How that works in phases is in how we work.

One client first, then the next

Pick a client who generates a lot of manual orders and sends them in a fairly fixed format. Build that first and let it run for a few weeks while you measure what it does. If it works, add the next client. That one goes faster, because the checks and the queue are already in place. For that first client you get four things ready:

1. A pile of recent orders as they arrived, with the corrections you made afterwards.
2. The translation table from their article codes to your WMS codes, even if it now lives in someone’s head.
3. The agreement with them, written out: cut-off, units, delivery days and what happens when stock runs short.
4. One week of counting, as in the baseline above.

An off-the-shelf package for order entry can also work, especially if all your clients send the same thing. Where that stops working is covered in bespoke or standard software. What we build besides order entry is on what we do, and where AI does and does not help in a warehouse is in AI in the warehouse.

Bring that count to an introductory call and we will work out what retyping costs you now.