JetSetGo's Multi-Modal Package Builder — Capability Documentation

JetSetGo's package builder lets an operator sell several products as one bookable thing — transport to get there, an experience while there, a night or two of accommodation, transport back — on a single transaction, with one confirmation, one refund process, and one customer record. The package is a real booking, not a discount code applied across separate carts. The platform knows the legs belong together AND tracks each one separately for reporting and operations.

What the package builder is for

Operators tackling real-life messiness are rarely selling a single product type. A coach company that picks customers up at the airport, ferries them across, books them into a cabin overnight, and runs the day tour the following morning is selling one trip — but on most platforms that's four separate transactions across four separate systems with four confirmations and four refund flows when weather cancels the day tour.

The package builder treats that one trip as one booking. The operator configures the package — which legs go in it, which are fixed, which the customer chooses, which rules apply across the combination. The customer sees one search, one cart, one price, one confirmation. The platform checks availability across every leg in real time, blocks the sale if any leg is full, splits revenue back to each leg for reporting, and sends the right comms to the right leg's customers when something changes.

This is load-bearing for any operator selling more than one product type together. It's also relevant for operators with a single product today who are planning growth into a second. If you sell more than one thing — or plan to — this turns "four bookings across four systems" into "one booking with four legs."

What the engine models

A package is composed of legs. Each leg is a real product on the platform — a transport service, an experience, an accommodation stay, an add-on hire — and keeps its own configuration: capacity model, price list, check-in flow, cancellation rules, channel exposure. The package binds them together without flattening them.

On top of the underlying legs the package adds:

• The anchor leg — the leg the customer picks first. Usually the dated, capacity-driven leg that sets the package's timing.
• The choice legs — the legs the customer makes selections within. Choices can be among alternative products, among fare classes, among dates within an operator-defined window, or among optional add-ons.
• The fixed legs — the legs that don't vary once the anchor is picked.
• The dependency rules — the constraints the platform enforces across the combination. Rules can reference any leg's attributes: chosen date, fare class, passenger count, presence of a vehicle, accommodation tier.
• The package-level settings — bundle pricing, cancellation rules across the legs, channel exposure, confirmation template, the unified customer record.

Each leg's own model — passenger and vehicle types, deck or cabin or seat-area capacity, multi-night pricing, walk-up POS, QR scanning, audit log — is unchanged. The package builder doesn't reinvent any of that; it composes existing products into a bigger unit.

How the package is built — operator side

Packages are configured by the operator, not coded. The operator picks the legs from the existing product catalogue, sets which one is the anchor, defines what the customer is allowed to choose for the other legs, and lays in the rules that hold the combination together.

Picking the anchor

The anchor is the first decision. In most multi-modal packages it's the dated, capacity-constrained leg the rest of the package follows from. A transport leg with scheduled departures is a natural anchor — once the customer picks the morning departure, the accommodation arrival aligns, the experience day aligns, the return transport constrains to a sensible window.

The anchor doesn't have to be transport. A multi-night accommodated stay can be the anchor when the trip is built around the cabin booking. A multi-day guided experience can be the anchor when the experience is the centre of gravity. The anchor is whichever leg sets the timeline; the rest are arranged around it.

Defining the rest of the package

Once the anchor is picked, the operator lays out the rest of the legs. For each, the operator decides whether it's fixed (the same product on every package booking) or a choice (the customer picks among options).

Choice legs come in a few shapes:

• Choose among products — the experience leg might offer the snorkel tour, the glass-bottom-boat, or the kayak hire as alternatives.
• Choose among dates — a window of acceptable dates for the choice leg opens. A two-night-stay package might require the cabin nights to fall within 24 hours of the anchor transport departure.
• Choose among fare classes — the standard cabin or the premium cabin, the standard fare or the family pass.
• Choose add-ons — paddleboard hire, breakfast, equipment rental, transfers. The package can include some add-ons as defaults, leave others as optional upsells, and gate others behind specific fare classes.

Fixed legs are simpler — the operator picks one product, one date pattern relative to the anchor, one fare class.

Dependency rules across product types

The package's intelligence sits in the dependency rules — the constraints the platform enforces across the combination. The rules are operator-defined and run on the bookable attributes of each leg. Examples:

• A coach transfer can only be added if there's a sensible window between its arrival and the anchor transport departure.
• An accommodation leg must fall on the night of the anchor's date.
• A vehicle add-on on the transport leg locks out accommodation options without parking.
• A children's count above zero on the anchor drops the adult-only experience leg out of the choice list automatically.
• When a multi-night accommodated tour is the anchor, the on-board experience legs are pre-selected — they're part of the anchor's product.
• A specific accommodation tier may require a specific transport fare class to keep the trip's tier consistent.

Rules sit in the visual rule builder rather than being coded. The platform evaluates them in real time — choices that fail the rules drop out of the picker before the customer can pick them.

