airline-revenue-management

How it is built

Architecture overview

An airline sells the same seat at many prices, and the seat is worthless once the door closes. Revenue management (RM) decides, for every future flight, how many seats each price class may sell, and keeps changing that answer as bookings arrive. The airline has already set the fares and the schedule; RM only controls availability: which classes are open or closed in the reservation system at this moment. A third-generation RM system, as Belobaba's lecture describes it, keeps a history of bookings and no-shows, forecasts demand and no-show rates per flight and class, computes booking limits and overbooking levels, and lets an analyst review them (lecture, slides 9-10).

The idea that makes it work is that a booking is accepted only if its fare beats the value of the seat it uses. For one flight that value comes from a forecast of what late high-fare demand will pay. For a connecting itinerary it is the value of the seats on all its legs, which is why network control exists. Most of the system is offline: forecasting and optimising run in batches, and the live path only looks up a limit or a threshold.

Method names (EMSR-b, bid price, virtual nesting) come from papers and lecture material; commercial systems add proprietary forecasting that is not published, and quoted gains are simulation or lecture figures, so they are "order of". This page covers seat control, not pricing; see Dynamic pricing for that.

Parts:

• Booking history store — bookings, cancellations, no-shows and denied boardings per flight, class and checkpoint — Money representation
• Demand unconstraining — turns observed sales, cut off by closed classes, into estimates of true demand — censored-demand-estimation (no page yet), Robust statistics
• Forecaster — demand mean and spread per flight, class and days to departure, plus no-show rate — Time-series forecasting, arima (no page yet), Linear and logistic regression, Evaluation metrics
• Overbooking model — how many bookings above capacity to accept — overbooking-optimization (no page yet), Monte Carlo integration
• Leg optimiser — nested protection levels and booking limits for one flight — revenue-management-emsr (no page yet)
• Network optimiser — seat values or bid prices for itineraries over many flights — LU and Cholesky factorization, Sparse matrices (CSR), largest-remainder-rounding (no page yet)
• Control publisher — writes limits and thresholds to the inventory system so every channel sees them — Fencing tokens
• Batch runner and analyst tools — scheduled runs, restart, review of exceptions — batch-checkpoint-restart (no page yet), Exponential backoff with jitter, Leases

 reservation / inventory system  <------ booking limits, bid prices ------+
   (bookings, cancels, no-shows)                                          |
        |  snapshot at checkpoints                                        |
        v                                                                 |
 +---------------+   +----------------+   +-------------+   +---------------------+
 | booking       |-->| unconstrain    |-->| forecaster  |-->| overbooking model   |
 | history store |   | censored sales |   | demand,     |   +---------------------+
 +---------------+   +----------------+   | no-show     |   +---------------------+
        ^                                 +------+------+-->| leg optimiser       |
        |                                        |          | (EMSR-b)            |
        |                                        |          +----------+----------+
        |                                        |          +----------v----------+
        |                                        +--------->| network optimiser   |
        |                                                   | (LP, bid price)     |
        |                                                   +----------+----------+
   analyst review  <--- exceptions, forecast vs actual ---------------+
        |                                                   control publisher ---->+
        +--- override, special-event forecast ------------->

The forecast feeds three optimisers that answer different questions: how many bookings in total, how to split one flight among classes, and how to split a network among itineraries.

How the parts fit together

Booking history store and unconstraining

The store holds, per flight departure, the bookings by class at fixed checkpoints before departure (data collection points, DCPs), plus the no-show history. The key fact is in the data: when the airline closes a class, no further sales in that class are recorded, so observed sales are a censored view of demand. A paper on this problem puts it as "no sales are recorded after a product has been sold out", and warns that treating censored sales as true demand underestimates demand, which feeds a spiral down: lower forecast, tighter limit, lower recorded sales (Nikseresht and Ziarati 2017, introduction).

Unconstraining methods estimate what demand would have been. The same paper names projection detruncation and expectation maximisation as the methods in common practice and proposes a multinomial-logit alternative. In a PODS simulation study, Skwarek found that skipping detruncation or using simple pickup detruncation gave the worst revenue, scaling the booking curve beat not scaling it, and projection detruncation did at least as well as unscaled booking-curve detruncation (1996 thesis abstract). Robust statistics keeps one odd day out of the history.

Forecaster

The forecast has to give each class a demand distribution, because the optimisers use a mean and a standard deviation, not a point. Skwarek's PODS study found pickup and regression forecasters not clearly ranked, depending on the detruncation used, and an "efficient" forecaster usually worse than pickup.

