Automate hotel stay restrictions.
Restore them when demand changes.
Set rules for minimum stay, arrival and departure blocks, closures and channel groups. Peaqplus watches the active demand signals, applies supported actions through your channel manager, then restores the previous setting when the condition clears.
Included in Pricing & Rate Management. Every new rule starts in notify-only, and automatic actions require a supported channel manager. Automation Rules handles restrictions; the Zone and Matrix engines handle rates.
AND 0–7 days before arrival
Fewer restriction checks. More control over the dates that matter.
The value is not automation for its own sake. It is keeping an agreed revenue strategy active between reviews, without hiding what the system changed.
Turn a repeated decision into a rule, let routine dates run and keep exceptions visible for judgement.
Review the condition, the affected dates, the previous value and the confirmed result instead of relying on an unexplained background action.
Run every new rule in notify-only first. Arm only the patterns you trust, while the rest continue to watch and report.
The move that undoes itself.
Setting a restriction is the easy half. You set a minimum stay for a strong week, the week softens, and the restriction stays there quietly turning away the bookings that would have filled it. The cost is rarely the setting — it is the forgetting.
A rule here carries the whole round trip. It runs every morning — and again whenever fresh data reaches the platform. When the situation arises, the restriction goes to your channel manager. When it passes, the original value comes back. You write down what you want once; nobody has to remember to undo it.
- Runs daily — and again when fresh data arrives, so a correction is picked up on the next evaluation rather than waiting for tomorrow
- The move is written straight to the channel manager, and from there to the channels that group covers
- Logged with its reason — which rule, which run, which condition matched
- Reversed after two consecutive non-matching runs, back to the value that was there before
- A date that has already passed is closed out in the log, never rewritten
Four rules a revenue manager actually wants.
None of these are clever. They are the moves you already make when you happen to look at the right date on the right day — which is exactly the problem.
A two-night minimum makes sense in a normal booking window. Inside the last week, with half the house empty, it just turns away the one-nighters who would have filled it. The rule drops the minimum to one night, and puts the two back when the week recovers.
A Friday already past 85% a month out does not need one-night stays leaving the Saturday next to it empty — and it certainly does not need to sell the last rooms at a discount. One condition, two moves that do different jobs: the minimum shapes the length of stay, closing the discount plan shapes what those nights are worth.
When only a handful of rooms are left, the expensive channel is the one you least want them sold on. The rule closes the OTA group for the endgame and leaves your own booking engine open. When inventory grows back, the group reopens on its own.
An event in town and a compset that has already moved up: that is the day you do not want sold cheap. Watching both sources every day, on every date, is the kind of check that rarely survives a busy week.
And for whoever is not building the rules: fewer manual checks, fewer restrictions left on by accident, and a written reason behind every change.
It sets the restrictions. The pricing engine sets the price.
Automating your rates is a different job — and the Pricing module already does it. The Zone and Matrix engines price every day by your own rules and push straight to your channels; run that fully automatically, or keep it advisory and approve each rate yourself. What you see on the Pricing Calendar is the result. Automation Rules covers the part those engines do not touch: the stay restrictions around the price.
There is a practical reason to keep the two apart, too. The rate held in Peaqplus is not a live mirror of your channel manager — someone may have repriced in the extranet an hour ago — so a restriction rule re-sending a price could quietly overwrite that. A rule writes only the one setting it is responsible for, on its own dates, and records what it replaced.
One condition can still trigger a whole set of moves — a minimum stay, a closed rate plan and a channel group in the same rule, sent as one batch. There can be one move per type, so a rule cannot contradict itself.
| Move | What it sets | Where it applies |
|---|---|---|
| Minimum stay | 1–14 nights | Room type × rate plan, or all |
| No arrival | On or off | Room type × rate plan, or all |
| No departure | On or off | Room type × rate plan, or all |
| Close the day | Fully closed | Room type × rate plan, or all |
| Channel group | Open or close | The whole group |
What your channel manager supports is what a rule can do — not every connection can make every move. The wizard marks anything yours cannot do before you pick it, and we confirm the exact list for your setup when you start. Without a supported channel manager you can still build rules that watch your dates and notify you; the automatic moves are the part that needs the connection.
See how automatic pricing works →Every rule starts by only telling you.
A new rule cannot touch anything, and that is not a setting you have to remember to check — it is where every rule begins. It watches, it matches, it writes to the log, and it notifies whoever you named: "this would have matched six days." Nothing moves.
Run it that way for a week or a month, next to the dates you know well. Read what it would have done. When you find yourself agreeing with it, arm it — and the platform asks for your password again at that moment, because switching a rule from watching to acting is not something that should happen by a stray click.
- Notify-only is the starting state of every rule, not an option you enable
- The log shows the matched dates and the moves it held back, run by run
- Arming a single rule asks for your password again — it is a per-rule decision, not a global switch
- A rule with no moves configured just watches — add moves and arm it when you are ready
- Admin rights required to manage rules at all
The signals worth building a rule on.
A rule reads the same numbers you already watch — occupancy, rate, revenue, pickup — and combines them with and/or, date by date. Below are the four signals that earn their keep when what you are automating is a restriction, plus a historical reference and the two filters that narrow any rule.
How many rooms are genuinely still yours to sell. It is not floored at zero either — a negative number is the overbooking signal, not a broken reading.
How far your own rate sits from the competitors you track — above or below, as a percentage. The condition reads the same competitor data the rate reports are built on.
Tentative and optional business as a share of the whole night — the soft part of the book. A day that looks full on paper can be mostly options that have not turned into anything yet.
Whether the date carries something from your Event Calendar — a public holiday, a local festival, a fair, a match. The pricing side already reads that calendar; now a rule can too.
Not last year's finished number — last year's same day as it looked a year ago, at this same distance from arrival. That is what makes it a real pace comparison instead of a flattering one.
Two filters narrow every rule: which weekdays it may touch (Fridays only, weekends only, any set you like) and how close to arrival it applies — anywhere from tomorrow out to two years ahead.
Not sure a pattern deserves automating yet? Several of these can run as a Ping alert first, so you can watch it for a few weeks before handing it over.
It only says what actually happened.
If the log says it happened, it happened. A change is recorded only once your channel manager has confirmed it back — so a refused change never shows up as done. You get a failure you can act on instead.
That matters most on the days you are not looking. Even a quiet run reads back cleanly: what changed, on which dates, and which rule asked for it.
- A line per move, with what was there before and what the rule set it to
- The reason attached to every write — which rule, which run, which condition matched
- Visible in the pricing log too, marked as automatic, alongside your manual changes
- Skips are logged as loudly as moves — closed period, manual change, another rule already holding the day
- A summary notification on the runs that matched or changed something, with how many dates were set and how many were put back — plus its own notice when a rule is suspended or stood down
| Date | Was | Now | |
|---|---|---|---|
| Fri, Aug 15 | min stay 2 | min stay 1 | Set |
| Sat, Aug 16 | min stay 2 | min stay 1 | Set |
| Sun, Aug 17 | min stay 1 | min stay 1 | Already so |
| Mon, Aug 18 | min stay 2 | min stay 2 | Put back |
| Tue, Aug 19 | min stay 3 | — | Yours |
When the reason goes away, the move goes with it.
The reversal is the half that decides whether you trust the thing. Once the condition has stopped matching, the platform puts back the value that was there before the rule touched it — not a default, not a guess, the actual previous value it recorded on the way in.
And it does not rush. A number sitting right on your threshold can drift across it and back within a day, so the rule waits for a second run to agree before it undoes anything. No flip-flopping on your channels.
- The original value goes back — the one recorded before the first move, not a default
- Two consecutive runs have to agree before a reversal — a wobbling number cannot start switching things back and forth
- A date already in the past is simply closed out — no pointless write to a night that has happened
- If you changed the cell yourself in the meantime, the rule lets go instead of reverting
- Reversals are not silent either — the run summary reports how many dates were put back
A change you make in Peaqplus is never written over.
This is the one that decides whether a revenue manager can live with automation. The rule set a two-night minimum on a Saturday; you opened the Pricing Calendar, knew something the data does not, and set three. From that moment the rule has no claim on that date. It does not push your three back to two, and when the condition passes it does not "restore" a one either. It steps back and says so in the log.
One thing worth knowing: the rule looks at what Peaqplus has on file, not at your channel manager. If someone edits a restriction straight in the extranet, the rule cannot see it. Keep the changes in Peaqplus and the protection holds.
The same principle settles rules arguing with each other. If two rules would touch the same setting on the same date and scope, the higher-priority one takes it and the other logs the collision and moves on. Two rules can still work the same date on different settings — a minimum stay and a channel group are not in each other's way.
- Changed in Peaqplus — the rule releases the date and logs why, with no write to the channel manager
- Applies on both paths — neither the move nor the reversal will step over you
- Ownership is per setting, per date, per scope — priority decides, the loser logs a collision and skips
- Already at the target value — the rule takes the date over without writing anything
- Every skip has a named reason, so a quiet run is still an explained run
11 rules written for you. Pick one, tune it.
You do not start from a blank condition builder. Eleven rules cover the patterns most hotels want first, grouped by what they are for: minimum stay, pace and deviation, events, competitors, channels. Pick one, move the threshold to your own numbers, choose who gets notified — and it starts watching.
Anything your channel manager cannot do is marked before you pick it, not after you save it.
- Last-minute min stay release — occupancy under target inside a week
- Filling up for Friday — inventory thinning on one weekday
- Saturday protection — the minimum held on your peak nights
- Pace guard — behind where you stood at the same point last year
- Overrun guard — running hot a long way out
- Weak outlier day — one soft date inside a strong week
- Event-day protection — an event on the calendar, sold accordingly
- Competitor guard — your rate drifting from the compset
- Last-minute restriction release — open the door as the window closes
- Saturation brake — high occupancy plus a weekday filter
- Commission guard — close the OTA group for the last rooms
When it would rather do nothing.
Automation earns its keep on the ordinary days and loses it on the odd one. These four are the odd ones — and in each, the platform stops instead of guessing.
Change the condition, the moves, the date range or the priority on a live rule and the platform reverses what that rule did and hands it back to you in notify-only. Renaming it, or changing who gets notified, does not count as a change of substance.
Nothing acts silently after an edit →A rule can ask for something your channel manager cannot do — a minimum stay it supports, an arrival block it does not. When that happens the platform stops the whole rule instead of doing the part that would fit — and tells you, once a day rather than once an hour.
Whole rule, or nothing →With moves still standing, the switch is refused — turn the rules off first, so the reversal happens on the system that made them. With nothing outstanding it goes through, and every acting rule drops back to notify-only, so a person deliberately re-arms them on the new connection.
Never mid-flight →A period you have excluded — a renovation window, a manual-strategy stretch, a booking stop — is skipped whole. Moves already standing inside it are left exactly where they are.
Your exclusions win →The pattern is the same every time: if it cannot do the whole job properly, it does none of it, and tells you why.
Included in the Pricing module.
Automation Rules has no separate subscription or setup fee. Add Pricing to BI Core for €49/month per property, or choose Growth from €236/month for properties with up to 49 rooms. The Pricing module's one-time €135 setup includes 1 hour of training. Admin rights are required to manage rules; automatic actions also need a supported channel manager.
Compare bundles and add-ons →What hotel teams ask before they automate restrictions.
Clear answers on minimum stay rules, pricing boundaries, channel-manager requirements, rollout and price.
It is a date-level rule that applies a booking restriction when selected demand conditions match. In Peaqplus, a rule can also restore the previous setting after the condition has stopped matching for two consecutive runs.
No. Automation Rules handles stay restrictions around the rate. Automatic or advisory room-rate changes are handled by the separate Zone and Matrix engines inside Pricing & Rate Management.
A rule can set minimum stay, no-arrival, no-departure, a full day closure or the open or closed state of a channel group. The available actions depend on what the hotel's configured channel-manager connection supports.
Yes. Every new rule starts in notify-only, showing the dates it matched and the actions it held back. An admin must arm each rule separately, with password re-entry, before it can make automatic changes.
No. It is included with Pricing & Rate Management and has no separate subscription or setup fee. Pricing costs €49/month per property on top of BI Core, or is included in Growth from €236/month for properties with up to 49 rooms. The one-time €135 Pricing setup includes 1 hour of training.
Write the rule once. Stop remembering to undo it.
In a 45–60 minute walkthrough on a simulated property, we build a rule around a real operating pattern. You see the dates it matches and the actions it holds back in notify-only, then step through the acting flow and the log that explains the result.
The demo is free and needs no PMS access. Automation Rules is included with Pricing; automatic actions need a supported channel manager.