Ferry and Ro-Ro Operations Software: Selling Lane Metres, Cabins and Freight on the Same Sailing Without Breaking the Manifest

You are not selling seats, you are selling deck

Every general reservation system in the world counts units of the same thing. Ferry operations does not work like that. A sailing has a length of deck measured in lane metres, and what fills it is a mix of vehicles with different lengths, widths and heights, some of which cannot go on a hoistable deck, some of which need power for refrigeration, some of which carry dangerous goods that must be segregated from each other and from passenger spaces.

Alongside that, the same sailing has a passenger limit set by the vessel certificate, a cabin inventory by type, and often a freight allowance the commercial team has committed to contract customers. A booking consumes different amounts of each. A family in a motorhome takes far more deck than four foot passengers and the same number of certificate places. An unaccompanied trailer takes deck and no passengers at all. A truck with a driver takes deck, one passenger place, and possibly a cabin on a night sailing.

Sell any of those against a single capacity number and you will either sail with empty deck or turn traffic away that would have fit. Both cost real money on a route where the vessel sails regardless.

What actually goes wrong at the ramp

The failure is rarely in the booking engine. It is at check in, fifty minutes before departure, when the vehicle in front of you is longer than the customer declared. A car with a trailer booked as a car. A van booked as a car because it was cheaper. A motorhome whose height matters because the mezzanine deck is down.

Now the load plan does not fit, and someone has to decide in real time what gets left behind. That decision is being made by a person with a clipboard who knows the vessel, and it is a good decision, but it is invisible to the commercial team who will never learn that this route systematically oversells lane metres on Friday evenings.

Then the manifest. Before the ramp closes the operator must know how many persons are on board and be able to produce that record. Add hazardous cargo declarations, which have to match what is physically loaded and where. The paperwork exists because after an incident someone will ask for it, so a manifest assembled from three systems and a handwritten list is not an administrative inconvenience, it is the thing you will be judged on.

Where Hogia Ferry Systems and Carus stop

Both are genuine ferry products and neither deserves the criticism that gets aimed at generic booking tools. They understand ro-ro capacity, freight and passenger traffic, and an operator moving off a legacy system will get real value from either. If your operation is a conventional route structure with standard vehicle categories, buy.

What tends to stay outside a packaged product is the specific physical reality of your vessels and your terminals. Deck configurations, hoistable deck rules, which lane takes which height, how your crew actually loads, and where your particular vessel's constraints bite are yours alone. So is your pricing structure, particularly where freight sits on contracts and retail sits on yield managed fares on the same sailing. So is disruption handling, which on a weather affected route is not an edge case but a regular Tuesday, and which involves rebooking an entire sailing across later departures while respecting every capacity constraint again. Operators typically end up with the product handling bookings and a superintendent handling reality, which works until the superintendent is on leave.

What a custom build has to include

A multi dimensional capacity model. Lane metres by deck with height and weight constraints, certificate passenger places, cabin inventory by type, and any commercial allocation such as freight contract commitments. Every booking consumes a vector across those dimensions, and availability is the answer to whether the vector fits, not whether a counter is above zero.

Vehicle categories that carry real dimensions rather than price bands. Length, height and whether a trailer is attached, with a declared value at booking and an actual value at check in, and the difference recorded. That recorded difference is what lets you set overbooking policy on evidence instead of instinct.

Dangerous goods handled as part of acceptance. Declaration at booking, class and quantity limits per sailing, segregation rules and placement constraints, and a hard block rather than a warning. Then the accepted goods flow into the load plan and into the documentation the master needs before departure.

A load planning view the deck crew will actually use. Assignment of vehicles to lanes and decks with the constraints applied, produced ahead of check in and adjustable at the ramp on a tablet that keeps working when the terminal network does not. If the plan lives only in the office, the crew will keep their own version and yours will be fiction.

Passenger registration and manifest closure as a controlled step. Counting persons on board, closing the manifest at ramp closure, and preserving that record in a form that cannot be edited afterwards. Late arrivals and no shows adjust the record with an audit trail rather than by overwriting it.

Pricing that handles two businesses at once. Retail fares with yield management by sailing, season and lead time, and freight rates on contracts with account customers, minimum volumes and periodic invoicing. These are different commercial models sharing one deck, and the allocation decision between them is a management choice the software should express rather than obscure.

Disruption as a first class workflow. Cancel a sailing, take every booking on it, and rebook across alternative departures by rule and by priority, notifying customers and freight accounts, while respecting capacity on the receiving sailings. On exposed routes this feature alone changes the working life of the operations team.

What it costs and how long it takes

A first release covering the multi dimensional capacity model, booking and check in with actual measurement capture, and manifest closure runs $90,000 to $185,000 and ships in 14 to 20 weeks. A full platform adding load planning, dangerous goods acceptance, freight contracts and invoicing, yield managed retail pricing, disruption rebooking, terminal hardware integration and agent channels runs $250,000 to $600,000 phased over 8 to 14 months.

What drives cost: the number of distinct vessel configurations, since each deck layout is its own constraint set. Terminal hardware, including number plate recognition, barcode scanners and lane displays, which is real integration work at each port. Multi leg routes with island hopping, because capacity has to be held per leg rather than per sailing. And offline behaviour at check in, which is not optional on a ramp and does add engineering time.

What keeps cost down: model one vessel and one route completely before generalising. Operators who try to build a configuration engine covering every vessel in the fleet on day one spend the budget on abstraction rather than on working software.

When buying is the right call

Buy if you run one or two vessels on a short route with simple vehicle categories, no significant freight contracts and no hazardous goods. The packaged ferry products handle that well and the marginal gain from bespoke capacity modelling will not repay a build.

Build when deck utilisation is being managed by a person with local knowledge, when check in regularly discovers vehicles that do not match their booking and nobody is measuring how often, when freight and retail compete for the same deck without an explicit allocation rule, or when a cancelled sailing means a day of phone calls. Each of those is a capacity decision being made outside the system that is supposed to be making it.

How to choose a developer for ferry reservation software

Ask them how availability is calculated for a motorhome with a towed car on a night sailing. The answer should involve lane metres, height, passenger places and cabin inventory in one check. If it involves a single availability count, they are about to build you an airline seat map.

Ask what happens at check in when the vehicle is two metres longer than booked. You want capture of the actual dimension, an immediate effect on the load plan, and the discrepancy retained for analysis, not a price adjustment and a shrug.

Ask how the check in application behaves with no network. Ramps are metal boxes at the edge of ports and connectivity is unreliable everywhere. Offline first with reconciliation is the only workable answer.

Ask how they would rebook a cancelled sailing. If the answer is a report of affected bookings, the operations team will still spend the day on the phone.

Ask who owns the code and settle it in writing before kickoff. You should hold the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit, which matters when the system holds the passenger manifests you would need to produce after an incident.