What Is Order Batching and When Does It Help?

The short answer

Order batching is combining several customer orders into a single pick tour, so one worker collects the items for all of them in one trip through the warehouse instead of walking a separate trip for each order. It helps most when orders are small, a line or two apiece, because then the walk to fetch them is the dominant cost and spreading one trip across many orders makes that walk cheap per order. It helps least when orders are already large, or when you cannot afford the wait and the sorting it takes to pull a batch together.

The thing to hold onto, and the reason this article sits where it does in the cluster, is what batching is not. Like picker routing, it is a way to make the trip you already have carry more. It does not change where anything is stored. It amortises the walk. It does not remove it. That distinction decides both when batching is the right move and when it is really a sign you should be slotting instead.

What batching actually is

Start with the number batching is trying to move: pick density. Pick density is how many picks a worker makes per unit of distance walked. A tour with high pick density is cheap, because almost all of the effort is the picking you were paying for anyway and almost none is travel. A tour with low pick density is expensive, because the picker walks a long way between a few picks. Small orders scattered across the building are the low-density, expensive case.

Batching attacks that directly. In Bartholdi and Hackman’s words:

Another way to increase the pick density is to batch orders; that is, have each worker retrieve many orders in one trip.

Put ten single-line orders on one cart and send a picker once, and the walk that would have been ten separate trips is now one. The picks per foot walked go up, the travel per order goes down, and you have bought back a large share of the most expensive thing in the building without moving a single pallet. That is the appeal, and for the right orders it is real.

The cost that makes batching a decision, not a default

Here is what the appeal leaves out. When one tour collects items for many orders, those items come back mixed together, and something has to separate them back into the right orders before they ship. That separation is sortation, and it is the cost that turns batching from a free win into a trade.

There are two ways to pay it. You can sort while picking, giving the picker a container for each order on the cart and having them drop each item into the right one as they go. Bartholdi and Hackman are blunt about the price of that: the pickers "must carry a container for each order and they must sort the items as they pick, which is time-consuming and can lead to errors." Or you can sort downstream, picking everything in bulk and separating it afterward, which needs its own space and labour, and at scale a sortation system, which the same text calls an expensive form of automation. Downstream sortation is what makes the most aggressive batching possible: as they put it, if twenty customers all want the same item, you can send one picker to pick all of it in one trip and let the sorter split it out. Powerful, and not cheap.

There is a second cost that has nothing to do with sorting. To batch orders you have to wait for enough of them to accumulate before you release the tour. For most operations that wait is fine. For one that ships on receipt, where an order starts getting picked the moment it lands because a customer has a machine down waiting for the part, that wait is unacceptable. Batching buys travel savings with two currencies, sortation and time, and whether the purchase is worth it depends on how much of each you have to spend.

When it helps, precisely

Because batching is a trade, the useful question is not whether to do it but for which orders. The textbook splits the answer cleanly by order size, and the split is worth memorising.

• Single-line orders: almost always batch. There is nothing to sort, because every item on the tour is a complete order on its own and can often be picked straight into its shipping container. In Bartholdi and Hackman’s words, "It is almost always better to batch single-line orders because no sortation is required." This is the free end of the spectrum, and if you are not batching your single-line orders you are leaving the easiest saving in the building on the floor.
• Very large orders: do not bother. A big order visits so many locations that it already has high pick density on its own, so there is little travel to amortise by combining it with anything. Verbatim: "Very large orders do not need to be batched because they will have sufficient pick density on their own."
• Medium orders: this is the actual decision. More than a line or two, but not enough to fill a dense tour by themselves. As the text puts it, "The problem then is with orders of medium-size." Here the trade is live, and Bartholdi and Hackman state the rule for resolving it plainly: "it is better to batch orders when the costs of work to separate the orders and the costs of additional space are less than the extra walking incurred if orders are not batched." Batch when the sorting and space cost less than the walking you save. Do not when they cost more. And apply the time test on top: only batch if you can wait to accumulate the orders without breaking a promise to the customer.

That is the whole of when batching helps, and none of it required a percentage. It required knowing your order sizes and what your sortation costs.

Batching, routing, and slotting: two of these are not like the third

Batching now sits beside picker routing, from the previous chapter, and it is worth being exact about how they relate, because it is the point of the whole cluster.

Routing and batching are both trip levers. Routing makes a single trip shorter by sequencing its stops well. Batching makes travel cheaper per order by sharing one trip across several orders. Neither one moves anything. Both take the placement of your inventory as fixed and make the best of it. Slotting is the odd one out: it changes the placement itself.

