Warehouse Slotting Optimization

A combined-velocity ABC classification and a greedy heuristic derived from a thirteen-constraint mixed-integer formulation, run against 370,000 pick records. Constraints enforced exactly where physical, relaxed with documented rationale where intractable, and named explicitly where not modeled. A two-week intuition cycle replaced by a five-minute optimization run.

---

The Problem

I had done Crest Hill the year before, the way the discipline asks an OPEX Manager to do it: data pull, XLOOKUP join, pivot, intuition-weighted velocity score, A/B/C cutoffs, sorted list, intuition-based slot assignment, operations discussions, WMS handoff. The plan was defensible by the standard of the discipline. It was also the project that convinced me the discipline was asking the wrong thing.

The site itself is a regional cold-storage facility supporting a single national food manufacturer, with one secondary raw-materials customer running at 5% of volume. Annual slotting refresh is the network standard — the item master and the velocity profile shift enough year-over-year that last year’s plan stops being the right plan. The SOP calls for quarterly refresh. In practice the cycle is so labor-intensive that quarterly never happens; sites run on annual at best, and many run on multi-year.

The manual cycle works like this. The OPEX Manager pulls discrete inventory data, item master, and picking history for the site. The item master and pick records get joined in Excel through XLOOKUP. A pivot table builds three column blocks per item: monthly pick frequency, monthly picked quantity, and replenishment frequency derived from the item’s TiHi and case weight. Each block gets a weight — chosen by the IE, sometimes adjusted by site operations, always by intuition — and the weighted average produces a velocity score. The velocity score gets cutoffs to assign A/B/C class. The items get sorted. Then the real work begins: figuring out which items go in which zones, which zones get which physical positions in the facility, which slots within each zone get which items, all under fuzzy goals of reducing travel time, increasing UPH, and minimizing aisle congestion. That step looks like a single line on a project plan. In practice it consumes weeks of iteration, site discussions, calendar alignment with operations, and revised drafts.

The Excel work itself takes a few hours. The slotting decisions and the operational discussions take a month. The full cycle, from data pull to WMS handoff, runs multi-week — every time, at every site, every year. Across a network of 100-plus sites, this is hundreds of OPEX Manager hours per year producing slotting plans whose underlying logic — the velocity weights, the slot assignments — has no formal mathematical defensibility beyond the IE thought it was right.

The conventional response to this kind of pain is to make the manual process more efficient. Better templates, shared Excel macros, a network playbook, a velocity-scoring spreadsheet with weights filled in by the corporate office instead of by each IE. All of which would compress the cycle modestly without changing what the cycle actually produces. The cycle produces an intuition-driven slotting plan. A better template produces a faster intuition-driven slotting plan.

What stayed with me from doing Crest Hill the first time was a different question. Warehouse operations is structurally an engineer’s discipline. It has objective functions — travel distance, throughput per hour, labor minutes per pallet. It has hard constraints — slot dimensions, weight limits, temperature compatibility, zone capacity. It has soft constraints — co-location, congestion, ergonomic accessibility. Every piece of the discipline lines up with the standard vocabulary of operations research. And yet the people doing the work across a 100-plus-site network were doing it in Excel, weighting things by feel, defending the result by seniority. The question I started asking was whether the gap between the discipline as it’s practiced and the discipline as it could be was a tooling gap, a methodology gap, or something deeper.

---

The Reframe

The manual cycle isn’t one process with a tractability problem at the end. It has two — one at Step 4, one at Step 7 — and the manual process crosses neither.

The first wall is the velocity score itself. Three measurement dimensions go into it: monthly pick frequency, monthly picked quantity, and replenishment frequency. Each dimension answers a different operational question. Pick frequency tells you how often a picker visits the item. Picked quantity tells you how much labor each visit consumes. Replenishment frequency tells you how often a forklift driver crosses the facility to refill the slot. All three matter. None of them dominates a priori. The IE collapses them into a single score with a weighted average — and the weights are chosen by feel. Sometimes the site operations team adjusts the weights, also by feel. Two IEs working the same data set, by the same SOP, will produce different A/B/C classifications. Both will be defensible by the standard of the discipline. Neither will be reproducible from first principles. This is the form of analytical work — weighted scores, sorted outputs, math notation — applied to a foundation that nobody has shown is correct. It is operations research as performance, not as practice. Done at network scale, the same weighted-composite method runs at every site every year, and the question of which dimension should dominate the velocity score for a given site, a given product mix, a given facility layout, never gets asked.