The general toolbox is on the neighbouring pages: Exponential smoothing for level and seasonality, STL decomposition for weekly and annual shape, and Time-series cross-validation for honest backtests. Demand per origin-destination-fare cell is small and often zero, which is the intermittent-demand case (croston-method, no page yet). Accuracy pays: Nikseresht and Ziarati report an estimate that 20 % better forecast accuracy gives about 1 % more revenue, and a study by Weatherford finding that a negative forecast bias can cost up to 3 % of potential profit.

Contract with the optimisers: per class, a demand mean and standard deviation to departure, plus a no-show rate. Linear and logistic regression can fit no-show rates; Kalman filter tracks a drifting level.

Leg optimiser: Littlewood and EMSR-b

For two classes, Littlewood's rule (1972) says to protect seats for the high class as long as its fare times the chance that demand exceeds the protected count beats the low fare. Belobaba's expected marginal seat revenue (EMSR) extended this to many classes (Talluri and van Ryzin 1998, related literature). In the lecture's form, with R the average fare and P the probability that demand exceeds the number of seats offered, class 1 gets the largest protection level θ with R1 · P(X1 > θ) > R2.

EMSR-b handles many nested classes by combining the demand of all higher classes at each boundary: the combined mean and variance are sums (classes are independent), and the fare is the demand-weighted average fare. The booking limit of the next class down is then capacity minus the joint protection (lecture, slides 18-22). The lecture's worked example has class Y with mean demand 10 (standard deviation 3), fare $1,000, against $700 for the next class: P(X > 8) is 0.747 and P(X > 9) is 0.63, so 8 seats are protected for Y because 0.70 lies between them.

Assumptions (lecture, slide 18): each class's demand is independent and random, the lowest class books first, and limits are computed once. A game-theory paper adds that customers may act strategically or move between classes, which makes demands dependent; re-optimising at checkpoints (lecture, slide 24) is how the static model is used in practice. Belobaba's 1987 thesis and 1989 paper describe the model's first test at Western Airlines: flights with EMSR limits carried more passengers at lower yields and earned more total revenue than manually managed ones.

Overbooking model

Passengers cancel or do not show, so selling exactly to capacity leaves empty seats. The lecture's cost-based model picks the authorised booking level that minimises expected denied-boarding cost plus expected spoilage cost: total cost is $DB · E[DB] + $SP · E[SP], computed over a range of levels from the show-up distribution (slides 12-14). The lecture quotes US domestic no-show rates of 15-20 % of final bookings, falling to 10-15 % on average with fare penalties, and says effective overbooking can bring as much revenue as fare-class allocation; treat these as order-of figures from slides. Rothstein (1971) published an early overbooking model (named in Talluri and van Ryzin). The show-up distribution can be simulated with Monte Carlo integration.

Network optimiser

A connecting passenger on A-B-C uses seats on two flights, and accepting a cheap local booking on one leg can block a better connecting one. Network (origin-destination, O-D) control values the whole itinerary. The lecture reports that leg-based class control with overbooking can add 4-6 % revenue, and O-D control a further 1-2 %, rising with load factor (slides 26 and 38). Three mechanisms recur:

• Bid price control. Each leg gets a threshold; an itinerary is sold only if its fare exceeds the sum of the thresholds of its legs. Talluri and van Ryzin (1998) show this is not optimal in general but is asymptotically optimal for large capacities if the right prices are used. The lecture's example: legs A-B, B-C, C-D with bid prices $34, $201, $169 give A-C a bid price of $235, so a $231 Q fare is refused and a $262 B fare is sold (slide 34).
• Virtual nesting with displacement adjustment (DAVN). Subtract the down-line displacement cost from an itinerary fare to get its value on a leg, and map fare-itinerary pairs into ten virtual value classes per leg (lecture example, slide 31). Existing leg tools then control the virtual buckets.
• Dynamic programming is the exact formulation, which Talluri and van Ryzin analyse; bid prices and nesting approximate its value function (§5).

How to compute the bid prices: the deterministic linear program (DLP) maximises fare times seats over all itineraries, with seats per itinerary at most mean demand and seats per leg at most capacity; the dual prices of the leg constraints are the bid prices (lecture, slide 36; Talluri and van Ryzin §5.1). It needs an LP solver (Simplex method or Interior-point method) over a sparse matrix (Sparse matrices (CSR)), with linear solves by LU and Cholesky factorization. Two weaknesses are documented: it uses mean demand only, so duals are zero on any leg whose mean demand is below capacity, and degenerate constraints give several equally optimal dual vectors (duals can then jump between runs). In Williamson's simulations (as reported by Talluri and van Ryzin), DLP bid prices with frequent re-optimisation beat the probabilistic nonlinear program and leg-based EMSR. A third route, prorated EMSR, splits each itinerary fare across its legs and runs leg EMSR to get bid prices; the paper shows iterating it has little theoretical justification and can converge to poor prices. The proration should sum exactly to the fare, so work in integer minor units (Money representation) with largest-remainder-rounding (no page yet).

