Bid price vs leg-based pricing in airline revenue management

Two airlines, same plane, same route, very different revenue. The difference is almost never the fare table. It's whether the revenue management system thinks in legs or in origin–destinations, and how it uses bid prices to decide who gets the seat.

Leg-based pricing — the old default

A leg-based system treats every flight segment as its own inventory pool. SFO–LAX has its own buckets. LAX–JFK has its own buckets. A passenger flying SFO–LAX–JFK is two independent decisions, made by two independent engines.

That works when most passengers fly point-to-point. It falls apart the moment you build a hub-and-spoke network where 40-60% of passengers connect — because the leg engine can't see that the seat it's selling cheaply on SFO–LAX is the seat a high-yield SFO–JFK passenger needed.

O&D (origin–destination) pricing

An O&D engine prices the itinerary, not the leg. It knows that selling a €120 SFO–LAX seat blocks a €580 SFO–LAX–JFK booking that would have used the same SFO–LAX seat plus an otherwise-empty LAX–JFK seat. The trade-off is explicit: take the €120 now or hold the seat for the higher-value connection.

The mechanism that makes this trade-off is the bid price.

What a bid price actually is

A bid price is the minimum acceptable fare for a seat on a given leg at a given moment. It's the marginal opportunity cost of selling that seat — not its cost, not its average price, the value of what you'd give up by selling it.

How a booking decision actually runs

1. Customer requests SFO–LAX–JFK at fare €580. Fare allocated to legs (commonly proportional to leg distance or via the airline's fare-mix rules): say €230 SFO–LAX, €350 LAX–JFK.
2. System checks: is €230 ≥ SFO–LAX bid price (€420)? No.
3. Reject. Even though the total fare is high, the leg allocation doesn't clear the bid price on the constrained leg. The seat is held for an expected higher-value itinerary.

Run the same logic across the network thousands of times a day and you get the 4–6% RASK uplift O&D systems are typically credited with vs leg-based.

Where bid-price systems fail

• Bad demand forecast. Bid price is forecast × marginal-value math. Garbage in, expensive seats unsold.
• Disconnect from sales channels. If the GDS or NDC layer is still showing old availability, the engine's bid prices don't translate into closed buckets.
• Stale fare-allocation tables. If the engine attributes €230 of a €580 fare to the wrong leg, it accepts loss-making bookings and rejects profitable ones.
• Group/contract overrides. One large group booked outside the engine can break the bid-price model for an entire week.

Bid prices vs nested booking limits

Older O&D systems used virtual nesting — every itinerary mapped to a virtual bucket with its own booking limit. It worked but was hard to update.

Bid prices replaced virtual nesting in most modern stacks because a single number per leg (the bid price) is far cheaper to refresh in real time than maintaining hundreds of virtual buckets. The outputs are similar; the operational cost is very different.

What "good" looks like

• Bid prices refresh hourly or faster on the horizon-to-departure window, not just nightly.
• Forecast accuracy > 85% at 21-day-out — below that, leg-based often beats O&D because the network optimisation amplifies forecast error.
• Distribution path can carry the answer. If your NDC offer engine doesn't honour the bid-price reject, the model is decorative.

For the metric layer this all ladders up to, see load factor vs yield and the broader yield management overview.