Thursday, 14:10. A trucker is at the gate for MSCU1234567. The inventory sheet says Available. The clerk sees the unit three-high in bay C-12 with two “clean” boxes on top—and a hold note from yesterday that never made it onto the stack plan. Forty minutes and two rehandles later, the truck leaves. Labor burned. Gate queue grew. The spreadsheet still looked fine.
That is the container stacking management software problem at a US empty depot. Not “do we have the box?” That is inventory trust. Stacking is the physical plan: which bay, which tier, which pick path—and how many moves you burn when the plan lies.
This piece is for ops-desk buyers who demo to cut rehandles and buried picks on an empty-container depot/yard OS (~200–5,000 TEU)—gate, EIR, inspections, M&R, yard, billing, portal, Jarvis—not a freight TMS and not a marine TOS. Yard spine: container yard management software. Count and trust: container yard inventory management. Releasability: container availability management. Multi-site context: multi-depot container management software. Focus here stays on stack rules, rehandle cost, and live positions—without rewriting the yard pillar or the inventory draft.
Why stacking ≠ “inventory list”
An inventory list answers existence and state: on-site vs departed, grade, hold vs Available, last Gate In. A stack plan answers geometry and cost: bay/row/tier, neighbours that block the pick, and whether today’s release order matches how the yard was built.
You can have a perfect on-hand count and still lose the afternoon. The unit is real. The position is wrong—or the position is right and the hold above it was never visible to the reach-stacker plan. Inventory is the ledger. Stacking is the map the equipment follows.
Practical rule: if “we have it” and “we can pick it without two moves” are answered from different files, you do not have stacking management—you have hope plus overtime.
Rehandles that burn labor at 200–5,000 TEU empty yards
At empty scale, rehandles are rarely dramatic crane ballet. They are quiet tax: dig one unit, restack two, shuffle a third because the booking changed, then do it again when the next appointment hits the same bay.
Typical burn patterns:
- Buried Available — the release is clean; two or three tiers sit on top with no plan to peel them first
- Wrong build sequence — Gate In stacked by arrival convenience, not by tomorrow’s pickup mix (size, grade, line programme)
- Hold-blind digs — crew starts a pick, then discovers a commercial or M&R hold mid-stack
- Appointment pile-ups — same bay asked twice in an hour because positions were “close enough” on a whiteboard
- Restack without a commit — unit moved physically; position never updated; next shift digs the ghost
At ~200 TEU the tax shows up as late gates. At a few thousand TEU it shows up as a second reach-stacker shift you did not staff for. Software does not invent yard physics. It makes the cost of a bad stack plan visible before the truck is on the pad.
Practical rule: if rehandles only appear in end-of-week labour chat, your stack plan is not managing anything—it is apologising after the fact.
Holds and blocked bays in the stack plan
A stack that ignores holds is a labour trap. Holds and blocked bays belong in the same plan the equipment uses—not in a side chat the clerk remembers at 14:10.
Minimum stacking-aware hold behaviour:
- Hold on a buried unit — plan must show the dig cost and that the target may not leave even after dig
- Hold on a top unit — peel path should prefer releasing clear Available neighbours before burning moves on a blocked box
- Bay / lane blocks — temporary closures, wash lanes, or M&R staging must remove capacity from the live plan, not only from a morning email
- Release clears — when empty container hold and release clears a unit, position truth and releasability must update together so the next pick list does not chase yesterday’s block
Stacking software should consume hold and Available outcomes—not invent a softer “yard OK” the booth will refuse. Pair definitions with container availability management.
Practical rule: a green bay on the map with a red hold on the unit is how you teach crews to distrust both.
What software must show the RTG / reach-stacker plan
Empty depots rarely need a full marine TOS twin. They need a pick-facing plan the desk and equipment can share.
Must-show fields for the move:
- Position — bay / row / tier (or your yard’s equivalent) as a committed location, not a sticky note
- Target unit ID and equipment type / size / grade the appointment expects
- Overlying units — what must move first, in order
- Hold / Available / Released on the target and on blockers when that changes the dig decision
- Destination after peel — where temporary restacks land so you do not create a second buried problem
- Last position event time — so “is this stale?” is answerable without walking the bay
Nice-to-have at empty scale: suggested peel sequence, bay heat by upcoming appointments, and multi-depot position conventions when the same clerk covers more than one yard (multi-depot container management software).
Practical rule: if the reach-stacker plan cannot list the two boxes above the target before the engine starts, you are still managing stacks with radio and luck.
Spreadsheet failure modes vs live positions
Spreadsheets fail at stacking in predictable ways:
| Failure | What the sheet shows | What the yard does |
|---|---|---|
| Stale cell | Last night’s bay | Unit moved at 09:40; nobody updated the row |
| Dual editors | Two “current” positions | Crew follows the printout; desk follows the shared drive |
| Hold in chat | Position only | Dig completes; unit cannot leave; restack unpaid |
| No tier model | Bay letter only | “It’s in C” means three possible digs |
| Nightly paste | Clean export | Peak-week appointments already invalidated the paste |
Live positions mean Gate In / relocate / Gate Out commit the map the same way they commit inventory. Nightly CSV can feed ERP later. It cannot steer a 14:10 pick. Inventory trust and position trust should share one unit timeline—see container yard inventory management—while stacking owns the geometry and rehandle math on that timeline.
Practical rule: if correcting a position requires a second typing after the move, you already have two yards—one steel, one Excel—and the steel one wins arguments.
Soft check: pull yesterday’s three longest digs. If any target was “Available” on inventory but buried under units the plan did not list—or blocked by a hold the map ignored—you do not have container stacking management software yet. You have a list and a radio. See live yard positions on containerhub.ai.
How stacking pairs with availability / hold-release without becoming a second system
The failure mode is familiar: inventory in one sheet, holds in email, stack map on a whiteboard, appointments in another tool. By Thursday the four truths disagree and every dig is a negotiation.
Healthy pairing on one depot OS:
| Layer | Owns | Stacking uses |
|---|---|---|
| Inventory | On-hand trust / unit identity | Which units exist to place |
| Availability rules | What Available must mean | Whether a pick is commercially real |
| Hold / release | Who can block and clear | Whether dig cost is wasted on a non-leaver |
| Gate + EIR | Physical commit in/out | Position create / clear events |
| Stacking | Bay/tier plan + peel path | Rehandle cost and pick order |
| Appointments / portal | Who is coming / what they see | Demand against the same positions |
Release authority: empty container hold and release. Available definition: container availability management. Yard product spine: container yard management software. Stacking should not become where clerks re-type Available “for the yard map.”
Practical rule: if updating the stack plan is a separate chore after Gate In, hold clear, or relocate, you already have two systems—one of them will lie first.
Soft CTA: fewer rehandles on containerhub.ai / demo or pricing
If the desk still plans picks from inventory lists and radio—while holds, Available, and Gate events already live somewhere else—the fix is not a thicker whiteboard. It is container stacking management software: live bay/tier positions, hold-aware peel paths, and rehandle cost visible before the truck hits the pad.
ContainerHub is a depot / yard OS for empty-container operations (~200–5,000 TEU)—gate, digital EIR, inspections, M&R, yard positions, billing, client portal, and Jarvis on one model—not freight TMS, not WMS, not a marine TOS pitch. Soft next step only: review the product, book a demo, or compare pricing. No directory ask.
Walk one buried Available unit in a demo. Ask whether the plan shows overlying boxes, hold state on the target, and a destination for the peel—without a spreadsheet between the booth and the reach-stacker.
Visit ContainerHub · Pricing · Demo
Related: Container yard management software · Container yard inventory management · Container availability management · Multi-depot container management software · Empty container hold and release