Channel Management and Inventory Allocation — Capability Documentation

Most operators above a certain size run more than one path to market. Direct website, walk-up kiosk, agent portal, B2B corporate accounts, OTA connectors, partnership integrations. Each path carries a different cost, a different customer expectation, and a different operational behaviour. The platform that runs the inventory has to manage who sees what, who can book what, who gets priority when capacity is tight, and who can hold capacity back from the general pool.

JetSetGo's inventory allocation system handles this. Operators define groups (segments of customers, sales channels, or package paths) and set per-service rules for how each group is limited or reserved against the underlying inventory. The booking flow then enforces those rules automatically, with one effective group resolved per booking from three independent pathways.

This doc covers what the system models, how a booking gets assigned to one of these groups, and the operator-side knobs that decide how capacity gets shared across them.

Why this is broader than "channel management"

Most platforms call this layer "channel management" and treat it as a rule keyed off where the booking originated. That covers part of the story — but it misses the cases where the inventory rule should follow the customer, not the channel, or follow the package, not either of those.

JetSetGo models the layer above channels and customers as inventory allocation groups. Each group is a label the operator defines (for example "OTAs", "Travel Agents", "Corporate", "Package Bookings", "Premium Direct"). The same booking can match a group through more than one pathway, and the system resolves which group applies before allocating any capacity.

The three pathways the platform checks:

The customer's identity or customer-type. A booking made by a known travel-agent client, a verified corporate account, or a tagged VIP customer can resolve to a group regardless of which channel the booking came through.
The sales channel. A booking that came through an OTA API, the operator's own kiosk POS, an agent portal, or a partnership integration can resolve to a group on the channel alone.
The package the reservation is part of. When a reservation is being added to an existing package (for example a shore excursion added for a passenger already on a cruise package), the package itself can resolve to a group — useful for premium packages that grant their passengers access to inventory the public OTAs never see.

When more than one pathway matches, the operator's configured priority decides which one wins. A booking from a travel agent through the agent portal might match both "Travel Agents" and "Agent Portal" groups; the operator sets the importance ranking so one of those wins consistently. There's no fixed list of groups — operators define what makes sense for their operation.

The "where did this booking come from" channel is one of the three pathways, but it isn't the whole story.

What the allocation rules do

For each (service, inventory track, group) combination, the operator can set one of two rules: limit or reserve.

A limit caps how much of an inventory track a group can consume on a service. Once the group hits the cap, further bookings from that group are blocked even if physical capacity remains.

Examples:

OTAs limited to 40% of passenger spaces on a peak-season tour. The OTA can sell up to 40% of the day's capacity; the next OTA booking after the cap fails, while direct bookings keep going through.
Travel agents limited to 60% of cabin inventory on a popular cruise itinerary, so the direct channel always has at least 40% available.
B2B trade accounts limited to a fixed percentage of vehicle deck space on a vehicle-ferry service.

Limits are a ceiling on what a group can take. They don't reserve anything — if the group never reaches the cap, the rest of the operator's customers fill the unused share.

Reserve — hold capacity for the group with release timing

A reserve protects capacity for a group. Non-group bookings cannot touch reserved capacity until a release time, set in hours before the service departs.

Examples:

10% of cabin inventory reserved for corporate accounts, released 24 hours before sailing. The corporate group can book those cabins right up until departure; everyone else can only access them in the last 24 hours.
20% of vehicle deck space reserved for trade-account freight customers, released only at departure — protecting the freight allocation against passenger-vehicle demand even at peak times.
A package-bookings reserve across every sailing — package customers always find capacity, because the platform holds inventory back from individual-booking demand.

The release time gives operators a knob to balance protection against unfilled capacity. Reserves with a release window before departure get back to the general pool if the group hasn't used them, so the inventory doesn't sit unsold.

Both limit and reserve rules are configured as a percentage of the service's capacity on a given inventory track. They run per service, so the same group can have different caps on different services. They can stack across multiple groups — a service can carry a 40% cap for OTAs, a 10% reserve for corporates, and a 20% reserve for trade accounts simultaneously, all from the same allocation rule set.

How a booking gets its group

Every booking attempt runs through a resolution step that figures out which group, if any, applies. The three pathways are checked independently, and whichever has the highest priority wins.

The operator decides priorities. A booking that matches both "Premium Direct" via customer type and "Direct Website" via channel will resolve to whichever has the higher importance ranking. This is how operators keep allocation predictable: a known corporate account booking through the OTA still gets corporate treatment if the customer-pathway outranks the channel-pathway in the configured priorities.

If the booking doesn't match any group, it's a non-group booking. Non-group bookings are not subject to group limits — they can keep booking up to physical capacity. But they also cannot access reserved capacity until the release time. The default behaviour is that non-group bookings get whatever capacity is left after the group reserves have been applied.

Two-layer allocation: group rules first, physical inventory second

When a booking arrives, the platform runs two layers of capacity checks:

Group restrictions. Does this group have any remaining limit-headroom? Is the capacity it's asking for being held by another group's reserve that hasn't released yet? If the group-level check fails, the booking is rejected before physical inventory is touched.
Physical inventory. If the group-level check passes, the platform allocates against the specific bookable units (seats, cabins, lane metres, vehicle bays). This is where the cabin-on-deck-3-row-12 specific allocation happens.

This separation matters operationally. The group layer enforces operator-defined commercial rules ("OTAs get at most 40% of every sailing"). The physical layer enforces real-world constraints ("this specific cabin can hold two people, that one can hold four, the under-cover deck has 2.1m height clearance"). Both have to pass for a booking to confirm.

