Package Builder: Selling Ferry + Tour + Accommodation as One Booking

JetSetGo Operations AnalystMay 18, 2026

A customer in Hobart spends 11 minutes on the Bruny-style long weekend page. Ferry across on Friday afternoon, cabin Friday night, wilderness cruise Saturday morning, dinner cruise Saturday evening, ferry back Sunday. She picks her ferry departure. She enters her name, email, phone, address. She picks her cabin category. She enters her name, email, phone, address. She gets to the wilderness cruise checkout — and the form asks for her name, email, phone, address. She closes the tab. The operator never sees the booking, never sees the customer, never knows the package converted to almost-sold and then walked away.

The package that isn't a package

Most multi-modal operators are not selling packages. They are selling three or four separate bookings on three or four separate systems, with the word "package" used as a marketing label rather than a transactional reality.

The pattern shows up everywhere the trip has more than one moving part. An island resort runs the ferry to its own island, the resort itself, and the activity menu on arrival — three systems, three databases, three reconciliations. A reef operator runs the day boat, the dive certification course, and the on-water overnight cabin — three confirmations, three refund processes when weather closes one leg. A coach company offers airport transfer plus the multi-day tour — two payment flows, two customer records that never merge. A regional tourism board bundles a ferry operator, an indie tour, and a partner hotel into a "weekend escape" listing — and the booking is actually three transactions stapled together by a discount code that the customer has to enter three times.

The customer experiences this as friction. The operator experiences it as a reconciliation problem. Both are symptoms of the same architectural issue: the booking platforms underneath were designed to handle one thing at a time, and "package" was retrofitted as a marketing wrapper around independent transactions.

A real package is something different. One transactional record. Per-leg inventory consumption. Per-leg cancellation rules. One payment, with revenue split automatically across the legs and across the operators that ran them. One customer record. One confirmation email. One refund path when the weather kills the Saturday cruise but leaves the ferry and the cabin intact.

This article is about what it actually takes to build that. Not the marketing copy — the architecture.

What a package builder actually requires

Six pieces, each of which has to be a first-class concept in the booking platform rather than a workaround layered on top.

One: the package itself, as a transactional primitive. A package is not "Booking A plus Booking B plus Booking C plus a discount". It is a single booking record with multiple legs. The legs are children of the package, not siblings to it. The package only sells if every leg can be allocated capacity at the same moment, in the same transaction. If the ferry leg succeeds but the cabin leg fails because someone else just took the last room, the whole package rolls back. The customer either gets the full package or sees a clear "this combination is no longer available" message and picks again. There is no scenario where the customer has paid for a ferry and a tour but the cabin is sold out.

Two: choice nodes — the bits that vary. Within a package, customers make decisions. Morning ferry or afternoon ferry. Snorkel tour or glass-bottom-boat tour. Twin cabin or double cabin. Each of these is a choice node in the package structure, with its own availability check and its own pricing implication. The customer makes the choice; availability and price update in real time without leaving the package flow.

Three: anchor nodes — the bits that don't vary. Some legs of a package are fixed. The Saturday-night cabin in the Bruny-style long weekend is the whole reason the package exists; the customer doesn't get to swap it for camping. The dinner cruise on the wine-and-water package is the headline event; everything else is built around it. Anchor nodes constrain the package — they fix the date, the resource, the time — and the choice nodes around them adapt.

Four: cross-leg constraints. Real packages have rules that span legs. Children under 12 cannot select the wine-tasting leg, so the package availability check has to look at the passenger ages on the ferry leg and gate the wine option accordingly. If the ferry leg includes a vehicle, the accommodation leg has to be cabin-class rather than dormitory because the vehicle changes who the customer is. If the package is the dive certification course, the accommodation leg has to be the on-water cabin because the diver has to sleep close to the boat. These constraints live in the package definition, not in the operations team's heads.

Five: per-leg cancellation logic. When the Saturday tour cancels for weather, the package does not automatically refund the whole thing. The ferry ran. The cabin was occupied. The dinner cruise happened. Only the tour leg cancels and refunds, and the SMS to the customer references only that leg. The package stays partially fulfilled with the operator's chosen refund policy applied per leg. The customer is not punished for the weather; the operator is not punished for the ferry that did run.

Six: revenue split, when the legs are operated by different companies. A coach-plus-ferry-plus-hotel package across three independent operators is one transaction to the customer. Behind it, it is one booking that has to be split into revenue against three balance sheets, with commissions, fees, and any agreed bundle discount apportioned correctly. The customer pays once; the platform handles the per-operator settlement; each operator's books match what they actually delivered.

Modelling any one of these on a system that wasn't designed for packages tends to be possible. Modelling all six together, on the same booking record, with the customer entering their details once, is where most platforms stop. (The true cost of generic booking systems for transport operators → covers the broader pattern of capabilities that appear on a feature list but only work with manual operator effort to back them up.)

