AI in the warehouse: where it helps and where to start

AI in the warehouse today mostly takes over office work around the floor. By AI this guide means software that reads text and messy data and checks it against your agreements. Robots and self-driving forklifts are part of warehouse automation too, but they stay outside this guide. At a 3PL or in contract logistics with a working WMS, the gain is usually in the work that is still done by hand. Think of the orders someone retypes from email into the WMS every morning. Or the planner who first converts the files of six clients into one format every morning, because every client uses their own columns and their own item codes and the WMS accepts only one format.

Where does AI actually help in a warehouse?

In the administration around the floor. Anywhere someone moves data from one place to another, or lays two lists side by side to see if they match.

A language model reads an email, a PDF or a messy spreadsheet roughly the way a person does. It understands that “plt”, “pallet” and “euro pallet” mean the same thing for this client. Ordinary code then checks what the model read against the agreements: does the item number exist, does the quantity fit, does this delivery address belong to this client. A classic integration breaks the moment a client moves a column. A model reads past that. The checks behind it catch what it reads wrong.

What we build sits mostly in four of those places.

Orders from email, PDF and Excel

A client emails an order as an attachment. Someone in the office opens it, types the lines into the WMS and checks that each item number exists. At ten orders a day that is manageable, but the work grows in step with the volume. A typo becomes a wrong pick that you only notice when the client calls about the wrong box. A system can read the order, check it against the agreements with that client and stage it in the WMS. Anything it is unsure about goes to a queue where a person looks at it. How that works in practice is in orders from email into your WMS.

Connections between WMS, TMS and ERP

Every client and every carrier delivers their data differently. One sends EDI, another a spreadsheet by email. Often a separate connection was built for each client, so every new client is a new build. One layer that translates all those messages into what your WMS, TMS and ERP expect turns a new client into a matter of configuration. See connecting WMS, TMS and ERP.

Work that never reaches an invoice

A return that was put back into stock, or a rush delivery on a Friday afternoon. The work was done and is recorded somewhere, but it never makes it onto the invoice to the client. Nobody notices, because the handling sits in the WMS or on a job sheet while the invoice is made in the ERP. Nobody lays those two side by side every day. A system does, and puts what is missing on a list for the controller. More in finding unbilled work.

Invoices from staffing agencies

Many warehouses use temporary staff from more than one agency. Each agency sends its own invoice with hours, allowances and rates. Checking them is often a spot check, because nobody has time to lay every line next to their own clock data, certainly not when a new pile arrives from several agencies every week. A system compares every line and shows only what differs. See checking agency invoices.

What these four share: the data already exists and the agreements are on paper. So the system has nothing to guess. It reads and compares, and a person decides on whatever does not match.

Where AI will not help your warehouse

In planning and in the layout of the warehouse itself. Good packages exist for those, built by companies that do nothing else. A language model is good at reading text and messy data, but the shortest route past forty addresses or the best location for a fast-moving item is a calculation it was not made for.

• Route planning. Your TMS or a planning package is better at it. What does help: making sure the orders and addresses going into it are right.
• Slotting, the allocation of items to locations in your warehouse. That is optimisation maths as well, and specialist software exists for it.
• Staff scheduling. Who is on the floor when depends on contracts and on people. That stays with your planner and their software.
• Replacing your WMS. Choosing and implementing a new WMS is a different kind of project altogether. You build AI into the system that is there, in the seam between the WMS and the client.

If everything is already connected and nobody retypes anything, there is little to gain. If someone promises one AI system that replaces your planning and your WMS in one go, you are buying a project with no end in sight. Who we build for shows where we draw the line.

Which process should you start with?

The one where most hours now go into retyping and checking. It is tempting to pick whatever sounds best in a board presentation, such as a chatbot for customer questions. Meanwhile someone in the office retypes orders every day that appear nowhere in that presentation. Work that comes back daily pays off more than something that comes up once a quarter.

You do not have to guess those hours. Ask the people in the office to log where their time goes for one week, in blocks of a quarter of an hour. Then add it up per process. For the biggest items, also look at how often something goes wrong and what a mistake costs, because a process that takes few hours but produces an angry client every month can still be the best place to start. A good first process looks like this:

• The work comes back every day or every week, in roughly the same form.
• The data is already somewhere: in an email, a file, the WMS or the time clock.
• There is an agreement to check against, such as a contract or a rate card.
• A mistake costs money or causes a complaint. Then you can show what the system delivers once it is built.

If you do not know yet what you want from AI, start with the log anyway. The first process follows from what you count.

Why one process at a time?

Because only after the first process do you know whether it works with your data. A system that can do everything on paper trips over the client who sends item numbers with a leading space. Or over the carrier whose file layout shifts a little every month. You only find those things by building and running.

Build four processes at once and after six months you do not know which part works and which does not. If orders land in the WMS correctly more often while invoicing still wobbles, you can no longer tell which change did what. Your people have to learn to trust four things at the same time. If it disappoints, all of it disappoints.

With one process it stays clear. You measure up front how much time it takes and how often it goes wrong. After the build you measure exactly the same thing again. If it adds up, you talk about the next process. If it does not, you know where the problem is and you have not spent more than you needed to.

The second process usually goes faster. The connection to the WMS is already there, your people know the queue for doubtful cases and you have figures from the first step. That is how a system grows step by step that fits the way your company works. A standard package usually asks the opposite: that your company adapts to the package. That trade-off is the subject of bespoke or standard software.

What does a first step look like?

Small and tightly scoped, around that one process. This is how it runs with us, and how we work has the details:

1. A free 45-minute call about where the manual work sits in your operation. Your week of logging helps here.
2. We pick the process and measure how it runs today: how much time it takes and how often something goes wrong. That is the baseline.
3. What the system must do goes on paper, with a fixed price agreed up front. You approve it before we build. If the system falls short, the final instalment lapses.
4. We build in the systems you already have and roll it out with your own people. They stay in the WMS and the inbox they know, with no new login.
5. The system first runs alongside the existing work. A person checks everything it proposes until it has proven itself on your data.
6. Then we measure again, the same way as the baseline. Only once this process works do we talk about the next one.

If the system touches employees' hours or attendance, for example when agency invoices are checked against clock data, bring in the works council early. Article 27 of the Dutch Works Councils Act gives the council a right of consent over arrangements for facilities suited to monitoring the attendance, behaviour or performance of employees. Settle that at the start, so it does not hold you up when the system is ready.

What should you ask a supplier of AI applications for logistics?

Ask about the concrete process and about what happens when it goes wrong. Every question below deserves a short answer, from us as well.

• Which process do you build first, and why that one?
• How do we measure how it goes now, and how do we measure later whether it is better?
• What happens to an order or invoice line the system is unsure about?
• Do my people have to work in a new system, or does the work stay in the programs they already use?
• Where is my data kept, and is it used to train a model?
• Can I take my data and the output with me if we stop?
• What happens to the payment if the system does not do what we agreed?
• Who else pays you? A supplier who also gets money from your staffing agency or your software vendor looks less closely.

Pay most attention to the answer about measuring. If that is vague, or all you get is a percentage the supplier says they reached at another company, you will not know after the build whether it delivered anything for you either.

You can bring that list as it is to an introductory call with us.