The yard is where a terminal quietly loses money. Not dramatically, and not in a way that appears on any single report, but in reshuffles nobody planned, containers nobody can find and space nobody realised was wasted. A container yard management system exists to close the gap between where the record says a box is and where it physically is. This guide explains how that gap opens, what it costs, and how to close it without paving anything. The wider yard series covers the neighbouring topics.

Key Takeaways

• Yard management covers slot allocation, stack planning, reshuffle minimisation and inventory truth. The fourth underpins the other three and is the one most terminals never measure.
• Inventory drifts because the record is built from reported moves rather than observed ones, and every unreported or mis keyed move creates a divergence that persists silently.
• Positioning technology splits into tags, satellite positioning on equipment and camera derived location. They differ enormously in installed cost and in what they do when a box moves unrecorded.
• Five metrics tell you whether the yard is working: reshuffles per container, yard utilisation, average dwell, search events and truck wait time.

What Yard Management Actually Covers

Yard management is the discipline of deciding where every container goes, when it moves and how few times it has to be touched before it leaves. It sits between vessel planning, which decides what arrives, and gate processing, which decides what departs, and it absorbs the consequences of both.

The first job is slot allocation. When a box lands, something has to choose a position for it, and that choice determines how much work is required to retrieve it later. Good allocation groups boxes by likely departure and keeps frequently accessed cargo where it is easy to reach.

The second is stack planning. Height, weight distribution, reefer proximity to power, dangerous goods segregation and equipment reach all constrain what can go where. A plan that ignores any of them produces either an unsafe stack or one that needs rework before it can be worked.

The third is reshuffle minimisation. Every time a container has to be lifted to reach another one, the terminal performs a move it does not bill for and did not want. Reducing those unproductive moves is the clearest financial objective in the whole discipline.

The fourth is inventory truth, and it underpins the other three. Allocation, planning and reshuffle reduction all reason about a picture of the yard. If that picture is wrong, the reasoning is wrong regardless of how sophisticated the algorithm behind it happens to be.

That is why this guide spends more time on drift than on optimisation. Terminals routinely try to solve a yard problem with better planning software when the actual defect is that the planner is looking at a yard that does not exist.

It is also why a container yard management system should be evaluated on what it observes rather than on how it plans. Two products with identical planning logic will produce very different results if one of them is fed by observation and the other by reported moves alone, and no feature comparison will show you that difference.

Why Yard Inventory Drifts From the Record

Every terminal operating platform believes a container is in a particular slot because a move was reported as complete. That belief is only as good as the reporting, and there are three reliable ways for it to be wrong.

The important property of all three is that they fail silently. Nothing raises an alarm when a container stops being where the record says it is, because the record has no independent source to disagree with. Drift therefore accumulates through a shift, through a week and through a peak season, and only becomes visible when somebody needs a specific box.

Moves that are never reported

An operator repositions a box to get at another one and does not record it, because the shift felt temporary and the shift ended before the box went back. This is the commonest cause and it is not a discipline failure so much as a design failure, since recording every touch manually is unrealistic at working pace.

The consequence is a container that the system believes is in position while it physically sits somewhere else, sometimes in a row it was never planned for. Nobody notices until the box is requested, at which point a person starts walking and a truck starts waiting. In a busy week a single yard can accumulate dozens of these without a single error appearing on any report.

Moves reported to the wrong slot

Slot references are short alphanumeric strings entered under time pressure, and transpositions happen. A box recorded in 04A3 that is actually in 04A2 is invisible to every report and perfectly obvious to anyone standing in front of it.

These errors are particularly corrosive because they are self consistent. The record looks complete, the audit trail looks clean, and the only symptom is a retrieval that takes longer than it should, which gets attributed to congestion rather than to data. That misattribution is why terminals so often buy more equipment when what they needed was a more accurate inventory.

Equipment and system gaps

Position reporting from handling equipment can fail, timeout or report a stale value, and terminals that rely on it without an independent check inherit whatever the equipment believed. Radio blackspots and equipment swaps midshift both produce the same silent effect.

Cycle counts are the traditional answer and they are expensive. A full physical inventory of a yard costs a shift of labour and is out of date within hours, which is why most terminals do it rarely and live with the drift in between. The interval between counts is precisely the period in which the yard picture is least trustworthy, and it is usually most of the year.

What Drift Costs, Counted Honestly

The first cost is search time. Somebody has to physically locate a container the record has misplaced, and that search occupies a person, often a machine, and always a truck driver waiting at the other end of the transaction. Terminals that start counting search events are usually surprised.

The second is unproductive moves. A box in the wrong place forces lifts that would not otherwise have happened, and each of those consumes equipment hours, fuel and operator time that generate no revenue. The client covers this specific cost in its analysis of yard reshuffles.

The third is capacity. A yard whose inventory is uncertain has to be run with more slack, because planners leave room for surprises. That slack is real estate you have paid for and cannot use, which is why capacity utilisation is a data quality metric as much as a planning one.

