Dynamic pricing — the rule-based approach

In lessons 33-34 we built the DCAL grid — the rate matrix that prices by arrival day (and its day-class), room category and length of stay (LOS); in Peaqplus, the Pricing Map module handles that layer. But the grid’s values cannot stand still: pace, pickup trend and the compset move every day — and the rate cells have to move with them.

Lessons 35-36 cover the two approaches to dynamic pricing:

• 35 (this lesson): the rule-based approach — IF-THEN logic; human-readable, easy to roll out.
• 36 (next): the elastic demand model — economics-based, built on price-elasticity calculation.

The two represent different maturity levels. A hotel typically starts with the rule-based approach and moves toward model-based pricing as it matures — we cover ML-based rate recommendations in lesson 56 at the expert level (Pricing Engine — ML-based rate recommendations).

What rule-based dynamic pricing means

Rule-based pricing is a set of simple IF-THEN conditions that adjust the BAR and its linked rate cells daily. A classic rule:

IF occupancy for a date within 14 days is > 70%, THEN BAR +8%.

A single logical condition — behind it, a basic economic instinct: when pace is fast, raise; when it is slow, cut.

This is fundamentally different from a static, hand-maintained rate (the “single rate” world): there, the price only changes when the RM touches it. In a rule-based system the price moves on its own as soon as the conditions are met. It is the bridge between manual pricing and model-based pricing.

A classic rule set

A realistic 10-rule set for Hotel Peaqplus City:

