You are not a container line with a ramp

What container software was built to do

Container systems think in TEUs. A slot has a weight. A box has a size. The whole commercial model — pricing, booking, capacity planning — is built around a rectangular metal box with predictable dimensions and a well-known surcharge profile.

That logic is elegant when your cargo is a container. Loading logic becomes predictable because the units are predictable. Pricing operates on a small set of variables: origin, destination, container size, equipment type. Surcharges follow predictable rules. The system can do most of the thinking, and the commercial team can focus on selling.

It starts to break when your cargo is a BMW X5. Or a Caterpillar excavator on tracks. Or a 14-metre agricultural trailer with non-standard height that requires lane metres, specific deck allocation, and clearance checks before it can even be booked.

In container shipping, cargo is the abstraction. In RoRo, cargo is the specification.

Where the workarounds begin

RoRo operators using generic liner systems know exactly what happens next.

The system cannot model the cargo correctly, so someone builds a spreadsheet. Surcharges for equipment, lashing, and special handling cannot be automated against a unit type the system does not understand, so someone calculates them by hand. Cargo dimensions do not connect to the booking flow, so operations makes adjustments after the fact — sometimes after the booking has already been confirmed to the customer.

Each workaround feels like a small fix. A spreadsheet to handle high-and-heavy pricing. An email thread to confirm out-of-gauge cargo with the operations team. A second spreadsheet to reconcile what was booked against what actually arrived at the terminal. None of them are catastrophic on their own.

Over time, the workarounds become the operating model. And the operating model becomes the ceiling. When the spreadsheet specialist leaves, the knowledge leaves with them. When volume scales, manual reconciliation does not scale with it. When the commercial team wants to launch a new pricing structure, the workarounds become the constraint.

What the wrong fit actually costs

The real cost is not the extra work. It is what the extra work prevents.

Pricing that should take minutes takes hours, because the calculation lives in a spreadsheet that a team owns. Bookings get confirmed without real capacity behind them, because the system tells the commercial team there is space available — but the system does not know that the cargo in question is out-of-gauge and will displace three other units. Voyage profitability gets reconstructed in Excel after discharge — never during, never before — because the data needed to calculate it lives in three different systems and a fourth spreadsheet.

The pattern repeats on a Friday afternoon. A customer asks for a quote on mixed cargo for a sailing the following Tuesday. The agent opens the pricing spreadsheet, cross-references the lashing table, emails operations to confirm whether the high-and-heavy units will fit, and waits. The customer waits with them. By Monday, the cargo has been quoted somewhere else.

When the cargo does get accepted in time, the second-order cost arrives later.

A high-and-heavy unit confirmed against incomplete capacity data can force last-minute reshuffling on the next sailing. Higher-yield units get bumped to a later rotation. A delayed discharge window in Bremerhaven then constrains loading capacity in the rotation after that.

One imperfect decision propagates across three voyages before anyone in the commercial team realises what happened.

Not because the people are slow. Because the system was not built for the business.

The hidden cost shows up as lower utilisation, longer quote-to-confirmation cycles, and a commercial team that spends more time reconciling than selling. It rarely appears on the P&L as a line item titled “wrong software.” It shows up as cost-to-serve drift, margin pressure, and the slow erosion of network yield as the commercial team keeps accepting cargo on terms the system cannot properly price.

The workarounds become the operating model. And the operating model becomes the ceiling.

The shift that changes it

When the data model actually fits RoRo, the dynamic changes upstream — not just in operations, but in the commercial conversation that starts the booking in the first place.

Cargo is tracked by make, model, and cargo group — not as a generic unit. A BMW X5 is a BMW X5 in the system, with its actual dimensions, its actual weight, its actual lashing requirements. Pricing is built around real cargo characteristics, not generic surcharge tables. Booking is confirmed against actual vessel configuration — the system knows which decks have which lane metres available, and it knows whether the cargo at hand can use them.

When that is in place, the commercial team stops compensating for what the system cannot do.

They quote faster, because the calculation is no longer a manual reconstruction. They confirm with confidence, because the capacity behind the confirmation is real. They negotiate from data, because forecast-versus-actual and voyage profitability become visible during the voyage rather than reconstructed afterwards. The role of the system shifts from constraint to enabler — and the role of the spreadsheet specialist shifts from indispensable bottleneck to optional power user.

The question for a RoRo operator running on container-derived systems is not whether the workarounds work. They do — that is why they have lasted. The question is what those workarounds prevent the business from doing. Faster quoting. More accurate capacity commitments. Pricing experimentation. Real-time profitability visibility. The list grows the longer the workarounds stay in place.

You are not a container line with a ramp. The cargo you carry is fundamentally different. The system supporting your business should be too.