# Dynamic offer pricing What changes when a travel offer is built for each request instead of looked up, how continuous pricing affects display and caching, and the honest trade-offs. A price that is looked up and a price that is calculated look identical on a screen. Everything else about them is different: how long they last, what they depend on, whether they can be compared, and what happens when the traveller takes ten minutes to make up their mind. Dynamic offer pricing means an offer is built for each request rather than looked up from a published table. The price reflects the itinerary, the timing, and the context of the request at the moment it is made. That makes offers more relevant, and also shorter lived and harder to compare. ## Looked up, or constructed The traditional model is a filing. Prices and rules are published ahead of time, distributed, and read by everyone downstream. The price for a given route, cabin, and date band exists before anyone asks for it, and it stays put until the next refresh. The constructed model inverts that. Nothing exists until the request arrives. A system takes the itinerary, the passenger context, the channel, and current conditions, then returns an offer that was assembled for that request and no other. | What differs | Filed and looked up | Constructed per request | | --- | --- | --- | | Where the price comes from | A filed table, refreshed on a schedule | A calculation run at request time | | What it accounts for | Route, cabin, booking class, date bands | The specific itinerary, timing, and context | | Number of distinct prices | A fixed grid | Effectively continuous | | How long it holds | Until the next refresh | Seconds to minutes | | Comparing two sellers | Straightforward | Only meaningful at the same instant | | Caching | Safe and worthwhile | Risky beyond a short window | | Reconstructing a past price | Reproducible from the filing | Only from what you recorded | ## Why the industry is moving this way Three pressures push in the same direction, and none of them is a technology argument. The first is granularity. A filed grid has a fixed number of rungs, and revenue management has wanted more rungs than the grid allows for a long time. Continuous pricing is what you get when the grid is removed entirely and the price becomes a function rather than a lookup. The second is combinatorial. [Unbundling](/glossary/unbundling) created so many permutations of fare, brand, and extra that publishing every combination in advance stopped being sensible. It is easier to compute the answer for the case in front of you than to enumerate every case in advance. The third is retailing language. Airlines increasingly describe themselves as retailers rather than as transport providers, and retailers construct offers. Standards such as NDC were designed around a request producing an offer, which makes the constructed model the natural shape rather than an awkward one. [Diagram: A traveller who already holds a confirmed booking is shown only the offers that suit that itinerary, adds them to a single cart, pays once, and the booking then reflects the purchase without anyone at the agency handling it.] The offer exists because a request was made. Everything downstream inherits its validity window. ## What it changes for an intermediary If you display offers you did not construct, dynamic pricing moves work onto your side of the boundary. The offer arrives with a shelf life, and a shelf life is a user interface problem before it is an engineering one. **Caution:** Caching a constructed offer is not the same as caching a fare table. A stale table shows a slightly wrong price. A stale constructed offer shows a price that never existed for this traveller, and the failure surfaces at payment, which is the most expensive place for it to surface. 1. **Treat expiry as content, not as an error state** If the offer has a validity window, the traveller should be able to see it. An offer that quietly stops being real is worse than one that visibly counts down. 2. **Re-price immediately before taking money** The check that matters is the last one. Anything earlier is an estimate, however recent it feels. 3. **Record the offer you actually showed** A constructed price cannot be reconstructed later from the filing, because there is no filing. If you did not store what you displayed, you cannot answer a dispute about it. 4. **Fail forward, not silently** When the price has moved, show the new one and say so. Silently substituting a different number is the behaviour that destroys trust in a post-booking cart. ## The honest trade-offs Constructed offers are better for relevance and worse for almost everything that depends on stability. Comparison suffers first. A traveller who opens two tabs is not comparing two prices for one product, they are comparing two snapshots taken at different instants. Neither seller is being dishonest and the traveller still ends up confused. Explaining a price gets harder. When a figure comes from a filing, you can point at the filing. When it comes from a calculation, the honest answer to why it changed is that the inputs changed, which is true and deeply unsatisfying. Testing gets harder too. A grid can be enumerated. A function has to be sampled, and the interesting behaviour tends to live in the parts nobody sampled. **Insight:** The trade is relevance for stability. That is worth making for a post-booking extra, where a well targeted offer at the right moment is worth far more than a price a traveller could have verified last Tuesday. It is a harder trade for a headline fare, where comparison is the whole game. ## What it does not change The traveller still has to understand what they are buying, still has to be shown a total that includes everything, and still has to end up with a booking that reflects the purchase. Dynamic offer pricing changes where the number comes from. It does not lower the bar for presenting it clearly, and if anything it raises it, because the traveller has less ability to check the number for themselves. ## Talk to us about displaying offers with a shelf life Short lived offers put real weight on the display layer. If that is the problem in front of you, it is worth a conversation. [Talk to us](mailto:hello@departcart.com) ## Frequently asked questions ### What is dynamic offer pricing? It is pricing where an offer is constructed at the moment it is requested, using the specific itinerary and context, rather than read from a table that was filed in advance and refreshed on a schedule. ### How is it different from dynamic pricing generally? Dynamic pricing describes a price that moves. Dynamic offer pricing describes where the price comes from: a calculation run per request, producing an offer that exists for that request and then expires. ### How long does a dynamically priced offer stay valid? Long enough to decide, not long enough to shop around. Validity is set by whoever built the offer and is usually measured in minutes, which is why an expiry has to be part of how the offer is displayed. ### Can you cache a dynamically priced offer? Only inside its stated validity, and only for the request it was built for. Anything longer risks showing a price that no longer exists, which becomes a failure at payment rather than a failure in the display. ### Does dynamic offer pricing make comparison impossible? Not impossible, but much harder. Two constructed offers are comparable only if they were built at close to the same moment for close to the same context, which no comparison screen can promise.