Mixed-pallet bays: when to allow them, when to ban them

We let it happen for two years and didn't notice.

A bay in the slow-mover aisle starts with one SKU on it. Over time, a pallet of a similar product gets dropped next to it because the bay next door is full. Then someone shaves a couple of cases off a third pallet and tucks them on top because the supervisor said "just for tonight". Two years later you cycle-count that bay and find four SKUs, three of which haven't moved in months, one of which is showing a phantom shortage because someone picked from the wrong stack in August.

That bay isn't a freak. It's every warehouse where mixed-pallet bays are tolerated without rules. And the question isn't whether to allow them — every warehouse already does, somewhere, whether they admit it or not — it's under what conditions.

The argument either way

Mixed-pallet bays — by which I mean a single bay holding more than one SKU, regardless of whether the SKUs are on the same physical pallet or stacked separately — are one of those debates where everyone has a strong opinion and nobody has a framework. The clean-warehouse camp says never: one bay, one SKU, end of conversation. The pragmatist camp says of course: a slow-mover at 0.3 PE shouldn't lock out a whole bay when there's another 0.3-PE SKU that fits next to it.

Both are right inside their own context, and both are wrong outside it. A 50,000-pallet ambient DC with 8,000 active SKUs cannot afford to refuse mixing — the slow-mover tail would eat its bay count alive. A pharma facility with batch-tracked, expiry-controlled stock cannot afford to allow it — one contamination event undoes a year of margin. Most operators sit between those two poles and never write the rules down, which means they get the worst of both worlds: the audit pain of mixing without the capacity benefit, because nobody consolidated deliberately, they just let the floor drift.

This post is the framework I wish I'd had the first time someone asked me whether to flip mixing on or off at the bay level. It comes down to five rules, applied per bay, enforced in the WMS.

The case FOR mixed-pallet bays

The case for mixing is almost entirely about the long tail of slow-moving SKUs.

Fill rate on slow movers. If you have a SKU that ships 2 cases a week and lives on a quarter-pallet, refusing to mix means that bay is 75% air for the next eighteen months. Multiply that by every slow-mover and you've donated a chunk of your usable capacity to nothing. Mixing two or three slow-movers into one bay reclaims that space without changing your rack count.

Bay count for fast movers. This is the second-order effect that operators miss. Bays freed up at the slow-mover end of the floor are bays you can re-slot for fast movers near the dispatch end. The throughput gain isn't from the slow-mover bay — it's from the fast-mover bay you didn't have to add. If you're capacity-constrained on pick face, consolidating the tail is one of the cheapest ways to expand it.

Lower replenishment cost. A slow-mover SKU that lives alone in a full bay has to be replenished from reserve every time the bay drops below pick-face minimum, which means a forklift trip for a SKU that's barely earning. Two slow-movers sharing a bay get replenished together, on the same trip, on the same paperwork. The picker's walk is shorter too because the SKU diversity per bay goes up — same paths, more pick lines.

There's a fourth benefit nobody talks about. Mixed bays make the math of pallet equivalents actually work in practice. If you can't share a bay, "0.3 PE per pallet" is meaningless — you're still consuming 1.0 PE of bay regardless of footprint. PE billing only delivers what it promises when the floor can hold multiple sub-PE units in one location.

The case AGAINST

The case against is real, and the operators who say "never mix" are almost always the ones who tried it without rules and got burned.

Pick errors. This is the big one. A picker walking up to a bay expects to find one SKU. If they find two, the brain shortcut is to grab the one that looks right and move on. If the two SKUs are visually similar — and slow-movers in the same category often are, because slotting tends to put them together — you've just engineered an error opportunity that didn't exist when each bay had one SKU. We had a mix-up between two flavours of the same drink concentrate that ran for three weeks before a customer flagged short shipments. They were on the same bay. Same brand, same bottle shape, label differed by one word. Single-SKU bays would have prevented it.

Cycle count complexity. When a bay holds one SKU, variance is easy: either the count matches the system or it doesn't, and the discrepancy belongs to that SKU. When a bay holds three SKUs, a -2 on one and a +2 on another is almost certainly a pick error between them — but it might not be, and you have to investigate to know. The auditor's job goes from a binary check to a forensic exercise. Multiply by every mixed bay and your cycle-count programme slows down enough that you start skipping locations.

Lot and batch contamination. This is where mixing becomes a hard no. If two batches of the same SKU end up on the same bay and someone picks the wrong one, you've broken FIFO and possibly traceability. If two SKUs with different expiry-tracking rules end up adjacent and a picker grabs from the wrong stack during a recall window, you've just shipped a non-recalled batch as recalled, or vice versa. For food, pharma, and chemicals this isn't a paperwork problem — it's a regulator problem.

FIFO discipline. Even outside lot-tracked products, FIFO breaks down on mixed bays because the rotation logic assumes one queue per location. Two SKUs on one bay means two queues that share a physical space, and pickers default to "whatever's in front" rather than "whichever came in first". A month later you've got a back-row pallet older than it should be and nobody can tell from the system view.

The 5-rule decision framework

Here's the framework. Five rules, evaluated per bay. If a bay passes all five, it can be flagged acceptsMixedPallets: true. If it fails any one, it stays single-SKU.

Rule 1 — Velocity. Only mix slow movers. The threshold I use is fewer than 1 pick per day averaged over the last 90 days, but you can flex this up or down based on your floor. The rationale is simple: pick error rate scales with pick frequency. A bay touched twice a day generates twenty times the error opportunities of a bay touched twice a month. Fast movers belong alone.

