Multi-Modal Booking Platform — Ferry, Tour, and Accommodation as One Booking
Above the fold: Sell the ferry, the tour, and the overnight stay as one bookable package. One inventory pool. One confirmation. One refund. One customer database — yours. From the website weeks ahead, or at the kiosk on the day. Live manifest across every leg of the journey. Built by operators who got tired of running their systems instead of running their business.
The real problem when you sell more than one thing
Your customer wants to spend a weekend on the island. The ferry to get there, the snorkel tour on Saturday, the cabin on Friday night. Right now that's three separate bookings on three separate systems — and a kiosk queue at the dock for the walk-up customers who bought their tour on the day. Three confirmations. Three refund processes when the weather cancels. Three customer database entries — none of which talk to each other. A POS at the resort that has no idea who's already paid for tomorrow's tour.
You know it's one trip. The customer knows it's one trip. The booking systems insist on treating it as three.
The pattern repeats across the industry. A reef-day-trip operator who also runs an overnight liveaboard. A coach company that sells the airport transfer plus the multi-day tour. An island resort that operates its own ferry. A vineyard tour that includes the bus, the cellar door, and the dinner cruise. The components belong together; the software keeps them apart.
The cost is everywhere. Operations staff manually keying the same customer into three systems. Refunds that go out in three transactions when the trip cancels. Packages priced by guesswork because combined availability lives in three separate places. Customers dropping off the booking flow because they have to enter their details three times. Peak season chaos because you can't see, in one place, what capacity is left across all the moving parts of an itinerary.
Two modes on one platform — pick what you need
JetSetGo handles two modes on the same platform, and that distinction matters more in multi-modal than anywhere else because a single package often combines both.
The first is sophisticated package booking — bundling ferry + tour + accommodation + transfer as one transaction with one inventory pool, channel rules across every component, and dynamic pricing that respects the whole journey.
The second is high-efficiency ticketed POS — fast kiosk sales, QR scanning at each leg of the journey, live manifest visible to every operator team along the route. Useful for the walk-up component of a package (the on-the-day add-on, the resident-card add-on at the kiosk, the dive-shop equipment hire at the dock).
A real multi-modal operation often runs both at once. The customer books the ferry + tour + cabin package three weeks ahead from the website. On arrival they buy a paddleboard hire at the kiosk and a sunset cruise add-on at the dock. All four transactions land on the same manifest, all four roll up to the same customer record, all four are visible across crew, office, and reservations in real time.
Operational tooling — for every leg of the journey
These capabilities work across every component of a multi-modal package and across every operating model within it.
Mobile POS at the ferry terminal, the dive shop, the resort front desk, the trail-head, the coach pickup point. Card payments via Stripe Terminal. Ticket issuance in seconds for on-the-day add-ons.
QR ticket scanning at each leg. The same QR code can carry multiple journey segments — ferry boarding scan, tour check-in scan, cabin check-in scan. Cryptographic validation prevents reuse. Boarding-state tracking per leg: Expected → Checked-in → Boarded for ferry; Expected → Checked-in → Departed for tour; etc.
Live manifest visible across all teams. The ferry crew sees who's coming; the tour guide sees who's arrived from the ferry; the resort front desk sees who's pre-paid for tomorrow's tour and who hasn't. A no-show on the ferry triggers re-allocation downstream. A weather cancellation on one leg of the journey triggers automated comms for that leg only — without cancelling the rest of the package.
Customer database that builds across legs and operators. Every transaction — ferry, tour, accommodation, on-the-day add-on — captures the same customer record. The operator owns the list. For multi-modal operators, this is the single biggest gain: one customer view across what was previously three systems' worth of fragmented data.
Weather cancellation comms automatically per leg. The Saturday snorkel is off because of rain; SMS goes out to the snorkel passengers (not the ferry passengers, not the cabin guests) with refund-or-rebook for that leg. The rest of the package continues.
Audit-grade reporting per leg per package. Useful when a council multi-modal subsidy depends on showing how many residents used the ferry-bus-tour combination. Useful when a tourism board grant audits package uptake. Useful when a partnership revenue split needs to be calculated across operators.
Sophisticated multi-modal inventory — what makes a package a real package
This is where JetSetGo is built differently.
Packages are real bookings, not stitched-together discounts. A package is a single booking record with multiple legs, each leg consuming its own inventory, all of it allocated together — all-or-nothing. The package only sells if every component has capacity. When any leg cancels the whole package cancels (with operator-configurable cancellation rules per leg). The customer pays once; the operator's accounting splits the revenue across components automatically.
One inventory pool across every product line. A ferry has its lane metres, tonnage, height limits, and passenger seats. A tour has its participant cap and equipment inventory. An overnight stay has its cabin or room categories with multi-night pricing. A coach has its seat selection and depot pickups. A dinner cruise has its table assignments. JetSetGo models each of these natively — they are not shoehorned into a generic activity-booking template. And critically: the same booking can touch all of them in one transaction.
Choices within a package. Customers can pick "ferry departure: 9am or 11am", "tour: snorkel or glass-bottom-boat", "cabin: twin or double" — all within the same package flow. Availability and pricing update across the rest of the package in real time as the customer makes each choice.
Anchors — the parts of the package that don't vary. In a typical island-weekend package the Saturday-night cabin might be fixed while the ferry departure and the day tour are customer choices. The package builder is a visual tool, not a coding exercise.
Constraints across legs. "Children under 12 cannot select the wine-tasting leg." "If the ferry leg includes a vehicle, the accommodation must be cabin-class not dormitory." "If the package includes the multi-day liveaboard, the included tours must align with the on-board schedule." Constraints are expressed in the visual rule builder, not buried in code.
Channel control at the architecture level. OTA capacity caps work per package — "OTAs get max 30% of the long-weekend packages; reserve 20% for direct bookings." Reserved capacity releases configurably. Premium-tier packages stay direct-only. The OTAs see only the packages and pricing the operator chooses to expose, while direct bookings see the full catalogue.
Pricing and business rules
Pricing is highly configurable per component, then combined into one package price. A ferry leg can be a flat fare, or priced by lane metres for vehicles. An accommodation leg can be a flat per-night rate, or priced per berth, or anchored to a peak date with surrounding nights variable. The same flexibility extends across every leg — the operator picks which dimensions matter for each component, and the platform sums the package price accurately.
Flat per component, summed. Useful when components are straightforward — ferry $35, tour $89, cabin $180 = package $304.
Consumption-based per component. A truck on the ferry leg priced by lane metre. A multi-night liveaboard leg priced by berth count and per night. A coach leg priced per sector. The package total reflects exactly what each customer consumed.
Package-level pricing rules. A bundle discount applied at the package level (10% off when ferry + tour + cabin are booked together). Anchor-component pricing (the Saturday-night cabin is fixed price; the choice components vary).
Versioned price lists switching automatically by date — summer rates, school holidays, peak season. Apply per component within the package.
Business rules engine. The visual rule builder handles cross-leg rules: "Family-of-four package discount when ferry leg has 2 adults + 2 children AND accommodation leg is selected." "Loyalty discount applies to the whole package, not just one leg." "Promo code SUMMER25 applies to package, not individual components." These are operator-defined, not engineering work.
One booking, every channel, every leg
Website. Mobile POS at every leg. Agent portal. API integrations with partner operators (when the ferry and the tour are separate companies in a shared package). OTA connectors — Viator, GetYourGuide, Expedia — listing packages, not just individual components.
All drawing from one inventory pool. All respecting the channel rules per leg. All updated in the same second when a sale closes anywhere.
This is what "multi-modal" actually means at the architecture level: one platform, one inventory, one customer record, every leg of every package on the same booking ledger. (Why one-size-fits-all platforms fail tourism operators →)
What this looks like for real multi-modal operators
An island resort + ferry operator running the ferry to the island, a 4-star resort on the island, and dive / SUP / glass-bottom activities. Package builder bundles ferry-return + 2-night stay + activity choice. Cancellation per leg: weather kills the dive, package refunds the dive only and the customer keeps the ferry + cabin. (How peak season capacity is mathematically modelled →)
A multi-day island journey combining the morning ferry, the wilderness cruise, the Friday dinner-cruise, and the cabin overnight. All legs operated by the same company; package booking with fixed anchors and customer-selectable choices; one confirmation; one refund process.
A regional partnership — coach company picks up at the airport, ferries customers to the island, hotels the customers overnight, returns next-day. Three operators, one package. Revenue split automatically per leg per booking; audit-grade reporting per partner.
A reef-and-rainforest operator running the day reef tour, the rainforest tour on the following day, the cabin in between. Customers book all three together as a single multi-day package; the customer database captures one record across three legs.
Frequently asked
Can the components of a package be operated by different companies? Yes. Partnership packages with separate operators per leg work. Revenue split is configured at the package level; reporting per partner is audit-grade.
What happens when one leg cancels for weather but the rest of the package is fine? Per-leg cancellation rules. The cancelled leg refunds (or rebooks); the remaining legs continue. SMS goes out only to the affected leg's customers. The package stays partially fulfilled with the operator's choice of refund handling.
Do all legs have to be on the same day? No. Packages can span days, weeks, or months — a Wednesday airport-coach + Saturday ferry + Sunday tour is one package. Multi-night accommodation legs are priced per night, with check-in/check-out separate from ferry departure times.
Can customers pick options within a package? Yes. Choices let customers select among options (9am or 11am ferry, snorkel or glass-bottom-boat, twin or double cabin) while anchors fix the parts that don't vary. Availability and pricing update across the rest of the package as choices are made.
How do walk-up add-ons work within a packaged trip? Customers buying a pre-booked package can add walk-up purchases at any leg's kiosk — paddleboard hire at the dock, sunset cruise add-on at the cabin reception. The add-ons attach to the same booking record; the customer database stays unified.
Do I have to take advance bookings for every leg? No. Some legs of a multi-modal operation can be walk-up only (kiosk at the dive shop, ticket-on-the-day at the ferry terminal) while other legs (the cabin booking, the multi-day tour) are advance-only. The platform handles both per leg.
How long does implementation take? Onboarding. Multi-modal configurations take longer than single-product ones — typically weeks rather than days — because the package builder needs the operator's actual itinerary structure modelled. Operator-driven configuration, not consultant-driven.
What if I outgrow you? Your data is yours — every leg, every customer, every transaction — exportable in full at any time.
Run the whole journey on one platform
The ferry, the tour, the cabin, the transfer, the on-the-day add-on, the partnership revenue split, the customer database — all on one platform. With one inventory pool. With pricing rules that respect the whole package.
Cancel anytime. You own your data.
See also: ferry booking system (when the ferry leg is the centre of gravity) — tour operator software (when tours are the centre of gravity) — cruise booking platform (multi-day cabin-based journeys).