Set up your first pricing rule

Your first pricing rule does not have to be sophisticated. It has to be yours, readable at a glance, tested in simulation and always within your limits. This guide takes you from zero to your first live rule without putting a single published rate at risk.

Why one rule, not ten

In most hotels, pricing strategy lives in one person’s head or in a spreadsheet someone recalculates by hand every week. A pricing rule turns that strategy into executable logic: you write it once and the system applies it every day, consistently and traceably.

The temptation is to write every rule you have in mind at once. Resist it. With a single rule you learn how it fires, what prices it produces and how to read its log. That learning is the foundation for everything that comes next.

Anatomy of a rule: trigger, condition, action

Every pricing rule, however complex it looks, is made of three parts:

• Trigger: the data point that wakes it up. It can be the projected occupancy of a date, recent pickup (the new bookings of the last few days), lead time, day of the week or a competitor’s move.
• Condition: the filter that narrows when it applies. A date range, a season, a room type. Without a condition the rule applies to everything, and you almost never want that.
• Action: what it does when it fires. Raise or lower the rate by a percentage or an amount, or propose a stay restriction.

Read in full, a rule sounds like a business sentence: “if this happens, and we are in this context, do that”. If you cannot read your rule out loud and have it sound reasonable, it is not ready yet.

Step 1: write a simple occupancy rule

For your first rule, pick the trigger that is easiest to reason about: occupancy. It is the number you already check every day and its logic is intuitive: high demand, price up; low demand, be careful not to give margin away.

1. Phrase it in business language. Illustrative example: “if the occupancy of a date goes above 80%, raise the rate by 10%”.
2. Translate the sentence into the rule: trigger (occupancy above the threshold), condition (the date range where you want it to apply) and action (the percentage adjustment).
3. Narrow the condition to a short period, for example the next few weeks of a single season, so the outcome is easy to review.
4. Check that your price limits (floor and ceiling) are defined for that period before moving on. They are your safety net.

The numbers in the example are illustrative: the right threshold and adjustment depend on your property, your season and your market. What matters is the pattern: a clear trigger, a narrow condition, a moderate action.

Step 2: test it in simulation mode

No rule should touch your real prices the day you write it. Simulation mode runs the rule against your calendar and your history and records what it would have done, day by day, without changing a single published rate.

1. Turn the rule on in simulation mode and let it run for a week or two alongside your normal operation.
2. Review the log: which dates it fired on, what price it proposed for each one and why.
3. Compare each simulated decision against what you would have done by hand. Where they match, the rule captures your judgment well; where they differ, ask yourself who is right.
4. Adjust the threshold or the percentage if needed and simulate again. Repeat until the log earns your trust.

Your price limits always win

Before switching on any rule, define your price floor and ceiling per season and per category. In Sentinel AI no rule ever jumps them: if the calculated action falls outside the range, the price stops at the limit. That changes the psychology of going live: you are not giving up control, you are delegating decisions inside a corridor you defined. The worst possible outcome is a price at your floor or your ceiling, never beyond.

When to add the second rule

The right signal is not the calendar, it is understanding: add a second rule when you can predict, before opening the log, what the first one did and why. If the log still surprises you, it is not the time to add complexity.

When the moment comes, make the second rule cover a scenario the first one does not touch: if the first reacts to high occupancy, the second can watch low-demand dates far in advance. Two rules competing for the same scenario are a recipe for conflicts.

Common mistakes

• Switching on ten rules at once: when something looks off, you cannot tell which one did it and you end up turning everything off.
• Writing rules that contradict each other: one that raises on occupancy and one that lowers on lead time can fight over the same date. Start with scenarios that do not overlap.
• Going live without simulating: the rule behaves differently from how you imagined it, and you find out in your published rates.
• Working without a floor or a ceiling: without limits, a badly written threshold can produce an absurd price. With limits, it is impossible.
• Overreacting: aggressive adjustments (illustrative example: dropping 30% at once) create more problems than they solve. Prefer moderate, reviewable adjustments.

How it looks in Sentinel AI

In Sentinel AI you write the rule with its trigger, condition and action, run it in simulation against your own booking curve and review the log of every decision with its why. Your price limits are always respected, and when several rules apply to the same date, an explicit priority order decides and records which one won. No black boxes: the rule is yours, and so is the evidence.