You do not have to take that hierarchy from us. Bartholdi and Hackman lay it out while discussing routing. First, batching softens the need for good routing: "one can reduce the need for pick-path optimization by batching orders, because the larger the batch, the less there is to be gained by optimization." Then, in the very next breath, so does placement: "Similarly, one can reduce the need to optimize by placing product so that the most frequently requested items are stored near each other."

Read those two together and the ranking falls out. Batching reduces how much routing matters. Slotting reduces how much routing matters and how much batching matters, because a tour whose items are already close together needs neither clever sequencing nor a big batch to be dense. And nothing on the list reduces the need for good slotting. Batching amortises a bad layout’s walk across more orders. It never shortens the walk. If your fastest item is in the far corner, batching just means more orders share the punishing trip to reach it, which is better than one order bearing it alone, and far worse than the item not being in the far corner.

Where the batching decision actually comes from

Both levers, batching and slotting, need the same thing to be done well, and it is the asset this whole cluster keeps returning to: the order history.

You cannot know pick density in advance, because it depends on orders you have not received yet. The text says exactly this: "Pick density depends on the orders and so we cannot know it precisely in advance of order receipt." What you can do is read it backward out of the orders you have already filled. A year of order lines tells you your real distribution of order sizes, which is the single-line, medium, large split the batching decision turns on. It tells you which orders would have combined well. And it tells you the thing that drives both levers at once: affinity, which items keep leaving the building together.

Affinity is the hinge. Bartholdi and Hackman’s example is the one everyone remembers:

Pasta and tomato sauce are two skus that have "affinity": Any customer ordering pasta is likely to order tomato sauce. Storing them together may reduce the work to pick the order.

Now watch affinity act on both levers from the same fact. Place the two together, and every future order that contains both is shorter, batched or not. Batch orders that share them, and the shared items sit in the same small area for the whole tour. The pasta-and-sauce relationship is invisible in any single item’s statistics and plain in the order history, and it improves your slotting and your batching in one reading.

One honest caveat, because the same authors give it. Storing affine items together may not reduce travel if orders are so large that the picker has to cross most of the building anyway. Which is precisely the case, very large orders, where batching was unnecessary too. The levers agree on where they stop mattering, and it is the same place.

One scoped note on the system

Dynamics 365 supports wave, batch, and cluster picking as execution mechanisms. It will group released work into a wave, hand a picker several orders to pick in one pass, and direct that pass reliably. That is real and useful and it is not in question here.

What it does not do, and chapter 1 of this cluster showed the same shape when it enumerated the eleven location directive strategies and found none that ranks placement by velocity, distance, or affinity, is read a year of your orders to decide your batching policy or to discover which of your items have affinity. That is analysis you run on your data, not a switch inside the ERP, and the ERP is right not to pretend the analysis is a setting. It executes the batching rule a human derived. Deriving a good rule, and finding the affinity underneath it, is the part left to you.

How to try it this week

Pull a month of order lines and bucket your orders by number of lines: single-line, medium, and large. The single-line bucket is almost pure upside. Group those orders by area and pick them together, and you have captured the easiest saving batching offers with no sortation to pay for.

Then take the medium bucket and do the thing that reads both levers at once. Count, for your busiest items, which other items keep appearing on the same orders. Every pair that ships together often and sits far apart is telling you two things in one line: a batching opportunity you can act on now, and a slotting move that would make the batch less necessary later. Both fall out of the same reading of the same history, and the slotting move is the one that keeps paying after the batch has shipped. The payoff for getting both right lands where every part of this does in the end, more lines out the door per person hour with the crew you already have.

The short version

Order batching combines several orders into one pick tour to raise pick density, the picks you make per foot walked. It almost always pays for single-line orders, because there is nothing to sort. It is unnecessary for very large orders, because they are already dense. It is a genuine decision only for medium orders, where the walking you save has to beat the sortation and space it costs, and only if you can wait to accumulate the batch. Like routing, batching makes the trip you already have cheaper. It does not change where things are. Slotting does, which is why the textbook says affinity placement reduces the need for both routing and batching while nothing reduces the need for good placement. Read your order history and it hands you the batch policy and the slotting moves together. The slotting moves are the ones that last.

For the other trip lever, and why placement beats both, read Should you optimize slotting or picker routing first?.

For the classic rule that decides which items earn the closest slots, read What is cube-per-order index?.

For the full ground-up treatment of the problem this sits inside, read Warehouse Pickup Optimization: The Operator’s Guide.