Durational and Multi-Sector Services — Capability Documentation

Most booking platforms assume the unit of sale is one service: one departure, one tour, one seat. JetSetGo handles that case, but it also handles the harder shape operators run into when their product extends past a single service instance: a multi-night cruise that crosses five nightly services as one reservation, a sleeper-rail compartment held across an overnight departure, a multi-leg coach journey priced by the legs the passenger actually rides.

This doc is specifically about that shape — one reservation that maps to multiple service instances. The customer treats it as one trip; the platform tracks consumption, allocation, and reporting across every service the reservation touches; the operator sees a unified record.

(For a different shape — multi-modal bookings where transport, accommodation, and an experience are sold together as multiple reservations under one booking, possibly bundled as a package — see the multi-modal packages capability doc. Multi-modal isn't a sub-mode of this concept; it's a separate construct.)

Who this matters to

Single-service operators (one tour, one ferry sailing, one venue session per reservation) rarely need this depth. Operators who run any of the following do:

Multi-night accommodated services — river and coastal cruises, expedition vessels, liveaboards, sleeper trains, multi-day tours with included accommodation, hotel stays sold through the same platform as the transport.
Multi-leg or multi-stop routes — coach networks with multiple pickup and drop-off stops, ferry routes that call at more than two ports, rail with intermediate stops, multi-stop tour itineraries.
Through-tickets and connections — a ferry leg plus a coach connection at the destination, sold as one journey, with both services allocated and priced under one reservation.
Operators planning to grow into any of the above — the model that supports complex multi-service reservations also handles the simple single-service case, so growing into it later doesn't mean migrating off the platform.

The underlying model: one reservation, many services

In JetSetGo, a booking is a top-level container. Inside it sit one or more reservations, and each reservation is what the customer thinks of as "the thing I booked". A reservation can map to one service or many.

When the reservation is simple (one ferry sailing, one tour, one seat at a venue), it maps to one service. When the reservation is durational (a four-night cruise, a sleeper-rail overnight, a multi-day liveaboard) or multi-sector (a coach booking that rides three legs of a five-stop route), the reservation maps to several services — but it's still one reservation, with one set of passenger details, one price total, one cancellation policy, one ticket reference.

This is the load-bearing difference vs. platforms that force "one booking equals one service". On those platforms, a four-night cruise sold as one trip becomes four separate bookings (one per night), or one synthetic booking that doesn't decompose for reporting. JetSetGo's model keeps the customer's "I booked one trip" mental model intact while letting the operator see, allocate, and report on every service the booking actually touches.

Mode 1 — multi-night durational services

When a booking carries both a check-in date and a check-out date, and the resource is one the platform knows how to schedule on a nightly basis, the booking engine discovers every nightly service in the date range and aggregates them under the one reservation.

What that looks like in practice:

A four-night river cruise booked check-in 5 March, check-out 9 March, on Vessel X. The platform finds the four nightly services (5th, 6th, 7th, 8th), allocates the customer's cabin across all four nights, prices each night, and writes one reservation that maps to four services.
An overnight sleeper-rail booking between two cities with the compartment held across the journey. Compartment inventory is allocated to the booking for the duration the passenger occupies it.
A liveaboard dive trip running multiple nights with the customer in the same bunk the whole time.
A hotel stay sold through the operator's booking platform alongside their transport product, with the room held nightly.

The same reservation can also carry related but separately-tracked bookings — for example, the cruise's day-three shore excursion that operates on day three is its own service, allocated to its own inventory, but linked to the cruise reservation so the operator can see they belong to the same customer journey.

Mechanical points worth knowing:

Per-night pricing can be configured as a per-night rate, a flat per-stay rate, or a tiered structure where some nights cost more than others (weekend nights priced higher than weekday nights, for example). The pricing engine evaluates each night against the version of the price list that applies on that night's date, so a stay that crosses a seasonal boundary picks up both sides correctly.
Allocation persists across the duration. The cabin, compartment, or room held on night one is the same one held on night four. The platform doesn't release and re-allocate per night.
Mid-stay changes are an edit on the reservation, not a re-booking. Extending by a night, swapping cabin categories, adjusting passenger count — all done on the one reservation.
Reporting decomposes back to per-night service utilisation. The operator can ask "how full was the cabin deck on night three of the season" and the platform answers because every reservation that occupied a cabin on night three has a row against night three's service.