Per-channel pricing and per-channel rules

Inventory allocation is the heaviest lever, but it isn't the only per-channel surface.

Per-channel pricing

Pricing is configurable per channel. The same product can sell at a different rate on different channels — a rate that reflects the commission cost on an OTA, a negotiated trade rate on the agent portal, a partnership-integration rate, an unmarked direct rate. The pricing engine treats channel as a core pricing dimension, so versioned price lists, peak/shoulder/off-peak rules, and the visual rules engine all compose with channel as one of the inputs.

Combined with allocation rules, this becomes a revenue-management lever. The OTA's allocation can run on its own rate, the direct channel's allocation can run on the operator's full rate, a trade account can see a flat negotiated rate — all at once, all on the same booking ledger. A surge rule in the visual rules engine can lift the OTA rate during high-demand windows while leaving the direct rate steady, or vice-versa.

Per-channel restrictions on what a channel can book

Beyond inventory caps and pricing, channels can be restricted to specific product categories, specific fare types, specific cabin classes, specific routes, specific advance-booking windows. Each restriction is a rule the engine enforces at the booking attempt.

Common patterns:

An OTA can sell day-tour and standard-fare products only; multi-day packages and premium cabins stay direct-only.
An agent portal can apply trade pricing, book on credit, and place provisional holds. The website cannot.
A partnership integration can sell the transport leg of a packaged journey but cannot sell the standalone transport product outside the package.
A B2B portal can book under a longer advance window or a shorter cutoff than the public website allows.

A worked example

A multi-product operator runs a portfolio of day tours, a multi-night liveaboard product, and a vehicle-ferry service that connects the mainland to the touring destination. They sell through their own website, a walk-up kiosk at the wharf, a trade portal for travel agents, and an OTA connector.

Their allocation rules might look like this:

OTAs limited to 35% of passenger spaces on every tour, 25% of the vehicle-ferry passenger capacity, and zero on the liveaboard.
Travel agents reserve 10% of liveaboard cabin inventory, released 14 days before departure if unsold — protecting agent allocation in the booking window the agent customers shop in.
Trade-account corporate clients reserve 15% of the vehicle-ferry vehicle deck, released 24 hours before sailing — protecting commercial-vehicle access.
Package bookings (customers booking a tour-plus-ferry-plus-liveaboard package) sit in their own group with no cap and priority access to the liveaboard premium cabin category. This ensures package customers always confirm.

Their per-channel pricing:

Direct website runs versioned seasonal rates with peak surcharges.
The OTA connector sees the same versioned rate but with a markup that covers commission (the operator's gross stays the same).
The agent portal sees a trade rate flat across the year.
The kiosk POS sees walk-up pricing with concession recognition for verified resident cards.

The booking flow then enforces all of this automatically. An OTA booking that would push the OTA share above 35% on tomorrow's tour fails before the customer sees a price. A direct-website booking on the same tour at the same moment confirms because it isn't subject to the OTA cap. A package customer booking the liveaboard premium category gets it because the package group has priority access; an OTA customer attempting the same fails because the premium category is direct-only and the package category isn't visible to OTAs.

What this layer doesn't do

It isn't a marketplace. JetSetGo doesn't aggregate inventory across operators or take inventory positions itself. Operators connect their inventory to whichever OTAs and aggregators they choose; the rules in this layer decide what those connections expose.
It doesn't enforce parity rules. OTAs sometimes require operators to match their direct rate with the OTA rate. That's a contractual matter between the operator and the OTA. The platform supports per-channel pricing; whether an operator uses it to differentiate is their commercial decision.
It doesn't manage commission accounting. Commissions are tracked elsewhere in the platform on the financial side; the allocation rules are about capacity, not payment.
It isn't a substitute for operator judgment on which channels to work with. The platform supports any channel the operator wants to plug in. Channel selection is the operator's commercial strategy.

Operator-first by design

The business model behind these tools matters. JetSetGo isn't an OTA or an aggregator. The platform doesn't have a marketplace, doesn't take inventory positions, and doesn't compete with operators for end-customer attention. That means the allocation rules in this layer work in the operator's favour by default — the operator decides what each channel sees, what the OTA cap should be, when reserves release, which channels carry the negotiated rates. There's no marketplace-side incentive nudging the rules in a different direction.

For operators evaluating against marketplace-model platforms (Rezdy, FareHarbor): the underlying capability of "limit how much OTAs can sell" or "reserve allocation for trade" can look superficially similar between systems. The structural difference is where the platform's financial interests sit. With a marketplace platform, exposing your inventory to the marketplace is part of the deal. With JetSetGo, every channel is one the operator chose to wire in.

How this composes with other capabilities

Pricing engine — the channel and group dimensions are pricing inputs. Versioned price lists and the rules engine apply on top of allocation rules.
Cancellation policies — different product variations can carry different cancellation policies, surfaced to customers at booking through the variation selection (independent of channel, although different channels can sell different variations).
Multi-modal packages — packages can resolve to their own allocation group, granting package customers access to inventory that's not exposed to OTAs or general direct customers.
Durational and multi-sector services — cabin and compartment categories can carry allocation rules just like any other inventory track.

Where to go next

Tour operator software — the broader pillar on multi-product tour operations where allocation rules carry the most operational weight.
Multi-modal booking platform — when transport, accommodation, and experience are packaged and the package itself is a group.
Ferry booking system — channel and trade-account rules on the vehicle deck.
Pricing engine — the pricing side of per-channel differentiation.

Book a demo →

Cancel anytime. You own your data.