Rule 2 — Compatibility. Don't mix high-error SKUs even if they're both slow. The two things that kill compatibility are similar SKU codes (anything where two digits differ — WH-4421 and WH-4412 will get confused, full stop) and similar appearance (same packaging, same colour, same brand family). If a picker has to read a label to tell two SKUs apart, those SKUs don't share a bay. If they have to read the label past the first three characters, they definitely don't.

Rule 3 — Lot and batch. Never mix batched or expiry-tracked SKUs with anything else. Not even with another batched SKU. The moment you put two lot-controlled stock items on the same bay, you've created a recall-blast-radius problem that no amount of careful pickering will undo. The rule is lot-tracked SKUs get their own bay, full stop, regardless of velocity.

Rule 4 — Client. Never mix SKUs from different 3PL clients on the same bay. This is partly about separation of duties — if Client A's stock is on Client B's bay and Client B's stock goes missing, the conversation gets ugly fast — but mostly about cycle-count attribution and billing. You cannot run pallet-equivalent billing cleanly if two customers share a footprint. Even if the SKUs are otherwise compatible, client separation is non-negotiable.

Rule 5 — Audit cadence. Mixed bays get cycle-counted twice as often as single-SKU bays. If your standard cadence is quarterly, mixed bays go monthly. If you're on an ABC-class schedule, mixed bays bump up a class. This is the rule operators forget, and it's the one that makes the whole framework safe — you accept slightly higher error risk in exchange for capacity, and you offset the risk by catching variance earlier. The detail on how to structure this lives in the cycle count playbook.

A bay that passes all five — slow, visually distinct, non-lot-controlled, single-client, on the elevated audit list — is a legitimate mixed bay. A bay that misses any one is single-SKU and the WMS should refuse a second putaway.

How to enforce in your WMS

The framework is only worth writing down if the system enforces it. Otherwise it lives in someone's head and breaks the day they leave.

The minimum data-model change is a bay-level flag:

bay.acceptsMixedPallets: boolean
bay.mixingReasonCode: enum (slowMover | velocityException | null)
bay.lastMixedAuditAt: timestamp

Around that flag, three pieces of logic:

Putaway. When a putaway operator scans a bay and the bay already holds a SKU different from the one they're placing, the system checks acceptsMixedPallets. If false, the putaway is rejected with a clear message ("Bay holds SKU-1234, mixing not enabled — re-route?"). If true, it checks the five rules — velocity class of both SKUs, lot-tracking flags, client codes, similarity score on SKU codes — and either allows the putaway or rejects with the specific failing rule.

Pick. When a picker arrives at a mixed bay, the pick screen forces a confirmation step: it shows the SKU code and a description, and the picker has to tap to confirm before scanning. Single-SKU bays skip this. The friction is the point — it slows the picker for the two seconds it takes to defeat the autopilot that causes the wrong-SKU grab.

Cycle count. Mixed bays get a count_priority boost on the cycle count generator. The system schedules them at 2× the normal cadence and flags variance investigations as "mixed-bay — check pick attribution before assigning to SKU."

If your WMS doesn't enforce mixing rules natively, the next-best thing is a putaway location list that's manually curated: a sheet of bay codes that are permitted to mix, refreshed monthly. Pickers and putaway staff are trained to refuse mixing on any bay not on that sheet. It's worse than software enforcement because people drift, but it's better than nothing, and it's the same intermediate step the warehouse installations flow walks operators through when they're migrating from spreadsheet-driven slotting.

The real-world reset playbook

Most operators reading this aren't starting from a clean floor — they're starting from two years of accidental mixing that needs unwinding. Here's the reset that actually works.

Week 1 — Audit. Run a full bay scan. Tag every bay that currently holds more than one SKU. Don't try to fix anything yet, just count. In most warehouses the number is two to three times what the supervisors think it is.

Week 2 — Classify. For each mixed bay, evaluate against the five rules retroactively. Bays that would pass the rules get tagged legitimateMixed. Bays that fail get tagged unwind. Lot-tracked bays that have somehow ended up mixed get tagged urgent and dealt with first.

Weeks 3–6 — Unwind. Work through the unwind list one bay at a time. Move the lower-velocity SKU to an empty bay, leave the higher-velocity SKU where pickers already expect it. Don't try to optimise the whole slotting at once — the goal is to clean the violations, not re-plan the floor. If you don't have empty bays, this is the moment you find out how much capacity the mixing was masking.

Week 7 — Flag and enforce. Set acceptsMixedPallets: true on the surviving legitimate bays, false on everything else, and turn on the putaway block. Tell the floor what's changed and why.

Week 8 onwards — Audit cadence. Elevated cycle-count schedule kicks in on the flagged bays. Variance on a mixed bay is now a signal to investigate; variance on a single-SKU bay is the usual quarterly check.

The reset takes about six weeks for a 5,000-bay site. The capacity recovery — bays you didn't know you had because they were holding 0.3 PE of slow stock — usually pays for the project inside the same quarter.

---

Mixed-pallet bays aren't good or bad. They're a tool with five rules and a configuration flag. The warehouses that refuse to use the tool give up a meaningful slice of their capacity. The warehouses that use it without rules give up a meaningful slice of their accuracy. The ones that thrive treat it the way they treat any other operational decision — define it, configure it, audit it, move on.

If you're configuring this from scratch and want bay-level mixing flags as a first-class part of the data model, that's how Loaditude's warehouse installations are wired by default — acceptsMixedPallets is on the bay record, the putaway rules read it, and the cycle-count engine knows to count those locations twice as often.