Dynamic pricing — the elastic demand model

In lesson 35 we saw the rule-based approach: simple IF-THEN logic — “if occupancy is above 85%, raise by 15%”. It works, but it is a blunt tool: the thresholds are binary, and a rule never tells you exactly how much a price move is worth. The more mature approach builds on the economic concept of price elasticity: it computes how much demand changes for a given price change — and from that, where revenue peaks.

This is one of the most calculation-heavy lessons in the series. But if you understand it, you also understand the why behind the Peaqplus Pricing Engine’s rate suggestions — and you know when to accept them and when to push back. In lesson 56 at the expert level (Pricing Engine — ML-based rate recommendations) the concepts learned here return packaged into an ML model; this lesson is the theoretical base.

What is price elasticity?

Price elasticity of demand is the classic economics measure: by what percentage does demand change when the price changes by 1%?

E = (% demand change) / (% price change)

Example: for a given week the hotel raises its rate from 100 EUR to 110 EUR (+10%), and bookings fall from 70 to 63 (−10%):

E = −10% / +10% = −1.0

The negative sign is normal economic behaviour: price up, demand down. Revenue, meanwhile: 100 × 70 = 7,000 EUR → 110 × 63 = 6,930 EUR — practically unchanged (−1%). That is no accident: E = −1 is exactly the boundary where the price effect and the demand effect roughly cancel each other out.

The levels of price elasticity:

• |E| > 1 — elastic demand (e.g. −1.5): a 1% price increase causes more than 1% demand loss. A price increase loses revenue.
• |E| = 1 — unit elastic: the two effects cancel out; revenue is unchanged to a first approximation.
• |E| < 1 — inelastic demand (e.g. −0.5): a 1% price increase causes only a 0.5% demand loss. A price increase produces revenue.

Industry experience puts the aggregate price elasticity of hotel demand typically between −0.5 and −1.5 — but that average says little, because the spread across segments is far wider. As an order-of-magnitude illustration:

Segment	Typical price elasticity	What it means
Transient business	−0.3 … −0.5	Inelastic — the company pays, price is not the main concern
Transient leisure (OTA)	−1.0 … −1.5	Elastic — compares options; the OTA list exists exactly for that
Transient leisure (direct)	−0.6 … −1.0	Medium — brand attachment exists, but so does a price ceiling
Transient occasion (e.g. honeymoon)	−0.2 … −0.4	Strongly inelastic — a life event, an emotional decision
Corporate negotiated	~0	Fixed contracted rate — during the contract period the question does not even arise
Group leisure (tour operator)	−2.0 … −3.0	Extremely elastic — moves the group to another hotel over a few euros

The exact value differs by hotel, market and season — these are orders of magnitude, not constants.

The mathematics of revenue maximisation

Price elasticity translates directly into revenue impact:

Revenue = price × quantity

Revenue change (%) = (1 + price change) × (1 + demand change) − 1, where demand change = price change × E.

Hotel Peaqplus City’s transient leisure (OTA) segment, E = −1.2:

Price change	Demand change (× −1.2)	Revenue change
+10%	−12%	1.10 × 0.88 − 1 = −3.2%
+5%	−6%	1.05 × 0.94 − 1 = −1.3%
0%	0%	0%
−5%	+6%	0.95 × 1.06 − 1 = +0.7%
−10%	+12%	0.90 × 1.12 − 1 = +0.8%
−15%	+18%	0.85 × 1.18 − 1 = +0.3%

Two observations. In this segment a price increase loses revenue and a cautious cut produces it — the revenue maximum sits at about −8% (in the table, the −10% row comes closest, at +0.8%). And the returns fade fast: at −15% only +0.3% remains — a deeper discount sells more rooms but brings in less money.

Now the same for the transient business segment, E = −0.4:

Price change	Demand change (× −0.4)	Revenue change
+15%	−6%	1.15 × 0.94 − 1 = +8.1%
+10%	−4%	1.10 × 0.96 − 1 = +5.6%
+5%	−2%	1.05 × 0.98 − 1 = +2.9%
0%	0%	0%
−5%	+2%	0.95 × 1.02 − 1 = −3.1%

Here the world flips: a price increase produces revenue — within the range shown, every increase step adds to it. That is the nature of inelastic demand.

One important limit: the linear approximation (demand change = price change × E) only holds within a band of roughly ±10-15%. Beyond that, elasticity itself shifts — −0.4 is no longer true for a +40% increase — and that is partly why the BAR ceiling set in lesson 35 exists.

The “cheaper = more guests” trap

The classic naive logic: “If I lower the price, more people come, so I make more revenue.” That is only true when |E| > 1.

A trap example: the hotel cuts −10% in the transient business segment, because “cheaper = more bookings”. E = −0.4:

• Demand change: −10% × (−0.4) = +4%
• Revenue change: 0.90 × 1.04 − 1 = −6.4%

More bookings (+4%) — and noticeably less money (−6.4%). The front desk is busier, the till emptier: a classic “cheaper = less revenue” situation. And the damage does not stop there: in lesson 9 we saw that a sustained discount also pushes the brand’s price position down, and guests learn to wait for the deal.

When does it work “in reverse”?

Can a price increase cause higher demand? The textbook answer: no. In reality, three cases deserve a mention:

1. The Veblen effect

For some luxury products, the price is part of the product itself: a higher price makes it more exclusive. At the very top of the ultra-luxury hotel segment this can work — an 800 EUR ADR can be more attractive than a 600 EUR one, because it promises something different. In Hotel Peaqplus City’s 4-star, city-centre position this does not apply.

