v2.0

GoRules Version 2 is here - redesigned, now with managed cloud.GoRules Version 2 is here!

Watch the launch videoWatch
gorules
Book a demoGet started

Offer management system rules
your revenue team owns.

Decide which ancillaries to offer, to whom, and at what price - seats, bags, upgrades, bundles - in visual decision tables evaluated in milliseconds inside your existing shopping flow. GoRules does not replace your revenue management system or your PSS; it is the decision layer they call.

From expired bid to sold seat,
start to finish.

Watch an evening in a revenue management team: a $340 upgrade bid expiring under a $400 floor, a one-cell change to the undersold-cabin rule, a replay over 8,400 expired bids, a signed release, and seats that sell before pushback.

scroll to play
Thursday, 16:20

A bid lands with 41 hours left.

K7QM2R offers $340 for business on LX 174 FRA-JFK. The cabin is 54 percent full at T-48 and the standing floor is $400.

The bid

$340 offered. $400 floor. Empty seat.

Fourteen J seats are unsold on a 787-9 and the forecast shows no late corporate demand. The bid expires below the floor and the seat flies at zero.

One cell

Revenue management fixes it herself.

The failing rule opens the live policy. On a branch, cabins under 60 percent at T-48 drop from a $400 floor to $340. Full cabins keep the full floor.

Proof before production

8,400 expired bids re-run.

Last month's below-floor bids replay against the draft while you watch: 1,900 would have cleared, $610k incremental, and nothing accepts on a cabin above 85 percent.

Sign-off

Revenue approves. v4.4.0 ships.

Jane Cooper signs the release, it promotes through staging to production with the full trail recorded. Rollback stays one click away.

Same evening

The seats sell before pushback.

Seat 2A goes first, then the map fills row by row as bids clear at the new floor - except on LX 38, already 92 percent full. Acceptance rate: 22 to 58 percent.

The offer changes daily.
The rules ship quarterly.

Ask an airline where its offer rules live and you get three answers at once: fare and inventory logic in the PSS, ancillary prices in a spreadsheet merchandising maintains by hand, and eligibility rules hard-coded in the booking flow, the check-in app, and the upgrade-bid tool. An offer management system is meant to put all of that in one governed place. Most carriers build the NDC pipes and leave the decisions exactly where they were.

So the change everyone in the room agrees on, lower the upgrade-bid floor on wide-bodies flying under 60 percent in business, waits for a release window in a system that was never designed to hold pricing judgment. The seats depart empty in the meantime, and a business seat that flies empty earns nothing at all.

The market answers with a platform migration. Offer and order suites from Amadeus, Sabre, and PROS, and the order-native PSS replacements behind IATA's Offers and Orders program, sell better retailing as the reason to move shopping, inventory, ticketing, and servicing onto a new stack. That is a multi-year transformation to fix what, at the level of the actual decision, is a rules problem. It is also why only about a quarter of carriers who say Offers and Orders matters have started the program.

Meanwhile the operational questions go unanswered. Why did this passenger see an $89 legroom seat and that one $59? What happens to attach rate if we bundle bag plus seat on leisure routes under four hours? Who set the current upgrade floors, when, and against what forecast? When the answers live in a codebase and a spreadsheet, every revenue review starts with an archaeology project.

The decisions inside
every offer you make.

Shopping context in, priced offer out: which ancillaries, for this passenger, on this flight, at this price, with the rules that produced it attached to the answer.

01

A worked example: the upgrade bid

Flight 441, FRA-JFK, a 787-9 with 30 business seats. At T-48 the cabin is 54 percent full, 14 J seats are unsold, and the forecast shows no late corporate demand. A passenger bids $340. The static floor is $400, so the bid sits rejected-pending until it expires and the seat flies empty at zero. In GoRules that is four decision-table rows: cabin load at T-48, time to departure, and status tier set the effective bid floor and say what happens to a bid below it. Cabins at 85 percent and above keep the $400 floor and decline outright, elite tiers keep their own $300, and cabins under 60 percent inside 48 hours drop to $340 and counter anything below. The bid clears at $340 and the released economy seat goes back into inventory.

02

Ancillaries by route, cabin, tier, and days to departure

The same tables decide the rest of the offer. Which bag, seat, and lounge products a passenger is eligible for, which bundle to surface, and what each one costs by route, cabin, fare class, status tier, channel, and days to departure. Model scores and willingness-to-pay estimates arrive as plain inputs, so a recommendation still has to clear the floors, the tier entitlements, and the interline rules before it becomes a real offer.

03

Offer rules without a PSS release

Revenue management and merchandising edit the decision tables directly, and natural-language rendering makes each row read the way the pricing memo does. Git-like versioning, approval workflows, and one-click rollback mean the head of revenue signs off before anything reaches a passenger, and any change reverts in one click if the forecast was wrong.

Keep the PSS.
Own the offer rules.

No migration: the PSS keeps inventory, tickets, and orders, and the RM system keeps forecasting and availability. GoRules owns the decisions between them.

01

Connect

