JetSetGo's Pricing Engine — Capability Documentation

JetSetGo's pricing engine is the part of the platform that decides what a booking costs. It runs across every product type — passenger ferries, vehicle ferries, buses and coaches, accommodated cruising, sleeper rail, day tours, and multi-modal packages that combine more than one product type into a single booking. One engine, every product.

This doc is for operators evaluating whether JetSetGo's pricing depth can model their actual fare structure — seasonal tiers, per-channel rules, consumption-based vehicle rates, per-night cabin pricing, package-level pricing across multiple products, early-bird and surge logic, concession recognition at the counter. The capabilities below describe what the engine models and how it resolves a price at the moment a customer asks for one.

Who this matters to

Operators with a flat single-rate-per-product fare structure rarely need a deep pricing engine. Operators with any of the following do:

Multi-dimensional inventory — vehicles measured by lane metres, tonnage, height, hazardous-goods class; cabins measured by berth count and category; freight by tonnage.
Multiple channels — direct website, kiosk, agent portal, OTA connectors, trade accounts. Each channel may see a different price, a different allocation cap, or a different rule set.
Seasonal variation — peak, off-peak, shoulder, school holidays, weekend-vs-weekday.
Yield or revenue-management goals — early-bird discounts, surge above a capacity threshold, channel-mix shaping, premium-tier inventory protection for direct customers.
Concession and verified-customer pricing — resident cards, pensioner cards, trade-account rates, repeat-customer loyalty tiers.
Multi-product packages — a transport leg plus an accommodation night plus an experience at the destination, sold as one transaction with a price that reflects the bundle rather than the sum of the parts.
Per-sector or per-leg routes — multi-stop journeys where a passenger boarding at the second stop pays for fewer legs than one boarding at the origin.

If any of those describe your operation, the pricing engine is load-bearing — the depth of what it can model decides what you can do.

What the engine operates on

The engine resolves a price for every line in a booking. Each line is the combination of:

A product — the bookable thing (a ferry sailing, a cabin on a cruise, a seat on a tour, a vehicle space on a deck, a coach seat).
A fare type or vehicle type — adult, child, infant, family, senior, resident, trade; car, motorbike, truck, oversize, EV, trailer. Operators define these.
A date — the date of travel decides which version of the price list applies.
A channel — direct website, kiosk POS, agent portal, OTA connector, phone reservations.
Optional consumption signals — lane metres for vehicles, tonnage for trucks, nights for cabins, sectors travelled for multi-stop routes.
Optional context — verified concession status, days-to-departure, current capacity fill, custom fields captured at the booking step, promo codes entered.

The engine resolves a price for each line, applies rules that match the booking's full context, and returns the final number the customer pays. Every evaluation is logged for audit and debug.

The four pricing modes

JetSetGo's pricing engine treats every priced line as one of four modes. Operators pick the right mode per fare type, per vehicle type, per route, per service — different modes can co-exist inside the same booking.

Flat pricing

A fixed rate per fare type or vehicle type. "Adult $35. Child $18. Car $85. Motorbike $35." The simplest mode, and for many operators most of the price card sits here. Flat pricing is the default when no consumption rule is configured.

Consumption-based pricing

Priced by what the booking actually uses. The operator picks which dimension drives the price.

Per lane-metre — a car billed by the metres it consumes on the vehicle deck. A small hatchback and a long ute are different prices on the same fare type because they take different amounts of deck.
Per tonne — a truck billed by tonnage as well as lane metres. Heavy-vehicle and freight pricing where both axes matter.
Per berth — a cabin priced by the number of berths used inside it. A four-berth cabin with two passengers prices differently from the same cabin with four.
Per kilo or per cubic metre — for freight and cargo operations where volume or mass is the unit of capacity.

Consumption-based pricing meters whatever the operation actually meters. Operators who run weight-rated decks turn tonnage on; operators with no overhead constraints don't. The dimensions that don't apply to your operation simply aren't part of your pricing.

Per-night and per-sector pricing

For products where the unit of consumption is time or distance rather than a flat seat.