The second wall is the slotting decision that follows. Once items are sorted by velocity, the OPEX Manager has to assign them to physical positions in the building — which items to which zones, which zones to which aisle clusters, which slots within each aisle to which items. The objective is some combination of minimizing travel distance, maximizing throughput per hour, and minimizing congestion. The constraints are real and well-known: slot height feasibility, weight limits, zone capacity, co-location preferences for items frequently picked together, temperature compatibility. This is a discrete assignment problem with a defined objective, named constraints, and a fully populated parameter set. It is, mathematically, a mixed-integer optimization problem. Written out formally for Crest Hill specifically, the formulation runs to roughly nine million binary decision variables under thirteen constraint families. That problem size is well outside what any commercial solver returns in a deployable timeframe. Exact solution is not on the table. The IE solves it by intuition, by experience, by precedent from how the site looked last year, by site operations pushing back on individual assignments — by every method other than the one the structure of the problem actually calls for.

Naming the walls explicitly changes what the project is. The reframe isn’t “build a tool that does the manual work faster.” The reframe is “the manual work has been crossing two intractability walls without naming them.” Step 4 has been crossed by laundering intuition through a weighted composite. Step 7 has been crossed by replacing math with judgment. Both walls are real. Both have been crossed informally for as long as the discipline has been practiced. Neither will be crossed formally without the engineering work being done at the foundation rather than the surface.

The principle that emerges is the one Section 2 was circling. Warehouse operations is structurally an engineer’s discipline, and engineering disciplines have a particular shape — sets, parameters, decision variables, objective functions, hard constraints, soft constraints — that’s explicit, named, and defended. The shape isn’t a stylistic preference. It’s what makes the work reproducible across practitioners and reviewable by peers. The Crest Hill project, from this point forward, was an exercise in giving warehouse slotting that shape. Not in automating the manual process. In replacing it.

---

The Approach

The approach was to rebuild the manual nine-step process from the engineering shape Section 3 closed on — sets, parameters, decision variables, objective functions, hard and soft constraints, all explicit and named. Not every constraint could be respected exactly. Not every operational factor would be modeled at all. But every relaxation would have documented rationale, and every omission would be acknowledged rather than hidden. That distinction — named versus anonymous, explicit versus tacit — is the substance of the engineering claim.

The codebase reads warehouse slot data, item master, inventory snapshot, and seven months of discrete pick and putaway records — 370,000 movement rows. Travel times between slots are not estimated by eye or by aisle position; they come from the WMS routing graph itself, computed in TMUs from inter-intersection distances and machine velocity and retrieval factors. The manual workflow has access to this same graph; the code is what actually uses it.

Stage 1 produces the velocity classification. A composite score combines movement-row volume (40% weight) and distinct-assignment trips (60% weight), both percentile-normalized to compress heavy-tailed throughput. The weights are explicit, validated to sum to 1.0, and applied uniformly across every SKU. Two engineers running the same data produce identical A, B, and C labels. This is still a weighted composite — the discipline doesn’t yet derive these weights from first principles. The substantive change from the manual process is not the absence of judgment; it’s the explicit constraint and exposure of judgment. Disagreement about the weights is now a conversation; in the manual process it was a shrug.

Stages 2a and 2b implement the slotting heuristic. There is no MILP solver in the code; exact solution at site scale is intractable in any deployable timeframe. The heuristic is greedy — items processed in velocity-rank order, slots sorted by distance from the dock, the closest height-feasible empty slot consumed by each SKU in turn. Stage 2a routes case-pick SKUs (those whose case-pick activity exceeds 75%) to floor-level bays under 58 inches z-height in aisles closest to the freezer doors, with co-picked SKUs clustered into shared aisles by majority-vote and spilling when an aisle is full. Stage 2b partitions the remainder into velocity-tiered pallet zones balanced to equal share plus a small capacity buffer.

The constraint inventory is the methodological heart of the section. The code enforces or relaxes thirteen constraints, organized into three categories:

Eight constraints are enforced exactly — the cases where the math has clean answers. Three are relaxed because exact enforcement is intractable or impractical at site scale, each with explicit rationale: co-location affinity becomes greedy majority-vote clustering, demand satisfaction relaxes to flagging under-allocated SKUs rather than failing the run, and the travel-distance objective becomes greedy slot ordering rather than a solved optimum. Two operational concerns are not modeled and named so — weight-based ergonomic placement, and lot or FEFO storage rules — both deliberate scope choices for the current build.

The savings calculation runs in travel-time units. Current-state travel is summed from real discrete movement rows — every actual pick and putaway in the data window, distance lookup per slot, no aggregation. Optimized travel uses zone-average distance times zone frequency for pallet movement and sums item-to-item distances replayed across real assignment sequences for case-pick movement. The delta converts to hours via the WMS routing graph’s standard TMU divisor, scales to quarterly figures by working-week and work-day parameters, and translates to an annual dollar figure against the site-specific wage rate — every assumption named.

LLM-assisted development was the velocity multiplier for the build, in the same disciplined sense as the first two case studies. The pipeline architecture, the constraint decisions, the heuristic design, the data validations, and the savings methodology were mine; the syntax was generated under direction. What the compression unlocks operationally is the change in cycle interactivity. A multi-week manual process across more than 100 sites a year compresses to a five-minute optimization run; the operational discussion still happens, but with the model in the room rather than in calendar-aligned increments separated by re-runs.

---

The Result

The optimization was validated against the most recent week of pick activity at the site and produced an annual labor recovery of approximately $136,000 at the site’s wage rate of $27.60 per hour — roughly 4,940 hours of travel time eliminated each year against a current-state baseline producing 258 hours of pick and putaway travel across the validation window.

The savings break down by movement type, each with its own mechanism. Putaway travel drops from 95.3 hours to 58.4 — a 39% reduction — through velocity-tiered pallet zones placing high-frequency SKUs in the closest available height-feasible slots. Pallet-pick travel drops from 98.3 hours to 46.1 — a 53% reduction, the largest of the three — reflecting that the manual layout had high-velocity pallet movers scattered through zones organized primarily around inventory capacity rather than pick distance. Case-pick travel drops from 64.9 hours to 43.2 — a 33% reduction, the most modest because case-pick was already roughly velocity-clustered in the manual layout; the heuristic refined the assignments rather than restructuring them.

Two methodological notes belong in this section. First, every SKU in the run — 315 pallet-pick and 572 case-pick — was fully slotted; the demand-satisfaction relaxation discussed in Section 4 (R2) is built into the code as a fail-soft mechanism but didn’t fire on this run, because the site’s slot capacity was adequate for the SKU set. Second, the savings figure is computed entirely from the WMS routing graph’s actual slot-to-slot travel distances, replayed against real discrete pick assignments — not estimated from typical-case assumptions. Every per-pick distance is grounded in the same network the WMS uses for live routing.

What the run does not include is a benchmark decomposition. Current state versus optimized is the only comparison the code presently produces. Random-zoning and pure-ABC-without-distance baselines — the comparisons a journal reviewer would require to isolate the contribution of velocity classification versus the contribution of distance-aware slotting — are not yet built. The $136,000 figure represents the total improvement the heuristic claims against the live layout, without that decomposition.

The slotting plan has been generated and validated against the most recent week of pick activity. The WMS handoff that converts the plan into live pick paths — the step where the recommendations actually change how pickers move through the facility — remains a decision. What does not require deliberation is the engineering itself. Every constraint is named in writing. Every relaxation is rationalized in writing. Every parameter is in version control. Site leadership reviewing the plan is reviewing math that argues for itself, not a recommendation that asks to be trusted. The engineering work is done; the operational adoption decision belongs to the site.

---

The Reflection

Engineering is the practice of writing down what intuition refuses to say out loud.

The senior operator knows the pallet has to fit the slot. Knows the heavy SKU shouldn’t go on the top rack. Knows which SKUs are picked together. None of it is written. None of it survives the operator leaving the building. The engineering version names every one of those — height feasibility as a hard constraint, ergonomic placement as a deliberate scope choice, co-location as a relaxed constraint with documented rationale. The substance isn’t that engineering handles more than intuition. It’s that engineering can be argued with, audited, transferred, improved. Intuition cannot. The work that survives the engineer leaving is the work that was written down. The rest leaves with them.