The fourth is service. Truck turn time is the number your customers notice, and a proportion of it is spent waiting for a container that was not where it was supposed to be. That proportion is invisible in an average and obvious in the tail of the distribution.

The fifth is decision quality. Every planning decision, every capacity forecast and every investment case rests on yard data. Terminals that do not trust their own inventory tend to make conservative decisions, which is rational and expensive.

These five compound rather than add. Longer searches lengthen truck turn, which pushes arrivals into the next window, which congests the yard further, which makes the next search harder. That feedback is why yard problems appear suddenly at terminals that were coping comfortably a season earlier, as our piece on handling peak season volumes describes.

Put a number on each of these before evaluating any solution. A terminal that knows it performs eleven thousand unproductive moves a year has a specific problem with a specific value, which is a far better negotiating position than a general aspiration to be more automated.

Positioning Technologies Compared

There are three families of answer to the question of where a container physically is, and they differ enormously in what they cost to install and in how they behave when something moves without being recorded.

Tags and real time locating systems

A real time locating system attaches a tag to equipment or to containers and triangulates position from fixed readers. Accuracy is good and the data is continuous, which is genuinely valuable in a busy yard with high equipment density.

The cost is the estate. Readers need mounting, powering and networking across the whole yard, tags need managing and replacing, and coverage gaps produce exactly the silent drift the system was bought to prevent. It is a capital project with an ongoing maintenance obligation, and at mid sized volumes that obligation is what usually stops the business case from closing.

Satellite positioning on handling equipment

Fitting satellite positioning to cranes and carriers infers container location from where the machine was when it released the box. This is cheaper than a full tag estate and works well in open yards with clear sky view.

It inherits every equipment reporting gap, though. If the machine did not report, or reported late, or a box was moved by a machine outside the scheme, the record drifts exactly as before. It also degrades between deep stacks and under structures, which are precisely the parts of the yard where position errors cost the most to resolve.

Camera derived location

Vision uses cameras to observe what is physically present and where. In a terminal that has already installed cameras for gate and crane recognition, the incremental cost is software rather than hardware, which changes the economics of the decision entirely.

It observes rather than infers, so an unreported move is still seen. The limits are honest ones: coverage depends on camera placement, dense stacks create occlusion, and the approach works best in combination with equipment reporting rather than as a wholesale replacement. Treat it as a second independent source of truth rather than as a single system of record.

How Vision Derives Stacking Intelligence

Docker Vision built its recognition engine for gate and crane use, reading container codes with computer vision from standard cameras. The same observation stream carries yard information, because a camera that can read a code can also record where and when it saw it.

That produces a stream of sightings rather than a continuous track, which is a meaningful distinction. A sighting is an observation with a timestamp and a location, and a series of sightings reconstructs where a container has been without requiring anything attached to the container itself.

Sightings are most valuable where they contradict the record. A box observed in a row the platform does not expect is exactly the exception a planner needs to know about, and surfacing those contradictions is more useful than confirming the hundreds of positions that were already correct.

The stacking layer sits on top of that. Once you can trust the current picture, allocation recommendations become worth following, because they are reasoning about the yard as it is rather than as it was last reported.

The commercial argument is the incremental one. A terminal that has already installed cameras for gate recognition is adding a software capability rather than a sensor estate, which is why this approach reaches a business case at volumes where a full tag deployment does not.

The honest limits belong in the same paragraph. Camera coverage is not universal, occlusion in deep stacks is real, and the strongest configuration combines vision with equipment reporting so each covers the other gaps. Any vendor claiming otherwise is overselling.

A useful way to scope it is to identify the twenty percent of your yard that generates most of the search events, and instrument that first. Those rows are usually well covered by cameras already installed for crane work, which the client describes in its piece on crane productivity and monitoring.

Feeding Recommendations Back Into the Work Queue

An observation that does not change what somebody does is a report, not a system. The value appears when a discrepancy or a recommendation becomes a work order in the platform that an operator actually receives on the machine.

Start with exceptions rather than optimisation. A daily queue of contradictions between observed and recorded position, ordered by how likely each container is to be requested soon, is immediately useful and requires no change to how the yard is planned.

Then add opportunistic repositioning. When a machine is already in a row for another reason, and a nearby box is badly placed for its likely departure, the cost of correcting it is close to zero. Systems that surface those moments recover value that pure optimisation misses.

Only then move to allocation recommendations. Once the picture is trusted and the exception queue is small, slot suggestions can be followed rather than second guessed, and the planning module you already licensed starts producing the outcomes it was designed for.

Route everything through the platform rather than into a separate screen. A recommendation that lives in another application competes for attention and loses. The client explains the integration mechanics in its post on plugging into an existing platform.

Assign an owner for the exception queue before go live. Queues without owners fill up and become evidence that the system does not work, when the real failure was organisational rather than technical.

The Five Metrics That Tell You It Is Working

Reshuffles per container is the headline. Count unproductive moves and divide by containers handled. Terminals that have never measured this are often startled, and the trend matters far more than the absolute figure because yard layouts differ so much.

