Pricing Engine — ML-based rate recommendation

Monday morning, 8:40. Daniel is running his usual rate-review routine in the pricing calendar. Most days are fine — then he stops at October 15. A Thursday, 24 days before arrival. The suggested rate: 132 EUR.

His gut number would be 118. Last year this Thursday sold at 114 EUR, and this year’s rate level is roughly 3-4% higher — 114 × 1.035 ≈ 118. A round, comfortable, defensible number. Against that, the 132 is +12%. “Isn’t that too aggressive?”

He has two options: accept or override. And either can be the wrong decision. If he blindly accepts a bad recommendation, he makes the system’s error his own. If he reflexively overrides a good one, he throws away exactly the edge he introduced the rate-recommendation system for.

This lesson is about that tension: what an ML-based (machine learning) rate recommendation is made of, how to read it, when to accept it, and when to override it. By the end of the lesson we take the 132-vs-118 case fully apart — and you will see Daniel’s decision too, along with the result.

The third step — from rules to a learning model

In pricing methodology we have climbed two steps so far:

• Lesson 35 — rule-based: IF-THEN logic (“if occupancy within 14 days is above 85% → BAR +15%”). Transparent and controllable — but rigid: hard thresholds (a drastic jump between 69% and 71%), segment blindness, and a rule set that goes stale if nobody tends it.
• Lesson 36 — elastic demand: the economic model of price elasticity. Already data-driven — it computes the revenue-maximising price point — but measuring elasticity is hard in practice: the variables blur together (event + campaign + compset movement at once), and sensitivity shifts over time.

ML-based rate recommendation is the third step. The decisive difference: the model does not apply a pre-written formula; it learns patterns from the hotel’s historical outcomes — from which signal constellations in the past were followed by what pickup and what realised rates.

This has two consequences, and both matter.

1. The model thinks in signal combinations, not isolated signals. The constellation “fast pickup AND an event in town AND the compset hasn’t priced it in yet” calls for a different rate than any of those signals alone. In a rule-based system, every combination would need its own rule — combinatorial explosion, exactly the “too many rules” trap you saw in lesson 35. In the elasticity model, the same thing shows up as confounding. The ML model, by contrast, learns precisely from the constellations — it also captures non-linear relationships (for example, that the event signal scales differently at high and at low OTB).

2. The response is continuous, not stepped. There is no 70% threshold below which nothing happens and above which +8% kicks in. Occupancy at 69% and at 71% produces nearly the same recommendation — the rate path is smooth.

And what do you give up in exchange? Direct transparency. With lesson 35’s rule you can see at a glance which rule fired. With an ML model, one row from the rule table is no longer an answer to “why this much?”. That is why explainability becomes one of this lesson’s central themes — because a recommendation you cannot justify is useless in practice: you can neither defend it to Adam nor decide for yourself whether to trust it.

What the model learns from — the input signals

ML jargon calls the model’s input signals features. A hotel pricing model’s typical feature set consists of exactly the signals you learned to read one by one in the earlier lessons of this course:

Two notes on the table.

First: an advanced rate-recommendation model can use further signals — weather forecasts (a moderate signal in a city hotel, a strong one in resort and beach business), search and denial data from the booking engine (how many people searched and did not book — lessons 39 and 42 showed why this is gold), air and rail traffic data. The principle is the same: any signal that tells about demand earlier than the booking itself is a valuable feature.

Second: most of these signals you can see yourself in the Peaqplus pricing calendar, next to the recommendation, row by row — the day’s forecast, occupancy and pickup direction, the events, the alerts triggered overnight, the competitor average (with expandable detail: which stay a competitor’s daily minimum rate came from, and what alternative offers it has per channel). This is no accident: the recommendation and the signals behind it live on one surface, so that verification is not a separate research project. Daniel’s routine is built on this — you will see it in a moment.

Reading the output — suggested rate, uncertainty, reasoning

The most visible part of the recommendation is the suggested BAR (Best Available Rate): one number for the given day, room type and rate category. But a mature rate recommender’s output is more than that, and as an RM you need to read all three layers.

1. The suggested rate. The price point the model considers closest to the revenue optimum — lesson 36’s revenue-maximisation logic, only now computed not from a single elasticity number but from the full signal set.

2. The uncertainty. In lesson 36 you met the concept of confidence: a mature system expresses its uncertainty next to the recommendation — as a confidence band (“132 EUR, range 126–140”) or as a strength indicator on the suggestion. Read it like this: a narrow band = the past held many similar constellations and they led to consistent outcomes — the recommendation is strong. A wide band = there is little analogue data, or the analogue days’ outcomes are scattered — the recommendation is weak, and your expert judgement carries more weight. Uncertainty is not the model’s flaw but its honesty: 100% confidence does not exist, and whatever presents itself as that deserves no trust.