Ten rules. Each one is simple on its own — together they add up to a complete pricing strategy: pace triggers (#1-4), event handling (#5), compset following (#6-7), structural day-of-week logic (#8), season peak (#9) and the guardrail (#10).

Two operating details:

• There is a hierarchy between the rules. Rule 5 (event) overrides rule 8 (Sunday weakness): if a concert falls on a Sunday, the event rule runs, not the discount. And rule #10 (floor/ceiling) overrides everything.
• The percentages do not stack. Between #1 and #2, the stricter threshold always wins: at 87% occupancy, +15% runs — not +23%.

The advantages of the rule-based approach

1. Transparency

A human understands why the price changed. When Adam asks, “Why did next Friday’s BAR jump from 132 to 152?”, Daniel answers in one line: “Rule #1 fired — that Friday is within 14 days and sits above 85%.” (132 × 1.15 ≈ 152.)

2. Control

A rule can be switched on and off. If the hotel doesn’t want to run last-minute promos on weak pace — because it worries about its price position — it simply switches off rule #4.

3. Teaching value

Building the rules teaches the team the demand behaviour of their own hotel. Formulating and justifying each rule is a business decision: where our thresholds sit, what an event is worth, what we do about Sundays.

4. A cheap entry point

The rule-based approach can even be implemented by hand (Excel + a daily PMS export). It needs no ML model — it does need a disciplined daily routine.

The dangers of the rule-based approach

Danger 1: too many rules

A 30-50-rule system is opaque. The RM can no longer find the cause of a price move because several rules conflict — and the hierarchy becomes unmaintainable.

Danger 2: hard thresholds

The condition “occupancy > 70%” is binary. At 69%, nothing happens; at 71%, the full +8% BAR increase lands. A 2 pp occupancy move triggers a drastic price jump — while demand moves continuously, not in steps. ML-based pricing (expert level, lesson 56) smooths this out into a continuous, non-stepped price path.

Danger 3: data staleness

The rules are built for a given market situation. If the RM hasn’t touched them in two years, the market has moved in the meantime — and the system quietly manufactures bad decisions without anyone noticing. That is why regular review is a mandatory element (see below).

Danger 4: segment blindness

The rule set works on total occupancy, not at segment level. If the corporate segment slows but leisure pickup happens to compensate, total occupancy builds normally — as if everything were fine — and not a single rule reacts. Only a segment-level rule or analysis would catch the corporate slowdown. The ML model (expert level, lesson 56) works at segment level — that is one of the main differences.

The principles of rule building

A mature rule-based system stands on five principles:

1. Simplicity

A maximum of 10-15 rules. If you need more, that is a signal: either rethink the hierarchy, or move on to model-based pricing.

2. Hierarchy

Every rule has a priority. The event rule sits above the standard pace rules; the floor/ceiling above everything.

3. Testing

A new rule’s impact is measurable: run it for a few weeks and compare the pickup result against expectation (forecast vs. actual — lesson 26).

4. Review

The full set gets reviewed quarterly: what fired, with what result — and what never fired at all? A rule is not forever.

5. Floor and ceiling

Always set a lower and an upper limit. At Hotel Peaqplus City: BAR floor 85 EUR (brand protection — below this the price damages positioning), BAR ceiling 350 EUR (above this, guest trust and price acceptance suffer).

The rule-based approach in a day

How does this system work day to day at Hotel Peaqplus City?

Overnight — automatic rule run

The Peaqplus Pricing Engine module re-runs the 10 rules overnight for the next 90 days. For every date it: (1) checks the 14- and 30-day occupancy and pace levels, (2) checks the event calendar, (3) compares the compset average’s movement, (4) applies the day-of-week and season rules. The result: a suggested BAR state for each of the 90 days.

8:30 — Daniel reviews the suggestions

As part of the morning routine, Daniel spends 5-10 minutes on rate revisions:

• ~80% of days are unchanged — the rules say there is nothing to do.
• 5-10 days have a suggested increase.
• 3-5 days have a suggested decrease.

If he agrees, he accepts with one click. If not, he decides in context. For example: for Nov 18 (the Coldplay Saturday we discovered from a compset signal in lesson 12), rule #5 suggests +25% on the 125 EUR day-class base — 156 EUR, with MLOS 2. But Daniel remembers the pickup of previous arena concerts: around +25% the pickup stalled, while around +18% the house filled. He sets the rate to 148 EUR — MLOS 2 stays, because most concert guests book Friday-Saturday. And he sees something the rule doesn’t: the rule never touched Nov 17, the night before the concert — he raises it by hand from 125 to 138.

The rule is a suggestion, not a decision. The RM is Daniel, not the system.

8:50 — sending to the channel manager

The approved rates go out through the channel manager (D-Edge — lesson 15) and are live on every channel within 15 minutes.

The whole daily process: about 20 minutes. By hand — in Excel, repricing channel by channel — the same 90-day review would typically be 2-3 hours of daily work.

The Peaqplus Pricing Engine — the rule-based module

The Peaqplus Pricing Engine fully supports the rule-based approach:

• Visual rule editor — the IF-THEN rules are built on a graphical surface, not at code level.
• Hierarchy management — priority levels and conflict watching: when two rules collide on the same day, you see which one won and why.
• Measurable rollout — a new rule can first run on a designated date range, and its impact (pickup, ADR) can be compared against the no-rule expectation.
• A learning layer — rule activations and the pace results measured after them are recorded, and over time the system suggests refinements (e.g. “the 70% threshold would work better at 75% for this hotel”).
• Floor/ceiling protection — if any rule would push the price outside the designated limits, an automatic override steps in.

Rule-based pricing is the Pricing Engine’s first level. Lesson 36 brings the next layer — the elastic demand model — and lesson 56 at the expert level covers ML-based rate recommendations.

When is it time to move on?

A well-run rule-based system can work for years. But there are signs that it is time to step forward:

• Too many rules: beyond 15+ rules, conflict management becomes time-intensive — a model packs into a single logic what the rules describe in fragments.
• Segment-level need: if occupancy is stable at the average level but moves dramatically at segment level, the rule-based system stays blind.
• Event calibration: rule #5’s uniform +25% is a crude approximation — a real event peak deserves a date-specific, dynamic price path.
• Compset complexity: the linear following of rules #6-7 is simple, but real compset dynamics are not linear.

The first step forward is not technology but economics: you need to understand how demand responds to price. That is exactly the subject of lesson 36.

Key takeaways

• Rule-based dynamic pricing moves the BAR daily with IF-THEN logic — simple, transparent, controllable.
• A mature rule set is 10-15 rules, with hierarchical priority and floor/ceiling protection (Hotel Peaqplus City: 85 / 350 EUR).
• The four main dangers: too many rules, hard thresholds, data staleness, segment blindness — the last two quietly erode results.
• The daily routine is ~20 minutes: an overnight automatic run + a morning RM review + sending to the channel manager. A rule is a suggestion, not a decision — the context knowledge belongs to the RM.
• The Peaqplus Pricing Engine adds a visual rule editor, hierarchy management, measurable rollout and a learning layer to rule-based pricing.