How to Choose a Multi-Modal Booking Platform
The real decision isn't "which booking platform". It's "how do we stop selling our packaged trips as three separate transactions on three separate systems and start selling them as one". By the time an operator searches for this, they've usually spent a season trying to stitch a ferry booking, an accommodation night, and an activity onto the same trip through email confirmations, manual re-keys, and a customer database fragmented across three places. The platform that fixes it treats the package as a real transactional object, not a discount code stapled across separate carts.
This guide is for operators selling two or more product types as one customer journey — transport plus activity, transport plus accommodation, or all three in any combination. If you run an island ferry plus a destination resort plus the activity menu on arrival, a coach company plus a multi-day tour plus the overnight, or a partnership pulling components from independent operators into a single weekend escape, the questions below were written with you in mind.
It's vendor-agnostic — what to look for, what to ask, what good answers sound like, what red flags to watch for. One short section at the end on where JetSetGo fits. The rest is the framework.
Why "how to choose" is the question worth answering
Most booking platforms handle single-product operations adequately — sell a tour, take a payment, print a manifest. Trouble starts the moment the business adds a second product type and the platform treats it as an alien object. The "package" the marketing team has been selling for years is, under the hood, three bookings reconciled by hand.
The cost shows up in three places. Customer drop-off — conversion on a stitched-together package is materially worse than on a single transaction because each system asks for the customer's details again. Operations cost — staff manually keying the same customer into three systems, processing three refunds when weather kills one leg, reconciling three sets of revenue at month-end. Strategic cost — without a unified customer database, the marketing programmes that would lift repeat business never gather the data they need.
Picking the wrong platform locks all three in for another evaluation cycle. Arival and Phocuswright's joint research finds the tours, activities, and experiences sector remains highly fragmented — more than 70% of operators are small or micro businesses with uneven tech adoption — meaning most operators choosing a platform have nobody in the next office to copy. (Arival × Phocuswright Outlook for Travel Experiences)
What to look for in a multi-modal booking platform
Eight capabilities matter more than the rest.
A real package construct, not bundled discounts. A package has to be a single transactional record with multiple legs underneath, not three bookings tied together by a coupon. Capacity holds against every leg's own model at the same moment — if the ferry has space but the cabin doesn't, the platform refuses the sale rather than booking a partial package the operator has to clean up. One payment, one confirmation. The multi-modal package builder capability doc covers the load-bearing mechanics; the Package Builder article covers the architectural pattern.
Structured packages with anchor + customer choices + fixed legs. Real packages have shape. One leg sets the timeline — usually the dated, capacity-constrained transport or multi-night accommodation — and the rest arranges around it. Some legs the customer chooses (morning or afternoon ferry, snorkel or glass-bottom-boat, twin or double); some are fixed because they're the reason the package exists. The platform has to model all three and enforce dependency rules in real time — choices that fail the rules drop out of the picker before the customer can pick them.
A pricing engine that prices each leg in its own mode and sums into one package price. The transport leg is often per-sector or flat per fare type. The accommodation leg is per night, sometimes per berth. The experience leg is usually flat per person. The platform has to price every leg in the mode that fits, sum to one total the customer sees, and still let the operator apply a bundle adjustment or peak-period uplift across the package as a whole. The pricing engine capability doc covers the full surface; what matters in evaluation is that the engine doesn't force every leg into the same pricing shape.
Channel rules that work per leg and per package. Multi-modal operations typically have legs facing different channel mixes. The activity leg might be heavily OTA-distributed; the accommodation direct-only because the rooms are scarce; the transport through agent portals for trade customers. The platform has to respect each leg's channel rules when the package sells AND let the operator set rules on the package itself — a premium long-weekend can stay direct-only even when the underlying transport sells through OTAs. The channel management capability doc handles this through allocation groups that resolve from the customer, the channel, or the package.
Per-leg revenue recognition with bundle-discount allocation. A package is one transaction to the customer; for the operator (or operators, in partnerships) it's revenue against multiple products and sometimes multiple legal entities. The platform has to record leg-level pricing for every package booking, allocate any bundle discount back across the legs using a configurable method, and produce reporting that survives accountant scrutiny — including partner reconciliation when the legs are operated by separate companies. Most platforms can sell a bundle; few produce an audit-grade per-leg revenue report without a spreadsheet.
Mixed walk-up and advance booking inside the same trip. Multi-modal operations often combine pre-booked and on-the-day transactions. The customer books three weeks ahead online; on arrival they buy a paddleboard hire at the dock or a sunset-cruise upgrade at reception. The walk-up has to attach to the same package booking, write to the same customer record, update the same manifest. Platforms that treat the package as advance-only and the kiosk as a separate world fragment the customer view exactly when the operator wants it unified.
Operational tooling visible across every leg. Ferry crew, experience guide, accommodation front desk, kiosk at the dock — all need to see the same picture in the same second. A no-show on the ferry has to flow through to the activity guide's manifest. A weather cancellation on the experience leg should fire comms only to the affected customers without touching the rest of the package. The platform should sit on a live manifest queryable per leg and across legs, with QR-validated boarding and audit-grade state tracking.
A provider who understands multi-modal operations. Software is half of it. The other half is whether the provider has actually configured a package across three product types before, whether onboarding includes someone who has thought through dependency rules and revenue splits, and whether the post-onboarding relationship is "log a ticket and wait" or "the same person who set you up answers when you call". Multi-modal configurations take weeks rather than days. Ask for a reference at your level of complexity.
The make-or-break moments most platforms fail at
A handful of multi-modal scenarios look small in a demo and turn out to be where most platforms quietly break.
Capacity simultaneity across heterogeneous legs. The package only confirms when every leg holds capacity against its own model at the same moment — and every leg's model is different. Transport is in passenger seats and lane metres. Accommodation is in cabin berths with category constraints. The experience is in participant slots, sometimes with shared equipment underneath. The platform has to check all of them in one motion, hold them together, and either confirm or refuse the package cleanly. Platforms that check leg-by-leg open a window where the ferry and the cabin sell while another customer's parallel transaction grabs the last activity slot — and the first customer is left with a half-package the operations team has to clean up. All-or-nothing allocation is the load-bearing guarantee.
Per-leg cancellation when one leg fails but the rest continues. The Saturday experience is off for rain. The ferry ran. The cabin was occupied. The platform has to refund (or rebook) just that leg — and send comms only to those passengers with a refund-or-rebook link for that leg, not a generic "your package was affected" message that confuses customers whose other legs went ahead. The operator decides per package whether cancellation is linked (cancel one, cancel everything) or independent. Most run a hybrid: customer-initiated linked, operator-initiated independent. The cancellation policies capability doc describes the model.
Per-leg revenue recognition with a package-level bundle discount. A weekend package priced as one number, with the ferry, cabin, and activity priced individually underneath, less a bundle discount. At month-end, what's the revenue per product? Most platforms record the package as one ledger line and leave the operator to allocate the bundle revenue by hand. The platform should record leg-level pricing per booking, apply the configured allocation method (proportional, weighted, or operator-defined), and produce reporting that traces every dollar back to the product that earned it. When the legs sit across separate operators in a partnership, the same logic powers reconciliation.
Mixed-channel package distribution with per-leg channel exposure. A weekend package is direct-only. The underlying transport leg sells through OTAs as a standalone, capped at a fraction of capacity. The accommodation is direct-only as a standalone too. The activity sells through several OTAs. When the package sells, every leg's underlying channel rule has to be respected — the transport counts against its OTA cap if the booking came through an OTA-eligible path; the accommodation gates if the channel isn't allowed; the activity honours its own commission structure. The platform resolves which rule fires per booking. The customer experiences none of this; the operator's reporting reflects all of it.
Dependency rules across legs that the customer never sees fail. Children under 12 cannot select the wine-tasting leg. If the transport includes a vehicle, the accommodation has to be cabin-class with parking, not dormitory. If the package includes the multi-day liveaboard, the included experiences have to align with the on-board schedule. The platform enforces these in real time — the wine-tasting leg disappears from the choice list as soon as children are indicated. Rules live in a visual builder the operator can edit, not in code.
Walk-up add-on attaching to a pre-booked package. A customer holds a three-leg package booked online a fortnight ago. On arrival they want a paddleboard hire at the dock and a sunset-cruise upgrade at reception. The walk-up has to attach to the original booking — same record, same customer entry, same manifest — not create a standalone transaction that fragments the customer view. The kiosk POS surfaces the existing package on a quick lookup (reference, email, phone, name) and the till operator attaches the add-on in seconds.
Where most evaluations go wrong
The most common mistake is evaluating on the demo flow single-product platforms also pass — sells a tour, takes a payment, prints a manifest. By the time the operator discovers "package" in the brochure was a discount code rather than a real construct, they've spent six months migrating to a platform that doesn't fix the original problem. Ask the vendor to build a real package live — anchor, two customer choices, a fixed leg, a dependency rule, a per-leg cancellation policy, a bundle discount — in front of you. If "we'll build that for you" comes up, the gap is structural.
The second is treating the legs as equal when they aren't. One leg in most packages is the dated, capacity-constrained one — usually the transport, sometimes the multi-night accommodation. The rest follow from it. A platform that models packages as a flat list will technically book the trip but won't let the operator constrain choices to compatible options as the customer moves through. The customer either makes an invalid combination (and operations picks up the call) or the platform refuses the booking late (and the customer drops off).
The third is under-weighting the operational layer. Building the package on the website is the part you'll evaluate hardest in a demo; the harder part is the day the experience leg cancels in bad weather and the operator needs to fire SMS to twelve customers across six packages, refund just that leg, leave the rest intact, and reflect the change on the activity guide's manifest, the front desk, and the office's day-of view in the same second. The operational view is where multi-modal platforms actually earn their keep.
A 10-question framework you can put to every vendor
Print this. Run every vendor against it. Score each answer 1–5 against your operation and total it up. The highest total isn't necessarily the right answer, but it gives you a defensible comparison.
The package construct itself. Walk us through modelling a three-leg package — transport, accommodation, experience. Is the package a single booking record with leg-level detail, or three bookings stapled together?
Anchor + choices + fixed legs. Show us how we'd set the transport leg as the anchor, offer a choice from three experience legs, fix the accommodation on Saturday night, and add a dependency rule that drops the wine-tasting option when children are on the booking. Edit live.
Capacity simultaneity. Two customers booking the same three-leg package at the same time. One cabin left, one activity slot left, twenty ferry spaces. Walk us through exactly how the platform decides who gets the package and what the other customer sees.
Per-leg pricing modes. Can we price the transport per-sector, the accommodation per-night with a category modifier, and the experience flat per person — all in one package? Can we apply a peak-period uplift across the whole package on a date pattern different from any leg's own price-list version?
Channel rules at leg and package level. Show us how we'd set the package direct-only while the underlying transport still sells through OTAs as a standalone, capped at a fraction of capacity. How does the platform resolve which rule fires when an OTA tries to book the standalone vs the direct customer booking the package?
Per-leg revenue recognition. A weekend package sells with a bundle discount across ferry, cabin, and experience priced individually. At month-end, what does the revenue-by-product report look like? Show us. If the legs sit across separate operators, what does the reconciliation report look like?
Per-leg vs per-package cancellation. The experience leg cancels for weather; the ferry ran and the cabin was occupied. Walk us through, click by click, how we refund just the experience leg, fire SMS only to the affected customers, leave the rest intact, and log every action.
Walk-up add-on attaching to a pre-booked package. A customer with an existing booking walks up to reception and wants a sunset-cruise upgrade. Show us the kiosk POS — how does the till operator find the existing package, attach the add-on, and have it reflected on every leg's manifest in the same second?
Live manifest across legs. Show us the activity guide's tablet, the ferry crew's manifest, the front desk's day-of view. Same data refreshed per leg, or three views that go out of sync? A no-show on the ferry — does the activity guide see the party of four become a party of three before the activity starts?
Reporting and BI. What's the standard view of a package across its lifecycle — booking through trip through revenue recognition? What BI layer sits behind it? Can we segment performance by package, leg, partner, channel, season — without exporting to CSV?
What the answers should sound like
A confident answer is specific. A vague answer is a warning.
On the package construct, a strong vendor draws the data model — package as parent record, legs as children, customer record holding consistent across them. On the choice structure, the vendor edits a package live, adds a leg, marks it as a customer choice, attaches a dependency rule, and shows the customer-facing flow update without a redeploy. On capacity simultaneity, the vendor walks the contention scenario click by click — both customers in the flow, the allocation logic, the loser's "this combination is no longer available" message — without "that's an edge case we'd handle in support". On per-leg revenue recognition, the vendor pulls up a real example report; if "we'd build that report for you" is the answer, you're being sold a service contract, not a platform. On the cancellation flow, the vendor runs the operator-initiated single-leg cancel with the SMS template and audit log open. On walk-up attachment, the kiosk demo opens an existing package by reference in seconds and writes the add-on into the same record.
Red flags: "we'll build that for you" (custom development locks you in); "that's on the roadmap" (you're buying a promise); "you'd export to CSV and reconcile" (the platform doesn't actually do what you need); "it's just a configuration change" without it shown live; reference customers the vendor declines to name. The single most useful input you'll get is a reference call with an operator running a multi-modal package at roughly your level of complexity — what their evaluation surfaced, what the first six months looked like, where the platform still gets in the way.
Where JetSetGo fits in your shortlist
JetSetGo is one of the platforms worth putting through the framework above. Packages are a real transactional construct with leg-level detail, anchor + choice + fixed legs, and dependency rules editable in a visual builder. Capacity holds against every leg's own model simultaneously, all-or-nothing. Per-leg pricing runs flat, consumption-based, per-night, per-sector, or per-package bundle. Channel rules resolve per leg and per package through allocation groups. Cancellation policies fire independently or linked. Revenue allocation across legs and partners is recorded at booking time and surfaces in the BI layer for audit-grade reporting. Walk-up add-ons attach to the existing package booking and write to the unified customer record.
If your evaluation surfaces multi-leg packages with structured choices, capacity simultaneity, per-leg revenue recognition, mixed-channel exposure, or per-leg cancellation as load-bearing requirements, JetSetGo is worth shortlisting.
Where to go next
The deepest segment overview is the multi-modal booking platform pillar. When one product type is the centre of gravity, the ferry booking system pillar and the tour operator software pillar go deeper. The capability docs on the multi-modal package builder, the pricing engine, channel management, cancellation policies, and durational and multi-sector services are the mechanics behind the framework above. The Package Builder article is the architectural deep-dive on what separates a real package construct from bundled discounts.
When you're ready to put a vendor through the framework, book a demo.