Which works best depends on the study. Hung's PODS thesis found DAVN best, heuristic bid price close behind, and network bid price worst owing to a "small network effect", and that frequent re-optimisation could reduce DAVN's performance (abstract). Lecture slide 35 says simulated gains of the methods are "quite similar", with data and forecast accuracy mattering more.

Control publisher

Results leave RM as booking limits per class and virtual bucket, or as bid prices per leg, written into the inventory system. A fare is filed with a booking code (RBD), and whether it can be sold depends on that class being open on that flight. Travelport's pricing documentation describes ATPCO Table 999 and Record 6 conditions that make a fare depend on a second class also being available, so one wrong closed class makes a fare unpriceable. Publish complete limit sets per flight, not partial updates. A resend after a timeout must not double-apply: key each push (Idempotency keys), and if two runs can overlap, reject the stale one with a monotonic number (Fencing tokens).

Batch runner and analyst tools

The nightly and checkpoint runs are large, restartable jobs: split by flight, record progress, and re-run only what failed (batch-checkpoint-restart, no page yet; the log of finished units is a Write-ahead log). Triggers are time-based (cron-scheduling, no page yet), and a single owner of each run is enforced with a Lease. Retries to the inventory system use Exponential backoff with jitter. Analysts compare forecast with actual using Evaluation metrics; the lecture says human intervention matters for demand surges (slide 24).

Data and control flow

Checkpoint run for one departure:

1. At a checkpoint, snapshot bookings, cancellations and the current limits per class.
2. Unconstrain the history of classes that were closed; update the forecast for each class: mean, standard deviation, no-show rate.
3. Compute the overbooking level from the no-show distribution and the denied-boarding and spoilage costs.
4. Compute leg limits: protection levels and booking limits by EMSR-b, and for network flights the DLP duals or the virtual-bucket mapping.
5. Flag large jumps against the old limits for an analyst.
6. Push the full limit set to the inventory system with an idempotency key; confirm availability changed.

One booking request:

1. A channel asks for availability on a flight; the inventory system returns the classes that are open.
2. The customer chooses; for a connection, the system compares the fare with the sum of leg bid prices, or looks up the virtual bucket of the itinerary.
3. If open, the booking is made and the remaining seats and class counts fall; no optimiser runs.
4. The booking and any later cancellation or no-show land in the history store.

Scaling

1. Number of forecasts. Flights × classes × checkpoints × markets. PROS says its platform runs "more than 400 million prices and 1.7 billion forecasts every day" (vendor claim, all products and customers, not one airline). Levers: parallelism by flight, aggregate sparse cells up to the leg.
2. Network LP size. One row per leg, one column per itinerary-fare combination; the matrix is sparse, but a hub carrier has many connecting itineraries. Levers: sparse solve, warm start, virtual nesting (which reuses leg tools).
3. Re-optimisation frequency. More checkpoints follow demand better; Talluri and van Ryzin note that approximations are re-solved frequently, while Hung found frequent re-optimisation could reduce DAVN performance in simulation. Levers: re-solve on triggers.
4. Time budget. A run must finish before the next checkpoint. Levers: order by departure date, restart only failed flights.

Failure modes

Real implementations

Neighbours: Airline reservation system holds the inventory and availability the RM publishes into; Dynamic pricing, Hotel booking platform and Car rental reservation and fleet platform are the same perishable-capacity problem in other industries.

Sources

• P. Belobaba, Air travel demand and airline seat inventory management, MIT PhD thesis, 1987. record
• P. Belobaba, Application of a Probabilistic Decision Model to Airline Seat Inventory Control, Operations Research 37(2), 1989. record
• P. Belobaba, Airline Revenue Management: Flight Leg and Network Optimization, MIT 1.201 lecture 17, 2008. slides
• K. Talluri and G. van Ryzin, An Analysis of Bid-Price Controls for Network Revenue Management, Management Science 44(11), 1998. record
• D. Skwarek, Competitive impacts of yield management system components: forecasting and sell-up models, MIT, 1996. record
• L. A. Y. Hung, Investigation of competitive impacts of origin-destination control using PODS, MIT FTL report R98-3, 1998. record
• A. Nikseresht and K. Ziarati, Estimating True Demand in Airline's Revenue Management Systems using Observed Sales, IJACSA 8(7), 2017. paper
• M. Li, T. Oum and C. Anderson, An Airline Seat Allocation Game. paper
• Travelport, Booking Class and Cabin (RBD, Record 6). help page
• RMOL: repository, project page
• Vendors: PROS, Amadeus Altéa Inventory, Sabre Revenue Optimizer