3. The reasoning. The right question is never how much the model suggests, but why this much. And here comes the classic charge: “ML is a black box — nobody knows what happens inside.” The answer: the individual internal weights you indeed cannot see, but the recommendation can be decomposed into its main drivers — a neutral base rate and each signal’s contribution. “The compset moved −4%, but pickup is 83% faster than on similar days, and there is an event overlap” — that is no longer a black box; it is an argument you can judge. As an RM, demand this decomposition: either the system shows it, or — as Daniel does — you assemble it yourself in five minutes from the calendar’s signals. A recommendation without reasoning is not decision support; it is an oracle.

Dissecting the 132 — the worked example

Back to October 15. Let’s take the recommendation apart the way an explainable model’s decomposition would show it.

The situation (T-24, i.e. 24 days before arrival):

• Hotel Peaqplus City, 80 rooms. OTB: 46 rooms = 57.5%.
• The similar days’ (autumn Thursdays) average at the same lead time: 45% — the day is running +12.5 percentage points ahead.
• Pickup over the last 7 days: +11 rooms; the similar days’ average: +6 — 83% faster.
• Compset average: moved −4% downward over the last week.
• Event calendar: October 14–16, a three-day industry conference in town, medium-sized.

The decomposition — from the neutral base to the 132:

Note the tension between the signals: the compset pulls down, the pickup and the event pull up. A compset-following reflex (lesson 44) would cut the rate here. The model, however, has learned from the past that when your own pickup is accelerating AND there is an event overlap, following the compset’s move leaves revenue on the table — most likely the competitors have not priced the conference in yet, or they target a different guest base. This is the signal combination that neither lesson 35’s rule nor Daniel’s anchored reflex captures.

And where did Daniel’s 118 come from? Last year’s rate + an inflation adjustment. In other words, the gut number works from a single feature: last year’s rate. It does not see this year’s pickup surplus, it does not see the conference, it does not see the OTB lead. In lesson 44 you saw the ARI lesson: the anchored reflex systematically underprices in compression — not because the RM is bad, but because a reflex by definition repeats the past’s average, while the model reads the current constellation.

Daniel’s verification routine

Daniel does not accept the 132 blindly — but he does not override it by reflex either. He gives the check five minutes, and he always asks the same five questions:

1. Is the pickup real? He opens the day’s trend chart: is the +11 rooms not the distortion of a single group booking? (It is not — 9 separate bookings of 1-2 rooms.)
2. Is the compset signal real? Expanding the competitor average, he checks which stay each competitor’s minimum rate came from — is the −4% not dragged down by one outlier, long-stay promotional offer? (Two competitors actually moved; the rest stand still.)
3. Is the event real? Does the conference truly overlap the date, and how big is it? (Yes — the main day is precisely the 15th.)
4. What does the forecast say? Is the expected close consistent with an increase? (Above 90% — yes.)
5. What do the neighbouring days say? Lesson 48’s day-by-day view: the 132 must not stick out of the Wednesday–Friday band without reason, and if the Thursday is compressed, the LOS question must be asked too (lesson 42) — is a restriction needed, or is the rate enough? (The Wednesday stands at 118, the Friday at 125 — the Thursday peak is justified by the event; no restriction needed, the conference guest books 2-3 nights anyway.)

Every question returns a consistent answer. Daniel accepts the 132.

The result — in hindsight

What would have happened with the 118? At the 132 rate, the model expected ~28 more rooms of bookings over the remaining 24 days. The conference-heavy demand mix is relatively inelastic — E ≈ −0.6, by lesson 36’s logic: the 118 versus the 132 is a −10.6% price move, which would bring +6.4% more demand, i.e. ~30 rooms instead of 28.

The difference: +156 EUR (+4.4%) in the model’s favour — on a single day, a single room type, a single decision. The fact: the day closed at 74 rooms (92.5%), and the last three weeks’ bookings arrived at an average of 131 EUR — the model read the compression correctly. The +156 EUR is not much by itself. But across an 80-room hotel’s 365 rate decisions a year, this same few-per-cent edge is what the rate-recommendation system’s business case is made of.

Override discipline — when to overrule, and when not to

An override (overruling — manually changing the suggested rate) is not a sin. A suggestion is a suggestion, not a command — the RM is you, not the system. But an override has discipline, and this is perhaps the lesson’s most important practical message.