Per night — accommodated multi-day services priced by the night between check-in and check-out. A four-night cabin booking prices as four nights times the per-night rate, plus any category modifier. Useful for cruise cabins, sleeper-rail compartments, liveaboard tours, and any product where the customer pays by the night.
Per sector — multi-leg journeys priced by the legs the passenger actually rides. A customer boarding at the second stop and disembarking at the fourth pays for two sectors; a customer boarding at the origin and riding the whole way pays for the full set. Useful for coach networks, multi-stop ferry routes, and rail services with intermediate stops.

These modes recognise that some products don't price like a flat seat — and trying to flatten them produces a fare card that doesn't reflect what the customer is actually buying.

Combining modes

Most operations end up combining modes. A vehicle ferry might run flat passenger fares, consumption-based vehicle rates by lane metre, per-night cabin pricing for an overnight service, and per-sector logic for a multi-port route — all on the same booking. The engine resolves each line in its own mode and presents one price to the customer.

The same applies to packages. A multi-modal package can carry per-sector on the transport leg, per-night on the accommodation leg, and flat per-person on the experience leg — sold as one package price with each component priced in the mode that fits it.

Versioned price lists

Every priced product carries a price list. A price list contains versions, and each version is bounded by a date range and an optional tier and category. The engine resolves a booking against the version that applies on the booking's date of travel.

Versions let operators model the real shape of a year:

Peak — summer, holidays, high-demand weeks. Higher tier rates apply automatically when the booking date falls inside the peak range.
Off-peak — quiet weeks. Lower rates apply.
Shoulder — the in-between periods that aren't quite peak but aren't off-peak either. Operators who run a three-tier or four-tier calendar use this mode.
Holiday — school holidays, public holidays, and named periods that don't fit a regular peak rhythm.
Weekday vs weekend — versions that apply only on certain days of the week.

Versions can also target product categories — a Standard version and a Premium version covering the same dates, each pricing its own category. When a booking lands, the engine picks the version that matches both the date and the category, with a fallback chain that resolves to a more general version when an exact match doesn't exist.

The operator sets versions once. The engine applies the right one on the right day, every day, without an operator having to remember which season is active.

Versions can be duplicated as a starting point for next year's equivalent period — most operators rebuild their seasonal calendar by duplicating last year's versions, shifting the dates, and adjusting the rates that need to move.

Set per service, per route, per season, per channel

Pricing in JetSetGo isn't a single price card. Operators set rates across whichever axes their operation cares about.

Per service — one specific sailing or departure can carry override pricing without affecting the rest of the schedule.
Per route — different routes can have entirely different fare structures even on the same vessel.
Per season — versioned price lists handle the date axis.
Per channel — direct website rates can differ from agent-portal rates, which can differ from OTA-channel rates, which can differ from kiosk POS walk-up rates. This is the surface where the operator decides what each channel sees.

The combination matters. A single operation can run versioned seasonal rates on the direct website, trade rates on the agent portal, standard-category inventory only on OTA channels with a capacity cap, and walk-up kiosk pricing with concession recognition — all from the same price list, all applying in the same second when a customer asks for a price. Each channel sees a different subset of inventory at a fare that follows the version applying on the date — never a hidden direct-customer markup.

The visual rules engine

Versioned price lists set the base fare. The rules engine handles everything that doesn't fit a flat tariff — the dynamic adjustments that depend on context.

The rules engine is a visual editor: operators build rules by selecting inputs and outcomes in a structured editor, not by writing code. A rule has a description, a date range it's active over, a priority that decides the order it runs in, and a draft-vs-active state so operators can build and test before going live.

Rules typically take one of these shapes:

Early-bird discounts — "10% off when booking more than 30 days ahead."
Surge above a capacity threshold — "Weekend surcharge of 15% when capacity is above 80%."
Concession recognition — "Resident rate applies on a verified resident card at the kiosk."
Trade-account pricing — "10% off for verified corporate accounts on weekday sailings."
Loyalty tiers — "Repeat-customer discount on the fourth booking of the calendar year."
Promo codes — "Code SPRING25 applies a 15% discount on bookings made in March."
Channel-specific tiers — different tiers visible to different channels (see below).
Conditional surcharges — hazmat surcharges, oversize-vehicle surcharges, peak-period surcharges that need to fire only on specific combinations.
Bundle pricing — discounts when a package combines specific products.