Package-level settings

• Bundle pricing. A discount applied to the package as a whole rather than to any individual leg. The customer sees the bundle price; the platform splits revenue back across the legs for reporting using a configurable allocation method.
• Promo codes and pricing tiers. A single code applies to the whole package. The package carries its own peak-period uplifts, channel-specific tiers, and versioned price lists — the same pricing tooling each leg has, applied to the bundle.
• Confirmation and comms. One confirmation email rather than four, laying out every leg with its date, time, location, and ticket.
• Cancellation handling. Linked (cancel one leg, the whole package cancels) or independent (each leg follows its own policy). Most operators run a hybrid — customer-initiated linked, operator-initiated independent.
• Channel exposure. The operator decides which sales channels see the package. A premium package can stay direct-only while the underlying transport leg still sells through OTAs.

How the package is booked — customer side

From the customer's side, a package is one search, one cart, one price, one confirmation. The structure stays the same regardless of how many legs the package contains.

1. Pick the anchor. The customer selects the anchor's date and time. The platform shows the anchor's availability in real time.
2. Make the choices. For each choice leg, the customer picks from the legs the rules allow. Choices that fail the dependency rules don't appear. As each choice is made, the platform updates the rest of the package — pricing adjusts, downstream choices narrow to the ones still compatible.
3. Add the add-ons. Any add-ons configured at the package or its legs surface as the customer moves through. Some are pre-selected because the chosen fare class includes them; some are optional upsells; some are mandatory in the chosen fare class.
4. Confirm and pay. One cart, one card payment, one transaction. One confirmation and one set of tickets covering every leg of the trip.

The flow runs from the customer's first interaction through to confirmation without ever leaving the package. Picking the transport and picking the cabin happen within the same flow, with the dependency rules and price updating in real time.

What the customer doesn't see — the platform is running availability checks against every leg's capacity model on every interaction. If any leg drops to zero mid-flow, the package becomes unavailable at the affected leg and the customer is shown the next available combination. The booking is only confirmed when every leg has been held against its capacity together. The package cannot oversell one leg to fit another.

The single-transaction property

The package is a single transaction. This is the property that makes the multi-modal sale work — and makes the operator's life easier after the sale.

• One payment. The customer pays once, on one card, at one moment. No risk of the customer paying for two legs then dropping off because the third payment failed.
• One booking record. The platform stores the package as a unified record with the leg-level detail attached. Every leg references the package; the package references every leg.
• One refund process when the customer cancels. The customer-initiated cancellation runs the package's policy — typically refund-or-rebook on the bundle as a whole. The operator doesn't process three refunds across three systems and reconcile them at month-end.
• Audit-clean reporting per leg AND per package. Each leg keeps its own reporting — passenger counts on the transport service, occupancy on the accommodation, participant numbers on the experience. The package adds a layer above — bundles sold, revenue per bundle, leg-by-leg revenue split, partnership reconciliation.
• One customer record across the legs. Every leg writes to the same customer record. Spend, attended services, no-show history, refund history, and preferences roll up to one customer rather than fragmenting across three product silos. For operators running loyalty schemes, marketing programs, or repeat-customer pricing, this is the change that makes those programs actually work across the operation.

Linked-entity nuance — both sides matter

A package leg is both a part of the package AND a thing in its own right. The platform tracks both.

As parts of the package — they share a transaction, a customer record, the package's cancellation logic when configured that way, a confirmation, and a package-level price when bundle pricing applies. They are allocated together — the booking confirms only when every leg has been held against its own capacity simultaneously.

As things in their own right — each leg retains its own product configuration, capacity model, check-in flow, boarding state, audit log, reporting feed, and channel rules where the leg is also sold independently. The transport leg's manifest shows the package passengers alongside the directly-booked passengers; the accommodation leg's occupancy report includes the package cabins alongside the standalone bookings.

This matters operationally — the crew running the morning manifest doesn't need to know who came in via a package. The package adds a layer above the legs without erasing the leg-level reality the operator's staff work with day-to-day. It matters for reporting too: partner reconciliation, channel-rule compliance, and marketing analysis all depend on legs being tracked separately enough to attribute revenue accurately and understand which combinations sell.

What the engine enforces

A handful of constraints run automatically. The operator doesn't write them; the platform enforces them.

• Capacity simultaneity. The package only confirms when every leg holds capacity against its own model at the same moment. A package with transport + experience + accommodation does not sell two of the three legs and leave the third oversold. All-or-nothing allocation is the load-bearing operational guarantee.
• Dependency-rule evaluation in real time. As the customer moves through the flow, the platform re-evaluates the rules on every interaction. Picking a different anchor date narrows the choices on dependent legs.
• Pricing rollup with allocation back to legs. The customer sees one price; the platform records leg-level pricing for reporting and reconciliation. Bundle discounts allocate back to legs using a configurable method.
• Per-leg vs per-package add-on attachment. Add-ons can attach at the package level (one paddleboard hire for the whole trip) or per-leg (separate equipment hire for each transport leg). The operator picks the model when the add-on is configured.
• Channel and inventory rule compliance. The package respects the channel rules of the operator and of each leg. If the transport leg is capped at 30% to a specific channel, the package's transport leg counts against that cap. If the package as a whole is direct-only, an OTA sees nothing.