Override when you have information the model does not. This is lesson 51’s framework: the human beats the machine where the data has not yet arrived. Examples:

• You know the conference’s main hotel block is contracted at a competitor — and it was just cancelled. The model would see this in the pickup at the earliest, days later.
• A 20-room tentative group option sits on the date, and the decision is due this week.
• A renovation takes 8 rooms out — the true capacity differs from what the model sees.
• The sales team has just quoted a series business for exactly this period.

Do not override when your only argument is the gut number. “118 is what I’m comfortable with” — that is not information; it is habit. Lesson 44’s ARI lesson was merciless about this: reflex pricing produces a systematic, one-directional error — downward in compression. If the model and your reflex disagree, and the verification routine (the five questions above) finds no fault in the signals, then in all likelihood your reflex is the faulty party.

And the decisive element: log and evaluate. Every rate decision should record how it was born — in Peaqplus pricing, every saved rate stores whether the automation set it, whether you accepted the suggestion, overrode it, or set a purely manual rate. This is the raw material of the month-end evaluation: who won — you or the machine? Pull up the overridden days and compare their outcomes with the accepted days’:

• If your overrides are systematically better in a certain situation type (say, group-heavy periods) → the model is blind to something there; that is calibration feedback — report it.
• If they are systematically worse → your reflex is more expensive than you thought; keep that in front of you on the next similar day.

The learning is two-way: the model can learn from your overrides, and you from the model’s hit rate. In lesson 61 (A/B testing) we formalise this evaluation into an experiment, and in lesson 64 (Decisions and Revenue Track) we build the full system of decision tracking.

One last guardrail: lesson 35’s BAR floor and BAR ceiling principle lives on in the ML layer. The model may suggest anything — the 85 EUR floor (brand protection) and the 350 EUR ceiling remain hard limits that no recommendation can cross.

In one hand — the recommendation lives in the day’s context

Finally, the place. The ML recommendation does not live in a separate report or export but on the day-level pricing surface — in the DCAL grid (demand calendar: day class × category × LOS) we built in lessons 33-34, which in Peaqplus the Pricing Map handles. This is deliberate: you validate the rate suggestion in the day’s context (lesson 48), where one view holds the suggestion, the forecast, the occupancy, the competitor average and the neighbouring days — and the LOS toolkit is in your hand right there too (MLOS, CTA, CTD — lesson 42), because the answer to a compressed day is often rate and restriction together.

The daily routine is familiar from lesson 35; only the suggestion behind it got smarter: in the morning you review the outlier days, and the accepted rate goes live on every channel within a quarter of an hour through the channel manager. If the hotel enables automatic pricing as well, the system applies the suggested rates by itself — except for manually closed periods, where the wheel returns to you. The mature division of labour: automation in the quiet zone, RM attention on the outlier days — the machine scales what is not worth a human minute, and you put your time where judgement is the bottleneck.

The puzzle’s last two pieces: in the previous lesson (55, Smart Forecast Enhanced) we put demand forecasting in order — the forecast gives the demand picture, the rate recommender the price-side answer; the two are sides of the same coin. And the next lesson (57, RM and data quality) is about what sits beneath both: the model is only as good as the data it learns from. Behind the 132 recommendation stands the assumption that the pickup data is accurate, the event calendar maintained, the compset rate fresh. If that does not hold, even the best model is confidently wrong.

Key takeaways

• ML-based rate recommendation is the third step after rule-based (lesson 35) and the elasticity model (lesson 36): it learns from the joint pattern of many signals, calibrated on historical outcomes — you gain combination sensitivity and a continuous rate path, you give up direct transparency.
• The input signals (features) are familiar: OTB position, pickup speed, lead time, day type, event calendar, compset rates, similar days — the model’s strength is not in new signals but in reading their constellations.
• The output has three layers: suggested BAR + uncertainty (confidence) + reasoning. The answer to the “black box” charge is decomposition: the recommendation can be broken back into a neutral base and the main signals’ contributions — in the example, 112 + 13 + 9 + 8 − 6 − 4 = 132 EUR. As an RM, demand it.
• Override discipline: overruling is allowed when you have information the model lacks — the gut number alone is no argument, because the anchored reflex systematically underprices in compression (lesson 44). Every decision logged, evaluated monthly: who won, you or the machine?
• The recommendation lives on the day-level surface (the DCAL grid of lessons 33-34, handled in Peaqplus by the Pricing Map): you validate it there, in the day’s context, with the LOS restrictions in the same hand — automation on the quiet days, RM attention on the outliers, floor/ceiling protection (85/350 EUR) above everything.