Mode 2 — multi-sector and multi-leg services

The other shape of "one reservation, many services" is when the journey crosses multiple stops on a route, or stitches multiple services together as connections.

JetSetGo's route model is a list of stops with services that visit them, not a list of point-to-point services. A coach running A–B–C–D–E publishes one service per scheduled departure; the route metadata says it calls at all five stops. A customer booking from B to D is riding two sectors (B→C and C→D) of one service. A customer booking from A to E is riding all four sectors of the same service.

Pricing can follow consumption. With sector-based pricing enabled for a fare type, the platform meters the sectors the passenger actually rides and prices accordingly. A→E pays for four sectors; B→D pays for two. The pricing engine handles this natively — operators don't need to publish a separate B→D fare and an A→E fare and every other combination. The fare card stays manageable while the prices reflect what the customer actually consumes.

When a journey requires a connection between services — a coach that ends at a port and a ferry that departs from the same port forty minutes later, sold as one through-ticket — the platform can treat the two services as a single journey for booking purposes. The customer books from origin to final destination; the platform allocates inventory on both services, prices both legs, issues one ticket reference, and tracks the connection as a single reservation.

Mechanical points worth knowing:

Stop-and-route data is operator-defined. Operators draw their routes once with the stops they actually call at. New stops added later become bookable without re-publishing the schedule.
Sector counts can include subsequent-service sectors. A multi-leg booking that crosses a connection counts the legs on both services for sector-based pricing.
Inventory is consumed on every service the booking touches. A coach-plus-ferry through-ticket consumes a passenger seat on the coach AND a passenger space on the ferry — both checked, both allocated, both decremented.
Availability check is all-or-nothing. If the connection leg has no inventory left, the originating leg's allocation isn't made either. The booking fails as a unit and rolls back. The customer is never left holding half a journey.

Multi-modal bookings — a ferry ticket plus a tour plus a hotel night, sold together — are a separate shape. They are multiple reservations inside a single booking, often grouped into a package. Each reservation in the package is its own thing: its own service, its own inventory consumption, its own per-leg pricing, its own cancellation behaviour. The package layer ties them together for the customer experience.

The shape this doc describes is different. It's about ONE reservation that internally maps to MULTIPLE services. A four-night cruise is one reservation (one cabin held continuously, one cancellation policy, one ticket reference) that the engine resolves against four nightly services. A multi-leg coach booking is one reservation that rides multiple sectors of one service.

The two shapes can compose. A multi-modal booking might contain one reservation that is itself durational (the cabin leg of a cruise + flight package, where the cruise reservation maps to multiple nightly services). At that point you've got both shapes operating at once: multiple reservations under one booking (the package), and one of those reservations mapping to multiple service instances (the durational cruise leg). They sit cleanly together because they operate on different levels of the data model.

See the multi-modal packages capability doc for the package shape.

Cabin and compartment inventory inside durational services

When a durational service has bookable units (cabins, compartments, rooms, berths), the inventory model handles them as part of the broader inventory tree the platform models for every resource.

The hierarchy can go as deep or as shallow as the operator needs:

A simple ferry cabin layout — categories (interior / oceanview / suite), each with its own count, no per-cabin selection. Bookings come in, the engine allocates one cabin from the right category.
A cruise with per-cabin selection — each individual cabin is bookable by number; the customer picks Cabin 207. Categories sit above as a filter and a pricing dimension.
Compartments on sleeper rail — multi-berth compartments that can be sold whole-compartment (one party of four occupies it together) or shared (multiple solo travellers share a four-berth compartment as four separate bookings). Operators decide which model fits their service.
Hotel-style rooms — check-in / check-out semantics, per-night rate, room category as a pricing dimension.

Allocation rules are operator-controlled. A cabin category can sit inside an inventory allocation rule that restricts it to certain customer segments — a premium category that only the direct channel sells, or a corporate-account category that only opens to verified trade clients. These restrictions are configured through the inventory allocation system described in the channel management doc.

What the model does NOT try to do:

Track ad-hoc room adjacency. Cabin and room layouts are modelled as inventory units with categories; the platform does not encode "the suite next door to my parents' suite" as a system-level relationship. If adjacency matters for a specific customer party, that's a manual operator-side decision when the cabins are allocated.
Manage housekeeping rotation, hospitality services, or in-cabin amenities. Those are operations sitting alongside the booking system, not inside it.
Impose a fixed cabin-grading taxonomy. Operators name their own categories and decide their own hierarchy.

