Why Booking Systems Built for Activities Struggle with Vehicle Decks
The booking system was working perfectly. Tours. Dive trips. Sunset cruises. One product, one capacity number, one button. The operator added a vehicle-ferry route — same wharf, second vessel, fifteen-car deck — expecting to wire it up the same way. Three peak weekends in, the same booking system that ran the activity side without complaint is generating angry phone calls. Customers booked vehicles that wouldn't fit. The deck went out half-empty on one sailing and overweight on the next. The audit log can't say why.
The booking system isn't broken. It was never built for this. The activity-booking category — the tools most tour, dive, and small-experience operators use — solves a clean problem well: how many participants fit on this experience, on this date, in this time slot. Vehicle decks aren't that problem. They look like it from a distance. They aren't. This article is about why.
What activity-booking platforms actually model
Activity-booking systems are built around a simple, powerful idea: a product on a date has a capacity, and bookings consume capacity one participant at a time. Most operators in the tours and activities space need exactly this. A snorkel trip seats twenty-four. A wine tour fits twelve. A whale-watching boat takes ninety. The booking flow is clean: pick the date, pick the time slot, pick the participants, pay. The system holds the capacity, prevents oversells, syncs to OTAs, and rings the till.
The data model behind that is usually one of two shapes:
Flat headcount cap per session — one number per departure: "20 spaces remaining". The booking decrements; when it hits zero, the slot closes.
Multiple participant types against one shared pool — adults, children, infants, with maybe a per-type price and per-type rule (children under 4 free), but ultimately they all draw from the same headcount.
This works because the underlying physical resource — a tour boat, a guided walk, a workshop — is genuinely one-dimensional from a capacity perspective. The constraint is how many bodies fit. Weight, height, dimensions of the participant, hazardous-materials class — none of these are decision variables for tours. The system doesn't need to know that one passenger is 90kg and another is 60kg; it just needs to know there's one fewer space.
Activity platforms also assume homogeneous units of inventory. Every participant is the same shape as every other participant from the system's perspective. The only variation is in price (adult vs child) or in add-ons (lunch, gear, transfer). The capacity arithmetic stays one-dimensional even when the pricing gets clever.
That assumption is the heart of the model, and it's exactly what breaks on a vehicle deck.
What a vehicle deck actually is
A vehicle deck is a multi-dimensional inventory problem. Five dimensions, all real, all checked against every booking:
Lane-metres — total length of vehicle deck, by lane. Vehicles of different sizes consume different amounts.
Tonnage — the deck's gross weight rating. A deck that fits the length of a fully-laden truck may still refuse it on weight.
Height clearance — the lowest overhead obstruction on covered decks. A fridge-truck cannot board a 3.8-metre covered deck regardless of length or weight.
Vehicle-class restrictions — motorbikes off the open-truck deck in heavy weather, hazardous materials to the open deck with separation distances, trade vehicles to the lower deck. Constraints about which vehicles, not just how many.
EV spaces — electric vehicles need fire-segregated bays. Conventional vehicles can use EV-marked spots; EVs can only use EV-marked spots.
A vehicle is not a participant. It is a bundle of consumption against five different ledgers, every one of which has to clear before the booking is valid. A 1.4-metre hatchback consumes 4.5 lane-metres and 1.3 tonnes. A 5.8-metre Land Cruiser consumes 5.8 lane-metres and 2.4 tonnes. A 4.2-metre fridge-truck consumes 4.2 lane-metres but blocks every covered-deck slot. A motorbike consumes 1.5 lane-metres, 0.2 tonnes, and counts against the motorbike-class limit (which may exist on a heavy-weather sailing).
The platform now has to do something the activity model never required: track different units of inventory that consume different amounts of different resources, and check all of them independently on every booking.
That's the qualitative gap. Operators who try to retrofit an activity tool to handle it run into the same set of failures every time.
How retrofitting fails
There are roughly four ways operators try to make a flat-headcount platform work for a vehicle deck. None of them work for long. The patterns are worth naming because they're the warning signs of an operation that's outgrown its tool.
Pattern 1: Cars-as-participants. Treat the vehicle deck as a "tour" with 15 "participant spaces". Every car booking is one participant. This works for cars-only operations until the first time someone tries to book a motorbike, a small camper, or a vehicle-and-trailer rig. The system has one decrement; the dockmaster has a Tetris puzzle. The deck will look full at 15 cars when it has room for four more motorbikes, or overflow at 12 cars when a couple of trade vehicles have eaten all the lane-metres.
Pattern 2: Per-vehicle-type sub-products. Create a separate "tour" for each vehicle category — Car tour, Motorbike tour, Truck tour — each with its own capacity. This temporarily solves the count problem and creates a worse one: the capacities are independent. The system has no concept that motorbikes and cars share the same physical deck. Sell out cars and motorbikes both, and the deck is now oversold. Set the capacities conservatively, and the deck sails half-empty. There's no arithmetic that reconciles the sub-products against the actual deck.
Pattern 3: Add-ons as vehicles. Make the booking a passenger product and offer "Add a car" as a $50 add-on. The car has no inventory record of its own. The system tracks revenue but not deck consumption. The dockmaster works from a printed manifest that may or may not reflect the vehicles actually booked. Reconciliation is by hand. Manifest accuracy is by hope.
Pattern 4: Headcount-as-lane-metres. Set the deck's "participant cap" to 200 (lane-metres), and ask the booking flow to charge "5 participants" per car booking. The system superficially works — the maths is right when the customer is a car — and silently fails on everything else. Customers don't understand why a motorbike costs "1.5 participants"; the booking checkout becomes confusing; integrations to OTAs collapse because the OTAs expect a participant number, not a length figure; and the system has no notion that the 200-unit cap is also constrained by 70 tonnes of weight and 3.8 metres of overhead.
Each of these patterns sees the operator paper over a structural mismatch. The mismatch isn't going anywhere. It surfaces every peak weekend, every weather-affected sailing, every dock-side conversation about a vehicle that shouldn't be on this sailing but is, or that should be on this sailing but isn't. Industry analysis of the activity-booking category from Arival's 2024 outlook research and from the Phocuswright In-Destination Experiences research stream consistently shows the category's strongest fit is single-resource, headcount-driven, time-slotted activities — exactly the inverse of a vehicle deck's shape.
What a purpose-built model gets right
A booking platform that handles vehicle decks at the data-model level doesn't treat them as a variant of a tour. It treats them as a different shape of inventory entirely. Several capabilities follow from that:
Multi-dimensional capacity tracking on a single resource. The same physical deck holds multiple parallel ledgers — lane-metres, tonnage, height-allowable, EV-marked, vehicle-class counts — all consumed in one booking transaction and all checked together. Either every dimension clears, or the booking fails as a whole. A 4.2-metre vehicle that exceeds the covered-deck clearance is refused at the point of booking, not refused at the gate.
Hierarchical capacity. A vessel has a vehicle deck, which has lanes, which have sections. A covered deck has different clearance from an open deck. A heavy-vehicle lane is loaded differently from a light-vehicle lane. The system models the hierarchy and rolls allocations up: when you fill a covered-deck section with sedans, the covered-deck clearance constraint releases for the remaining open-deck capacity. A booking system that only sees "the deck" can't reason about it.
Operator-defined vehicle classes. Cars, vans, motorbikes, light trucks, heavy trucks, refrigerated freight, hazmat freight, oversized loads, recreational vehicles, vehicle-and-trailer combinations, electric vehicles, school buses, emergency vehicles. The operator defines the classes that matter on their deck and the rules that apply. The system doesn't ship with a hard-coded list because every operator's deck is different.
Vehicle catalogue with real dimensions. When a customer chooses "2021 Toyota HiLux", the booking inherits the actual length, weight, and height of that model. The customer doesn't type "5.3 metres", and the operator doesn't trust their typed figure. The catalogue provides the dimensions; the booking flows through the deck's ledgers automatically.
Trailers as their own ticketed entity. A car-and-trailer is two bookable units: the car with its dimensions, the trailer with its dimensions, both ticketed, both priced, both loaded. Detach the trailer at the destination and the trailer is its own record on the return leg. The platform knows the unit is travelling as one transaction (the booking, the boarding, the deck-side adjacency) and as separate entities for reporting, pricing, and the restrictions specific to the combination.
Consumption-based pricing. Tariff per lane-metre, or per tonne, or per metre-over-standard for oversized loads. The pricing engine reads the vehicle's actual dimensions and prices accordingly. A flat $50 per car and a separately-configured rate per lane-metre for a truck — or a fully-dimensional rate that scales with every booking. The pricing follows the model rather than fighting it.
Hard refusal at the booking point. A vehicle that won't physically fit on the deck cannot be booked, on any channel — direct, OTA, agent, walk-up POS. The operator never sees a confirmed booking that the deck can't honour.
Manifest output that matches the deck. The pre-departure manifest lists vehicles by class, lane-metres consumed, weight contribution, overhead clearance, with totals against each ledger. The document the maritime authority asks for after any incident is the same document the dockmaster uses to load.
These aren't exotic features. They're the data shape the deck actually has. The question isn't whether they're available in some hand-coded extension or as a paid module — it's whether the booking platform's core data model can express them at all.
Operators living between the two models
The hardest spot is the operator who runs both — tours and a vehicle deck on the same business — and has to either pick one platform or stitch two together. Three common configurations:
A passenger ferry plus a vehicle ferry, where the vessels operate similar schedules but the capacity model is different. The activity tool runs the passenger boats fine; the vehicle boat needs the deeper model.
A multi-modal operator selling a vehicle-ferry crossing plus a tour at the destination as a package. The package has to honour both inventory shapes in one booking transaction. (See The True Cost of Generic Booking Systems for Transport Operators for the broader story on packaged products.)
A single vessel doing both — a small RoRo that runs as a vehicle ferry on weekdays and as a tour vessel on weekend charters, with the vehicle deck cleared to function as a passenger-event space. The same physical resource needs to be modelled as two different inventory shapes depending on the service.
In each case, the operator who tries to make one activity tool cover both either gives up the data fidelity on the vehicle side or sets up parallel systems and lives with the reconciliation cost. The right answer is a platform whose core inventory model supports both — different shapes of inventory against the same resource taxonomy, with services choosing which dimensions matter for that specific run.
Three implementable takeaways
If your operation has a vehicle deck and the current booking tool was built for activities, three concrete moves regardless of platform decision:
Audit one peak sailing on paper. Pick a recent peak Saturday. Pull the actual vehicle mix that boarded. Calculate the lane-metres consumed, the tonnage carried, the overhead clearance occupied. Compare that to what the current booking system thought was on the deck. The gap between the booking system's view and the deck's reality is what the model mismatch is costing.
List the vehicle classes that actually come through the gate. Not the marketing categories. The real ones — including the awkward combinations (car-and-trailer, motorbike-with-sidecar, oversized recreational vehicle, EV with charging request). Every class the booking system can't represent is a class the dockmaster is reconciling by hand at the gate.
Time one boarding's refusal queue. How many vehicles at last peak season got refused at the dock because the booking system said the deck was full when it actually had length or weight available, or said the deck had room when it didn't? The number is usually 5–15% of peak-day arrivals. That number is the operating cost of a model mismatch, in customers turned away and goodwill spent.
Where this is going
Two trends are widening the gap between the activity-platform model and the vehicle-deck reality over the next several seasons.
EV share is rising. Electric vehicles are heavier than equivalent combustion vehicles and require fire-safety segregation under maritime guidance from both the Australian Maritime Safety Authority and the UK Maritime and Coastguard Agency. On ferry routes serving popular EV destinations, the mix is already higher than the national average. EV spaces stop being a flag in the booking flow and become a hard count the system has to hold and release independently — exactly the kind of multi-dimensional inventory the activity model can't represent.
Contract scrutiny is tightening. Vehicle ferries operating under council Public Service Obligation contracts, regional subsidies, or community-service routes face audit requirements that flat-count capacity reporting can't satisfy. The auditor wants to see lane-metres delivered, tonnes carried, vehicles refused-and-why, with the timestamped evidence. That report is mechanical if the inventory model carries the dimensions; it's a multi-day reconstruction if the booking system thinks the deck is a tour with a participant cap.
These pressures don't reverse. The category of operators where an activity-booking tool is the right answer doesn't change. The category of operators with vehicle decks is moving — fast — in a direction the activity model wasn't built to follow. (For a closer look at the per-sailing revenue mechanics that this measurement gap drives, see The Hidden Economics of Ferry Operations.)
What to look for in a platform
The shorthand: if you're evaluating a booking platform for a vehicle deck, the test isn't whether it lists "vehicles" in its product taxonomy. The test is whether the data model can represent multi-dimensional inventory on a single resource, with operator-defined vehicle classes, hierarchical capacity, and tariffs that scale with the dimensions the vehicle actually consumes. Most activity-booking platforms cannot. Some have added "vehicles" as a feature on top of an unchanged participant-count model — useful for marketing copy, not for the deck.
Operators who run only activities are well-served by activity platforms. Operators who run vehicle decks need a model the platform was built around, not retrofitted into.
JetSetGo's vehicle ferry software was built with multi-dimensional vehicle deck capacity as a core data shape — lane-metres, tonnage, height, EV spaces, vehicle catalogue, trailers as separately-ticketed items, per-deck loading rules, hierarchical capacity, and manifests that report against each. The same platform handles activity-style products (tours, cruises, events) on the same resource taxonomy, so an operator who runs a vehicle ferry on weekdays and a chartered tour on weekends doesn't need two systems. The multi-modal booking platform pillar walks through how a single booking can combine a vehicle-deck crossing with a tour at the destination — both inventory shapes, one transaction.
Book a demo → to see vehicle-deck inventory modelled against one of your own sailings.