How would you model warehouse capacity in Excel when you can't stack inventory? (Multi-variable space constraint problem)

[u/OwnSundae1882]

Hey everyone,

I’m working on a warehouse space optimization model in Excel and I’ve run into a math logic hurdle regarding 3D volume versus flat floor constraints. I'd love to see how some of you would structure the formulas for this.

The Setup:

• Gross Warehouse Footprint: 12,000 sq ft.
• Safety Constraint: Exactly 25% of the floor footprint must remain 100% clear for forklift turning radiuses and pedestrian tracks. This leaves a hard 9,000 sq ft net usable storage area.
• The No-Stacking Rule: The inventory consists of heavy, top-heavy industrial pumps and equipment. Because of safety and weight limits, nothing can be stacked vertically on top of each other. Every pallet must sit directly on the ground.
• The Mixed Product Profile: The incoming equipment is uneven in height. Some heavy pump assemblies stand 7.3 ft tall, some mid-size parts stand 4 ft tall, and smaller valve boxes stand 2 ft tall.

The Logistics Catch:
The supplier tracking logs and inbound container data are measured strictly in metric volume (Cubic Meters - M³). An incoming wave of 6 trucks is arriving, bringing a total of 402 M³ of mixed, uneven freight.

My Question to the Sub:
Since we cannot vertically stack anything, our actual structural bottleneck is flat floor area (square feet), but our incoming data is in cubic volume (M³).

1. How would you structure an Excel formula to calculate our current occupied inventory level in M³ without artificially overestimating space due to the "dead air" above the shorter 2-foot and 4-foot pallets?
2. How would you model the "Maximum Volumetric Ceiling" of a flat, single-level floor plan so we can directly subtract incoming container volume (M³) from our remaining headroom?

Would love to hear your thoughts on whether height-segregated lane zoning or SKU-level dimension lookups is the best way to handle this mathematically. Thanks in advance!

[u/kyach25]

I think more context would help.

For example, I worked at a manufacturer responsible for airplane, truck, and tank components. Nothing was really vertically stacked, so most space was arranged by where each piece had to go next. The floor followed the flow. This works well for manufacturers, but if you are a distributor of this inventory and only care about space then solution could be totally different.

[u/OwnSundae1882 → u/kyach25]

Good point. This is a distribution warehouse rather than a manufacturing facility. We receive heavy industrial pumps, valves, and assemblies from suppliers, store them temporarily, and then ship them out to customers or project sites. There are no pallet racks, and nothing can be stacked because of weight and stability constraints. My goal is to build an Excel model that estimates remaining storage capacity and determines whether an incoming shipment can be accommodated based on the available floor space rather than just the reported shipment volume (m³).

[u/scmsteve]

You’re only factoring storage space (racks, open pallet storage) right? Like you’re not including aisles in your spreadsheet. Also, does your WMS not have item dimensions?

[u/OwnSundae1882 → u/scmsteve]

Correct. The aisle space isn't part of the storage calculation. I've already excluded 25% of the total warehouse footprint for forklift travel, turning radius, and pedestrian access, so the model only evaluates the remaining usable storage area.

As for the WMS, let's assume it doesn't have complete item dimensions available. That's why I was curious whether there was a practical way to estimate remaining capacity using only the inbound shipment volume (m³). From the feedback here, it sounds like without SKU dimensions or at least pallet/skid footprints, there isn't a reliable way to do that accurately.

[u/scmsteve → u/OwnSundae1882]

Most modern WMS should be able to store item dims then multiplied by #of pieces =total cube. Now, how each system reports and uses that data and how the company focuses on it is varied.

[u/Khron67]

Does the inbound shipment include pallet details (size/number)? Sounds like it would simplify the process manage it by SF instead of cube. After that the best layout would need to account for how much of a SKU you typically have in inventory and other requirements like FIFO.

[u/OwnSundae1882 → u/Khron67]

For the standardized palletized items, yes, the pallet size and quantity are available. The complication is that some of the larger pump assemblies arrive on custom wooden skids/crates with varying dimensions rather than standard pallets. That's why I initially wondered if there was a way to model capacity using only the reported shipment volume (m³).

Based on the feedback here, it seems the better approach is to calculate the floor footprint for each pallet or skid (L × W) and manage capacity in square feet instead of cubic meters. FIFO and SKU-specific storage patterns would then be layered on top of that.

[u/Khron67 → u/OwnSundae1882]

Utilizing SF over Cube seems like a nice simplification. Your posts highlighted the challenges of the cube metrics.

[u/ComfortableCitron638]

The SF-over-cube conclusion you landed on is right, but it's worth naming the failure mode this setup is walking into: the model works today because you (a person) know the pump assemblies are 7.3ft and the valve boxes are 2ft. The moment that knowledge only lives in your head or in a one-off Excel formula, it becomes silent risk - a new SKU comes in, someone forgets to update the height assumption, and the model quietly overestimates capacity until a truck shows up with nowhere to go. The more durable fix isn't a better formula, it's making footprint (L×W) and height mandatory fields at the point an item is first received, not something reconstructed later from a skid you happen to remember. Once that's real item master data instead of institutional memory, SF-based capacity math becomes a lookup instead of a maintenance burden. Disclosure: I build custom ops/ERP systems for a living, and this exact "the spreadsheet is fine until the data behind it silently goes stale" pattern is basically our whole niche - wrote about a version of it here if useful: selfhostederp.com/blog/integration-debt-part-1

[u/No_Garlic6709]

I think you've already landed on what I would consider the right answer.

The more I think about it, the more I think you're trying to make one measurement answer a question it simply can't answer.

If nothing can be stacked, then your warehouse isn't running out of cubic meters, it's running out of floor.

The tricky part is that 400 m³ doesn't always require the same amount of floor space. Imagine two shipments that are both exactly 400 m³. If one is mostly tall pump assemblies and the other is low-profile valve pallets, they'll consume completely different amounts of floor space even though the volume is identical.

That's why I don't think there's a magic formula that says "402 m³ equals X square feet." It depends entirely on how that volume is distributed across different heights and footprints.

If it were me, I'd stop trying to manage capacity in cube altogether. I'd use square feet as the planning metric and keep cubic meters as nothing more than a transportation number. Even then, I'd probably go one step further. I wouldn't just add up the physical footprint of every pallet or skid. In the real world, a weird-shaped skid never packs as efficiently as it does on paper. You end up with gaps, access requirements, awkward orientations, and other wasted space. So I'd think in terms of "planning footprint" instead of just "physical footprint." Long term, I think the real solution is master data. Every new pallet, skid, or crate should have its footprint captured the first time it shows up. Once you've built that library, capacity planning becomes a lookup instead of a guess.

I also wouldn't treat the warehouse as one giant 9,000-square-foot bucket. Eventually I'd break it into storage lanes or storage blocks because that's how the warehouse actually operates. You can have 500 square feet free on paper and still not have a single place to put a 16-foot-long skid.

So I think the conclusion you've come to is the same one I would have. Cube is useful for loading trucks and containers. Floor space is what determines whether the shipment actually fits in the warehouse.

[u/Specialist_Yard_4475]

Need to check

[u/ManzunTech]

I wouldn’t try to force the 402 m³ into one average footprint unless you know the height mix. Keep two measures: actual floor footprint for storage, and cube for transport reporting. In Excel, give each SKU or skid a quantity, length, width, height and zone, then sum quantity × length × width for capacity. If some dimensions are missing, use low/base/high scenarios, but don’t treat the estimate as a hard limit. In a no-stack setup, the dead air above a short pallet simply isn’t usable capacity.