What this looks like in the platform

A package builder that works is a visual tool, not a coding exercise. Operators lay out the package structure as a tree:

The package root sits at the top with its name, dates, channel rules, and bundle pricing.
Anchor nodes hang underneath as fixed legs — the Saturday cabin, the headline dinner cruise, the dive certification.
Choice nodes sit alongside the anchors as customer-decided legs — ferry time, tour type, cabin category, dietary option on the dinner cruise.
Constraints attach to legs as visual rules — age limits, vehicle dependencies, group-size minimums.
Pricing attaches at two levels: per leg (the ferry costs $35, the cabin costs $180 per night, the tour costs $89) and at the package level as a bundle adjustment (10% off when the three legs are booked together).
Cancellation rules attach per leg — the cabin is non-refundable inside 48 hours, the tour is fully refundable until the morning of, the ferry follows the standard policy.
Revenue split attaches at the package level when legs are operated by different companies — Operator A keeps 100% of the ferry leg, Operator B keeps 100% of the cabin leg less platform fee, the bundle discount is apportioned proportionally.

The customer-facing flow then collapses to a single transaction. The customer picks the package, makes the choices the operator allowed, sees the live price update, enters their details once, pays once, gets one confirmation that lists every leg with its own QR code. The same package can be sold at the website, at the resort front desk POS, at the ferry kiosk on the day, through an agent portal, or through OTAs that list the package as a single product rather than as separate components.

The 5-step decision framework

If you are setting up packages for the first time — or auditing the packages you already sell — five questions get you to a working structure.

1. What legs make up your packages? List every component the customer is buying. Ferry, tour, accommodation, transfer, equipment hire, meals, on-the-day add-ons. Each one is a leg. If you sell the package today but fulfil it by handing the customer over to a partner for one component, that component is still a leg.

2. Which legs vary, which are fixed? Walk through the package from the customer's point of view. Where do they get a choice? Where is the decision already made for them? Choice nodes are flexible; anchor nodes are fixed. The package builder needs both.

3. What are the cross-leg constraints? Age limits, vehicle dependencies, dietary or accessibility requirements, group-size minimums, sequencing rules ("the cabin leg has to fall between the two ferry legs"). Write them down before you build them in — most operators discover constraints they had been handling informally.

4. What is the pricing model — per leg, per package, or both? Most multi-modal packages need both. Per-leg pricing because each component has its own rate card and peak/off-peak swing. Package-level pricing because the bundle discount, the loyalty offer, and the promo code apply to the package as a whole.

5. What is the cancellation policy per leg, and what happens when one leg cancels but the rest are fine? Map out the scenario where weather kills the tour but the ferry ran and the cabin was occupied. Map out the scenario where the customer cancels the whole package 72 hours out. Map out the scenario where the customer cancels just the tour leg. The platform handles whatever rules you define; if you don't define them, the operations team handles every cancellation by hand.

Run those five questions across each package you sell. The answers form the configuration the package builder needs.

Where this is heading

The architecture matters because of what is coming next.

Regional tourism boards are increasingly bundling independent operators into single-listing weekend or week-long experiences — ferry operator plus indie tour plus partner hotel, sold as one product on the destination's visitor site, with revenue flowing automatically to each participating operator. Without a package builder that handles cross-operator revenue split natively, those partnerships rely on manual reconciliation that breaks down at scale.

OTAs are starting to list packages rather than just individual components. Viator, GetYourGuide, and Expedia have all begun surfacing multi-component experiences ahead of single-component ones because the average order value is higher and the cancellation rate is lower. Operators who can supply a single package listing get the priority placement.

Commission accounting across legs becomes the gating constraint as packages grow. When a single package touches three operators, two OTAs, one agent network, and a platform fee, the per-leg per-channel attribution is the difference between books that balance and books that don't. (Why one-size-fits-all platforms fail tourism operators → covers why generic activity-booking systems were never built to handle this kind of per-leg accounting.)

The packages-as-marketing pattern most operators run today — three transactions glued together by a discount code — works at small scale. It stops working when the package gets popular, when partnerships multiply, when OTAs want a single listing, when audit-grade per-leg reporting becomes a contractual requirement.

Build the package once, sell it everywhere

A real package is one booking record with multiple legs, configured visually, sold across every channel, allocated atomically, cancelled per leg, settled per operator. Every customer touches it the same way: one form, one payment, one confirmation, one QR code per leg. Every operations team sees it the same way: one manifest entry that shows every leg they are responsible for.

That is what selling ferry plus tour plus accommodation as one booking actually looks like. Marketing can call it whatever it wants; the architecture underneath is what determines whether it works at scale.

Book a demo → to see the package builder configured against your own itineraries.