Your booking flow, NDC offer API, upgrade-bid tool, or check-in upsell calls GoRules over REST, or embeds the MIT-licensed open-source ZEN Engine with SDKs for Node.js, Python, Java, Go, C#, and Rust. The payload carries the shopping context: route, cabin, equipment, load factor and days to departure from the RM feed, fare class, status tier, channel, and whatever is already in the cart.

02

Model the offer

Rebuild offer construction as a decision graph. Eligibility runs first, then the ancillary catalogue for this passenger and this flight, then the price for each item, then bundling and the guardrail policy that can only narrow the result. ZEN expressions handle the arithmetic, and typed TypeScript function nodes cover anything custom, such as blending a willingness-to-pay score with a floor.

03

Test on real traffic

Branch the policy and replay last month's shopping sessions and expired bids through both versions. Compare attach rate, take-up, and incremental revenue item by item, count how many rows the guardrail catches, and let revenue managers read the rules in natural language before sign-off.

04

Operate

Promote through dev, staging, and production with an approval recorded at each step. Every evaluation returns the offer plus the rules that produced it, ready for revenue reviews, pricing audits, and the order record. When a route softens, the change ships the same day instead of the next release train.

Built for production,
not proof of concept.

  • Sub-millisecond evaluation with the Rust-core ZEN engine, fast enough to price ancillaries inside a shopping request, a bid window, or a check-in upsell
  • Git-like version control on every offer policy: branches, commit history, approval workflows, and one-click rollback when a floor moves the wrong way
  • Self-host with Docker or Kubernetes so PNR, tier, and revenue data never leave your infrastructure, or run on GoRules Cloud
  • Full traceability: every offer links to the rules that fired, and every rule change records who changed what and when. SSO, RBAC, and SOC 2
  • No lock-in: the core engine is open source under MIT, and 70+ industry templates, including aviation starting points, give you a working base

Questions, answered.

What is an offer management system?

An offer management system is the layer that assembles what an airline sells at the moment a passenger shops: which flight products and ancillaries to show, in what bundle, to which customer, at what price. It sits above inventory and distribution rather than replacing them, and it is the "offer" half of IATA's Offers and Orders model, where every purchase eventually lands in a single order record instead of separate PNRs, tickets, and EMDs. Two separable jobs live inside it: the science that estimates demand and willingness to pay, and the decision layer that turns those signals plus your commercial policy into an offer you are willing to defend. GoRules is the decision layer, a rules engine where eligibility, pricing, bundling, and guardrails live in one versioned, auditable place.

Does GoRules replace our revenue management system or PSS?

No. Your RM system keeps forecasting demand and allocating inventory, and your PSS keeps reservations, ticketing, and servicing. GoRules decides the things that sit between them: whether this passenger is eligible for this ancillary, which bundle to construct, what the upgrade-bid floor is on this cabin at this point in the booking curve, and when to route an offer to review. Those systems call GoRules over REST wherever a decision is needed, so nothing has to migrate and no vendor roadmap has to move first.

How does an offer management system increase ancillary revenue?

Ancillary revenue reached roughly $157 billion worldwide in 2025, about 15.7 percent of total airline revenue, up from 9.1 percent in 2016. Most of that growth came from unbundling, not from smarter offers: the same seat, bag, and upgrade prices go to everyone, set weeks ago in a spreadsheet. Moving those rules into a decision layer lets you vary them where the money is, by route, cabin, fare class, status tier, channel, and days to departure, and then measure it. In the upgrade-bid example on this page, dropping the floor from $400 to $340 on business cabins under 60 percent full at T-48 turns bids that would have expired at zero into cleared revenue, without touching the floor on cabins that are already selling.

Can we run upgrade bidding and other dynamic-offer decisions through it?

Yes. Upgrade bidding is a good fit because the decision is pure policy: what the floor is for this cabin at this point in the booking curve, and whether a bid below it should be declined or countered. Cabin load at the bid window, time to departure, fare class, status tier, and the demand forecast are the inputs. Encode those as decision-table rows, and your bidding platform or NDC offer service calls the policy at each window. The same pattern covers seat and bag pricing, bundle construction, waitlist and upgrade priority, and disruption re-accommodation offers. Every outcome returns the rules that fired, so a revenue manager can explain any accept or decline months later.

Can we self-host so passenger data stays in our infrastructure?

Yes. Deploy GoRules with Docker or Kubernetes inside your own environment, so PNRs, tier data, fare data, and decision logs never leave your network. The high-performance Agent evaluates rules close to your booking flow with hot reloading, and SSO plus role-based access control govern who can view or change offer rules. GoRules Cloud is available if you prefer managed hosting.

The same engine,
next door.

One decision layer serves the whole institution - these use cases run on the same tables, versioning, and audit trail.

Promotion EngineBundles and discounts on the same tablesDynamic PricingPrice moves with guardrails attachedLoyalty EngineTiers, points, and member entitlements

Price every extra.
Explain every offer.

Model your upgrade-bid floors as a decision table this afternoon, replay last month's expired bids through the simulator, and see the incremental revenue before anything reaches a passenger.

Get started Book a demo