Each rule produces an adjustment or a validation outcome — a discount, a surcharge, a fee, an eligibility decision. The pricing engine applies them on top of the base fare, in priority order, with every evaluation logged. An operator who wants to know why a particular booking got the price it did can look at the audit trail and see every rule that fired, every rule that didn't, and why.

Rules can be built from templates for the common patterns (percentage discount, fixed fee, peak-day surcharge, bundled add-on) or from scratch when the logic needs branching. An inline tester runs a sample booking context through a draft rule and shows the result without affecting live bookings.

Product variations — selling the same seat under multiple fare structures

JetSetGo's variations system is one of the more revenue-load-bearing parts of the pricing engine. A product (a ferry seat, a tour place, a cabin night, a coach trip) can be sold under multiple variations that share the same underlying physical inventory but carry different combinations of price, cancellation terms, included add-ons, and channel availability.

The primary differentiator in most operators' variation stacks is cancellation flexibility:

A Non-Refundable Saver variation sells for less than the standard fare but locks the customer in. They've taken a price discount in exchange for certainty for the operator.
A Standard variation sits at the base rate with a moderate refund policy.
A Fully Flexible variation sells for a premium and refunds up to close to departure.

Customers who plan to definitely travel pick the Saver; customers who want insurance pick the Flex and pay the premium; everyone else picks Standard. Operators capture the extra revenue from customers who value flexibility, instead of bundling it into the base fare and effectively giving it away.

Variations can carry more than just cancellation differences:

Bundled add-ons. A premium variation can include normally-priced add-ons at no extra charge — a coffee voucher included with the Premium Ferry Fare, a luggage allowance bundled into the Flexible Coach Fare, breakfast and lounge access included with the Premium Cabin. The add-on is still tracked as its own line on the booking (so reporting can decompose it later), but it prices at zero because the variation includes it.
Inventory caps per variation. A "Value Deal" variation can be capped at a certain percentage of capacity per service without changing the overall capacity of the service. Once the variation hits its cap, only the higher-priced variations remain bookable. This is yield management without separate ticketing.
Channel availability. A variation can be available on some channels and not others — a Trade-Only variation that doesn't appear on the public website, or a Flexible variation that's direct-only with no OTA distribution.

The customer sees the available variations side-by-side at booking ("Standard $35", "Flexible $45", "Saver $28"), picks one, and the platform records which variation was selected. The pricing engine prices the chosen variation; the cancellation engine respects its policy; the allocation system enforces any per-variation caps and channel restrictions.

See the cancellation policies capability doc for the cancellation side, and the channel management doc for the per-channel and per-segment allocation side.

Third-party dynamic pricing integration

The visual rules engine described above is the operator-configured path. Operators set every rule by hand; the platform applies what they've configured. For most operators that's enough — pricing depth comes from combining versioned price lists, channel inputs, variation inputs, consumption inputs, and the rules engine.

For operators running an external dynamic-pricing or revenue-management system — purpose-built tools used in some segments of the transport and hospitality industries — JetSetGo can be integrated with any such system upon request. The specific integration shape depends on the partner system: some expose APIs the platform reads from, some accept rate pushes from the platform, some run as middleware between availability and pricing. The integration design is scoped per engagement.

This matters because the alternative — forcing operators to choose between the platform's pricing engine OR their dynamic-pricing system — pushes them into using one and disabling the other. JetSetGo's stance is that the operator-configured side and the algorithmic side can compose: operators don't have to pick.

For operators not running an external system, this entire layer is invisible — the visual rules engine does everything they need.

Pricing across every product type, one engine

The same pricing engine prices a vehicle ferry sailing, a coach seat, a cabin on a multi-night cruise, a sleeper-rail compartment, a day-tour seat, a freight container, and a multi-modal package that bundles several of those into one booking. Operators with more than one product type run them through one engine — not three.

Two consequences:

One configuration model. An operator running a ferry and a tour and an accommodation product configures pricing once, in one place. Versioned price lists work the same way on every product. Rules look the same. The audit trail is unified.
Package-level pricing is native. When products are bundled into a single package, the engine prices each leg in its own mode and the package as one bundle price. The platform tracks the package as one transaction and the individual legs separately for reporting, so revenue can be split back to each component without double-counting.