Yard utilisation is the second. Occupied slots against usable slots, measured at peak rather than on average. Utilisation that looks comfortable on a monthly average and touches ninety five percent every Thursday is a yard with a Thursday problem.

Average dwell is the third, and it should be read as a distribution rather than a mean. A yard where most boxes leave in three days and a tail sits for six weeks needs a different intervention from one where everything moves slowly.

Search events is the fourth and the one almost nobody records. Every time somebody has to physically look for a container, log it. This single metric is the cleanest proxy for inventory truth available and it costs nothing but a habit to collect.

Truck wait time is the fifth, because it is the number your customers experience. Separate the portion attributable to yard retrieval from the portion spent at the gate, since they have different causes and different fixes.

Publish all five monthly and watch the trends together. A terminal that improves reshuffles while search events climb has optimised its plan against a picture that is getting less accurate, which is a failure disguised as progress.

Two habits make the numbers useful rather than decorative. Break every metric down by yard block, because averages hide the two rows causing most of the trouble. And record the operational context alongside them, so that a bad month explained by a berth closure is not mistaken for a system that has stopped working.

Sequencing a Yard Programme

Step one is to measure the current position for a month without changing anything. Reshuffles, utilisation at peak, dwell distribution, search events and truck wait. Without a baseline you will never be able to demonstrate improvement, and you will not know which problem is worst.

Step two is to fix identity at the boundary. Accurate gate data is the foundation of accurate yard data, because a box that entered under the wrong number is misplaced from the first second. This is also the cheapest and fastest intervention available.

Step three is to introduce observation where the drift is worst. That is usually the rows worked most heavily and the areas where cycle counts have historically found the most discrepancies. Start narrow, prove the exception queue is useful, and expand.

Step four is to close the loop into the platform so discrepancies become work rather than reports. This is the step that converts an interesting dashboard into an operational change, and it is the one most often deferred.

Step five is optimisation, and it comes last deliberately. Allocation strategy and stacking policy are worth tuning once the picture is trustworthy, and are largely wasted effort before that, which is the mistake most yard projects make in their first month.

Run in that order and each step funds the next. Gate accuracy pays for itself in turn time, observation pays for itself in search reduction, and optimisation pays for itself in reshuffles, by which point the case for the next phase writes itself. Our note on what to ask before you appoint a supplier covers vendor selection.

The sequence also protects the programme politically. A yard project that opens with an expensive sensor deployment and promises benefits in eighteen months is fragile to a change of priorities. One that shows a measurable turn time improvement in its first quarter, then a falling search count in its second, keeps its funding because each phase has already proved itself.

Conclusion

A container yard management system is only as good as its picture of the yard, and that picture drifts the moment it depends purely on reported moves. Measure the drift, fix identity at the gate, add observation where the divergence is worst, and route discrepancies back into the work queue before touching optimisation. Terminals that follow that order find capacity they already owned. Ask Docker Vision about a yard audit using cameras you have already installed.

Frequently Asked Questions

What does a container yard management system do?

It decides where every container is placed, plans the stacks, minimises unproductive reshuffles and maintains an accurate inventory of what is physically in the yard. The last of those underpins the quality of the other three.

Why does our yard inventory drift from the record?

Because the record is built from reported moves rather than observed ones. Unreported repositioning, mis keyed slot references and equipment reporting gaps each create a divergence that stays invisible until somebody cannot find a container.

How much does a reshuffle actually cost?

It costs equipment time, fuel, operator time and usually a waiting truck, and it earns no revenue. Terminals that count unproductive moves for a month are typically surprised by both the volume and the annualised value.

Is RTLS better than camera based positioning?

They answer differently. Tags give continuous tracking at the cost of a reader and tag estate. Cameras observe rather than infer and cost software where cameras already exist. Many terminals are best served by combining both.

Can we use the cameras we installed for gate OCR?

Often yes. A camera that reads a container code also records where and when it saw that container, which produces yard sightings without new hardware. Coverage depends on placement and deep stacks create genuine occlusion.

What is a sighting and why does it matter?

A sighting is an observation of a specific container at a specific place and time. A series of them reconstructs movement without attaching anything to the box, and the valuable ones are those that contradict the recorded position.

Which yard metric should we start tracking first?

Search events. Log every occasion somebody physically hunts for a container the record has misplaced. It costs nothing but a habit, and it is the cleanest available proxy for whether your inventory can be trusted.

Should we optimise allocation before fixing data quality?

No. Optimisation reasons about whatever yard picture it is given, so improving the algorithm while the picture is wrong simply produces confident bad decisions. Fix identity and observation first, then tune allocation policy once the data can be trusted.

How does yard data reach our operating platform?

Through the same interface routes that carry gate events, so a discrepancy becomes a work order for an operator rather than a line on a separate dashboard nobody opens. See our explainer on reading a container in realtime for the mechanics of that flow.

Does this require paving more yard area?

Usually not. Most terminals discover they were holding capacity in reserve purely to absorb uncertainty, and recovering that slack releases usable space without any construction at all. See how automation reshapes terminals for the wider effect on layout.