How a package cancels

Cancellation can run two ways, and the operator chooses per package.

Linked cancellation (all-or-nothing). Cancelling any leg cancels the whole package. Useful when the package's value is the bundle — the trip is only worth selling if every leg happens. The cancellation runs the package's policy in full; the refund processes as one transaction back to the customer's original card.

Per-leg cancellation (independent). Each leg cancels on its own terms. When the experience is killed by weather, the experience refunds; the transport and accommodation legs remain intact and the trip continues. The customer gets refund-or-rebook comms for the affected leg, "your other legs are unchanged" for the rest.

Most multi-modal operators run a hybrid: customer-initiated cancellation linked, operator-initiated cancellation independent. The setting is on the package, with overrides per leg. Each leg's own cancellation policy still applies; the package decides whether the policies fire together or independently.

How packages compose with the rest of the platform

• Pricing. Every pricing-engine capability available on standalone products is available within the package — flat per leg, consumption-based per leg, per-night on accommodation, per-sector on multi-stop transport, per-berth on cabin inventory, per-package-bundle pricing, versioned price lists switching by date, channel-specific tiers, the visual rule builder for promotional and concession logic. See the pricing engine capability doc for the full surface.
• Channel rules. Packages sit in the channel-rule model alongside standalone products. The operator decides which packages are exposed to which channels, which are direct-only, which cap channel exposure at a percentage of capacity.
• Walk-up POS. A walk-up customer at any leg's kiosk can buy an on-the-day add-on that attaches to an existing package booking. The package record grows; the customer database stays unified.
• Capacity awareness across legs. Availability is recomputed in real time from each leg's underlying capacity model — lane metres on the vehicle deck, passenger seats on the transport, cabin berths on the accommodation, participant count on the experience. Package and standalone bookings draw from the same capacity pool.
• Audit log. Every leg writes to the operator's audit feed with full context — the parent booking, the package the leg belongs to, the leg itself, the linked customer record, the timestamp, the payment trail. Probity-grade audit reporting holds up across multi-modal as cleanly as it does on standalone bookings.

Worked examples

Transport + experience + stay + return transport. The anchor is the outbound transport departure; the experience is a choice (snorkel, glass-bottom-boat, or kayak); the accommodation is a choice (standard or premium cabin); the return transport is fixed to a window. The platform constrains the return to compatible departures. Per-leg cancellation when weather kills the experience; bundle cancellation when the customer cancels the trip.

A partnership package across separate operators. A transport company picks customers up, a separate ferry operator runs the crossing, a separate hotel runs the overnight stay, the transport company runs the return. Three operators; one package. Revenue allocation routes the right share to each partner automatically. Audit reporting per partner.

Multi-day accommodated journey with on-board experiences. A multi-night accommodated experience runs as the anchor — the customer picks the arrival night, the cabin type, and the number of nights. The on-board experiences are pre-selected because they're part of the anchor's product. Optional shore experiences are add-ons priced per leg.

What the package builder doesn't try to be

The package builder is not a promo-code engine bolted onto a single-product cart. A promo code applies a discount to a cart; a package is a structural object the platform tracks across its lifecycle from search through to post-trip reporting. Promo codes are a feature of the pricing engine, useful within and outside packages — not a substitute for a real package model.

The package builder is not a marketing-page tool. It models the bookable structure of a packaged product. The marketing presentation lives wherever the operator builds their site; the package builder gives the booking endpoint that backs whatever frontend the operator runs.

The package builder is not an itinerary planner for the customer. The customer picks the package the operator has built; they don't compose their own from arbitrary leg combinations. The package builder is for productised bundles the operator wants to sell with package-level rules and pricing.

Where to go next

• Multi-modal booking platform pillar — the broader story on selling transport + experience + stay as one platform.
• Pricing engine — how pricing composes across legs, bundle pricing, versioned price lists, channel tiers.
• Cancellation policies — refund tiers, linked vs independent leg cancellation, weather-event handling.
• Ferry booking system — when transport is the centre of gravity of the package.
• Tour operator software — when the experience is the centre of gravity of the package.

JetSetGo is tailored to your operation. You configure the legs that matter and the rules that hold them together — the dimensions that don't apply to your operation simply aren't part of your packages. Built with the ease of use small operators need, and the configurability the most complex multi-modal enterprises require. A platform you don't outgrow.

Book a demo →