A worked example

Consider an operator running an overnight transport-and-accommodation service: a vessel that carries passengers, vehicles, and freight on a route with two intermediate stops, with cabins for an overnight crossing and the option to package the crossing with a destination experience.

Their pricing might look like this:

Passenger fares are flat per fare type, with versioned price lists for peak summer, shoulder spring and autumn, and off-peak winter.
Vehicle rates are consumption-based by lane metre, with tonnage as a second axis for trucks above a threshold. Peak vehicle rates apply in summer.
Cabin rates are per-night with a category modifier — standard cabin, premium cabin with ensuite, suite. Premium and suite categories are sold under their own variations, which include bundled add-ons (lounge access, breakfast) and stay direct-only; OTAs and aggregators sell the standard variation.
The route is per-sector. A passenger boarding at the origin and disembarking at the destination pays for two sectors; a passenger boarding at the second stop and disembarking at the third pays for one.
A package ties the crossing with a destination experience. The crossing prices per-sector and per-cabin-night; the experience prices flat per person; the package sells as one bundle price with each component priced in its mode and the customer seeing one total.
Rules layered on top: early-bird discount more than 60 days out, weekend peak surcharge above 80% capacity, resident concession on a verified resident card at the kiosk, hazmat surcharge for declared dangerous-goods vehicles, trade-account rate for repeat-freight customers on a verified corporate account.

That entire structure runs on one engine, with one configuration model, with audit trails on every evaluation. The customer sees one price. The operator sees the revenue split back to each component for reporting.

A simpler example: a single-route day-tour operator with peak and off-peak versions, child and senior fares, an early-bird discount more than 30 days out, and a 40%-capacity OTA cap. That uses a fraction of the engine's depth and is also fully supported. The platform scales down as cleanly as it scales up — capabilities you don't need aren't part of your configuration.

How pricing composes with other capabilities

The pricing engine doesn't sit alone. It composes tightly with:

Channel management — channel rules decide which inventory categories each channel can sell and at what cap. The pricing engine respects those rules and applies any channel-specific rate adjustments on top.
Cancellation policies — refund tiers and cancellation fees are configured separately from pricing but operate on the same booking context. A cancellation policy can reference the original price paid, the version that priced it, and the time elapsed since booking.
Multi-product packaging — package-level pricing sits inside the engine, but the package structure (anchor leg, choices for the rest, cross-leg dependency rules) lives in the package builder. The two compose: the structure decides what can be bundled, the engine prices the bundle.
Operational tooling — concession recognition at the kiosk POS, audit reporting on every rule evaluation, dynamic pricing dashboards that show booking velocity against expected curves, the simulator that lets operators model a pricing change before going live.

For more on these, see the pillar pages on tour operator software, ferry booking system, and multi-modal booking platform.

What the pricing engine doesn't try to be

The pricing engine itself doesn't invent dynamic prices from a built-in black-box algorithm. The operator-configured side (versioned price lists, the visual rules engine, variations) applies what the operator has configured, transparently and with full audit trails. For algorithmic dynamic pricing, the engine integrates with whichever external dynamic-pricing or revenue-management system the operator already runs or wants to plug in — see the section above. The platform doesn't impose one model over the other; both can compose on the same booking.

It is also not a billing or accounts-receivable system. It decides what a booking costs at the moment of booking. Invoicing, accounting integration, and downstream financial reporting are separate concerns that consume the pricing engine's output.

And it is not a one-shot configuration. Operators iterate — duplicating last year's versions for next year, adjusting rates based on what the dashboards surface, tuning rules when channel mix shifts, recalibrating variation premiums based on actual customer choice mix.

Where to go next

Tour operator software — the broader pillar on tour, activity, and multi-product operations.
Ferry booking system — the broader pillar on passenger and vehicle ferries, with the deeper inventory model that the pricing engine prices against.
Multi-modal booking platform — when transport, accommodation, and experiences are sold as one packaged product.
Channel management — how channel rules and per-channel pricing combine.
Cancellation policies — the refund-and-cancellation side that sits next to pricing.

Book a demo →

Cancel anytime. You own your data.