2. Price as a quality signal

If a hotel’s rate sits dramatically below the compset, the guest sees not a bargain but a risk: “at this price, something must be wrong with it”. Correcting an abnormally low price upward can therefore even improve demand — not because more expensive is more attractive, but because the price moved back into the credible band. In lesson 12 we saw exactly this with the Coldplay Saturday underpricing: a conspicuously cheap room on the Booking.com list looks suspicious, not attractive.

3. Combined with restrictions — the apparent exception

If an increase comes with an MLOS, room nights can grow even while the booking count falls — whoever wants to stay takes 2-3 nights; whoever does not, moves on. That is not demand growing but the metric shifting: the mix moved toward longer stays. (Restrictions logic: lesson 24; in more depth in lesson 42.)

Measuring price elasticity — the practical difficulty

The model is only as good as the E estimate. And that is the hard part.

Problem 1: there is no clean experiment

Elasticity could only be measured cleanly with a controlled experiment: two identical guest groups, one at 100 EUR, the other at 110. In the real market there are no two identical groups and no two identical weeks — the market moves constantly.

Problem 2: several variables move at once

You raised the price — but meanwhile an event landed in the calendar, marketing launched a campaign, and the compset raised too. Which one caused the demand change? The price effect blurs together with the other variables (confounding).

Problem 3: the average hides the segments

Hotel-level measurement yields a single average E — the difference between business (−0.4) and OTA leisure (−1.2) disappears. Yet decisions are made precisely at segment level.

Problem 4: E is not a permanent number

A segment’s sensitivity changes with season, market situation and the economic cycle. Last year’s E is only a starting point this year — the estimate needs continuous recalibration.

The Peaqplus Pricing Engine — the elastic demand layer

The Peaqplus Pricing Engine automates this model — handling the four problems above with statistical tools:

1. Segment-level E estimation

A segment-level price elasticity estimate is built from the hotel’s own historical pace and rate data. At Hotel Peaqplus City, for example: transient business −0.4; transient leisure (OTA) −1.2; transient leisure (direct) −0.8; transient occasion −0.3; group leisure −2.5. This is the hotel’s own elasticity portrait, not an industry average.

2. Revenue-maximum search

For every date, the module computes the revenue-maximising price point. The lesson-35 rule knows only this much: “if above 70%, +8%”. The model computes where the maximum actually sits in that day’s pace state.

3. Mix-combined impact

It combines the elasticities based on the day’s segment mix: the revenue maximum of a 60% leisure + 30% corporate + 10% group day sits elsewhere than that of a corporate Monday.

4. Confidence range

Every suggestion comes with confidence: “Suggested BAR 138 EUR ± 6 EUR, model confidence 78%.” There is no 100% certainty — a pricing decision is always made under uncertainty, and the system says so out loud.

5. Controlled trials

A new pricing logic can first be rolled out on a subset of dates, with the rest staying on the old logic — the incremental difference measures the model’s accuracy and continuously calibrates the estimate. (The methodology of A/B testing: expert level, lesson 61.)

In lesson 56 at the expert level (Pricing Engine — ML-based rate recommendations) we also look inside the ML stack.

The two approaches together

The rule-based approach (lesson 35) and the elastic demand model (this lesson) are not either-or. In a mature system there is a division of labour:

• The rules provide the frame — event minimums, floor/ceiling, structural day-of-week logic.
• The model fine-tunes in the free zone — it computes the revenue-maximising price point wherever no hard rule binds.

Three examples from Hotel Peaqplus City:

• An average Wednesday. No rule fires (medium pace, no event). From fresh pace data the model computes a revenue-maximising BAR of 122 EUR instead of the 118 EUR day-class base. Quiet, small fine-tuning — most days look like this.
• The Coldplay Saturday (Nov 18). Rule #5 prescribes +25%: 125 → 156 EUR + MLOS 2. From demand elasticity the model computes a maximum around 148 EUR (+18%): event demand is strong, but most of it is price-sensitive OTA leisure. The same number Daniel dialled in from experience in lesson 35 — and the same one you already saw as the Pricing Engine’s suggestion in lesson 24. The model calibrates the crude rule.
• A Sunday with a big conference starting Monday. Rule #8 would prescribe −15% (structural Sunday weakness). But the model sees the Sunday corporate arrivals in the pace — inelastic demand — and computes +5%. The two layers conflict, and this is where the RM decides: the hotel’s own pace data shows this Sunday is not an average Sunday. He overrides the rule for that day.

The pattern is the same as in lesson 35: the system suggests, the RM decides — but the better the model, the more rarely you need to intervene by hand.

Key takeaways

• Price elasticity: E = the % change in demand divided by the % change in price. The negative sign is normal behaviour; the absolute value tells you whether demand is elastic.
• It differs dramatically by segment: business is inelastic (about −0.3 … −0.5), OTA leisure is elastic (−1.0 … −1.5), tour operators are extremely elastic (below −2) — a hotel-level average hides this.
• Below |E| = 1 a price increase produces and a price cut burns revenue — “cheaper = more revenue” is only true when |E| > 1. Compute it; don’t decide on gut feel.
• The revenue-impact formula: (1 + price%) × (1 + price% × E) − 1 — and the linear approximation only holds within a ±10-15% price band.
• Measuring E is hard (no clean experiment, confounding, segment averaging, drift over time) — the Peaqplus Pricing Engine handles it with segment-level estimation, confidence ranges and controlled trials, while the rule layer provides the frame around it.