How pricing composes across services within a reservation

A durational or multi-sector reservation can apply different pricing modes to the services it touches. A multi-leg coach booking might price per-sector across all legs at one fare; a multi-night cabin reservation prices per-night across all nights; a sleeper-rail compartment held across an overnight journey can combine per-sector pricing for the rail journey with per-night pricing for the bunk inside it. The engine applies pricing per priced line, where a line corresponds to a passenger plus a service plus a fare type. Different services inside the same reservation can carry different pricing modes without conflict.

Some operator-visible consequences:

The customer sees one price total for the reservation. The internal decomposition is invisible to them.
The operator sees the decomposition. Reports break revenue back to each component service — night-by-night cabin revenue, sector-by-sector route revenue — all tracked separately even though they were sold under one reservation.
Cancellation operates on the reservation, not the underlying services. When a cancellation policy refunds 100%, it refunds the whole reservation's value, regardless of how many services it spanned.

A worked example — a multi-night, multi-sector reservation

Consider a coastal cruise operator running a four-night itinerary that picks up at one port, calls at two intermediate ports, and disembarks at a fourth. They sell:

Whole-itinerary bookings — passenger boards at port 1, sails for four nights, disembarks at port 4. Passes through all four nightly services, all three sector legs.
Partial bookings — passenger boards at port 2 for the back half of the itinerary. Three nights, two sector legs.
Day-of shore-excursion add-ons — a shore-excursion service operating on day 2, with its own inventory.

For a passenger booking the whole itinerary plus the day-two shore excursion:

One booking at the top.
Two reservations inside the booking: the cruise reservation, and the shore-excursion reservation.
The cruise reservation is the durational + multi-sector shape this doc describes: one reservation, four service rows (one per night), one cabin held continuously, sector pricing across the route. One cancellation policy on the reservation; one ticket reference for the trip.
The shore-excursion reservation is a single-service reservation in its own right: one service, one seat allocated, one flat fare. It has its own cancellation policy that can differ from the cruise's.
The customer sees one price total at checkout — the booking sums across both reservations.

For the partial booking (port 2 onwards) without the shore excursion:

One booking with one reservation inside it.
The reservation spans three service rows (nights 2–4), one cabin held across the three nights, three sector pricing.
Same containers, fewer underlying services on this trip.

For the operator's revenue report, the cabin's night-by-night utilisation and the shore excursion's day-two capacity decompose back to the services they touched. The cruise reservation and the shore-excursion reservation report separately for revenue while sitting under the same booking for the customer relationship. Nothing's lost; nothing's double-counted.

What this capability isn't

The durational-and-multi-sector model handles the underlying booking shape — one reservation mapping to multiple service instances. It is not:

A property-management system. The platform manages cabin, compartment, and room inventory and bookings against that inventory. It does not manage check-in keycards, housekeeping schedules, or front-desk operations beyond the booking record.
A specific itinerary planner. Routes, sectors, and connections are operator-defined. The platform supports them and enforces them; it doesn't propose itinerary changes or substitute alternative routes.
A pricing recommendation engine. Pricing is configured by the operator (see the pricing engine doc). What this doc describes is how priced lines compose when a reservation spans multiple services.

How this composes with other capabilities

Pricing engine — sector and per-night pricing live in the engine. Versioned price lists handle the date axis. Channel and inventory-citizen rules apply on top.
Multi-modal packages — a different shape entirely: multiple reservations under one booking, grouped into a package. The two compose cleanly — a multi-modal booking can contain a durational reservation as one of its legs.
Channel management / inventory allocation — cabin and compartment categories can carry segment-based allocation rules and per-channel restrictions like any other inventory.
Cancellation policies — policies attach to product variations, which in turn govern how a whole multi-service reservation is refunded.

Where to go next

Cruise booking platform — the pillar on multi-night accommodated sea services.
Sleeper rail booking software — the pillar on overnight rail.
Multi-modal booking platform — when transport, accommodation, and experiences get packaged.
Ferry booking system — multi-leg ferry routes specifically.
Pricing engine — per-night and per-sector pricing modes in depth.

Book a demo →

Cancel anytime. You own your data.