> For the complete documentation index, see [llms.txt](https://support.holidayhero.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.holidayhero.com/the-basics/communication/conditional-rules.md). # Conditional Rules Conditional rules decide whether a scheduled message is actually sent, based on details of the reservation. Use them to target the right guests without duplicating templates. **What are conditional rules?** *Conditional rules* are additional filters on top of a message template's schedule. They determine **if** a scheduled message should actually be sent to the guest, based on the reservation's details. Where the schedule ("When") decides *at what moment* a message goes out, a conditional rule decides *whether* it goes out at all. A template can hold multiple rules — all active rules must pass for the message to be sent. If any rule fails, the message is skipped. You'll find the rules in the **Conditional Rules** section of a message template, below its schedule. On the **Message Templates** overview, a template with rules carries a blue **conditions** badge with the number of rules on it.

The Conditional Rules section of a message template, with three rules combined with AND

**Rules and Scheduling** Conditional rules are evaluated at the scheduled moment of sending. This means: * A message is still scheduled as normal based on the reservation timing. * At the moment of sending, we check all active rules against the reservation. * If one or more rules don't match, the message is skipped for that reservation. This allows you to re-use a single message template across many reservations while still tailoring *who* actually receives it. **Adding a conditional rule** Rules are added one at a time, in a three-step dialog: **Rule type**, **Configure** and **Review**. The timeline on the left shows where you are. 1. Go to **Message Templates** and open the template. 2. In the **Conditional Rules** section, click **Add Condition**. 3. **Rule type** — click the kind of check you want. This takes you straight to the next step.

Step 1: choose what the rule should check

4. **Configure** — fill in the condition. The fields differ per rule type; each one is explained under [Rule Types](#rule-types) below. The blue box under the fields says in plain words when the message will be sent. 5. Click **Next**. If something required is missing — no day picked, no source ticked — the dialog stays on this step and tells you what to add. 6. **Review** — check the rule type and the condition. Leave **Active** switched on to apply the rule right away, or switch it off to add it without using it yet.

Step 3: review the condition and decide whether it applies right away

7. Click **Add Condition**. The rule is saved immediately and appears in the **Conditional Rules** section — you don't need to click **Save** on the template. To change your mind halfway, click **Back**, or click an earlier step in the timeline. {% hint style="info" %} A rule can't be edited once it is added. To change one, add a new rule with the right settings and delete the old one. {% endhint %} **Activation** Every conditional rule has an active/inactive toggle. An inactive rule is ignored during evaluation, so you can temporarily disable a rule without deleting it. This is useful for seasonal rules that you'd like to re-use later in the year. **To switch a rule off or on:** 1. Open the message template. 2. In the **Conditional Rules** section, click the toggle to the right of the rule. The change is saved straight away. A switched-off rule shows an **Inactive** badge. **To delete a rule:** 1. Open the message template. 2. Click the trash icon below the rule's toggle. 3. Confirm. *** #### **Rule Types** There are eleven types of conditional rules available. ### **1. Date Range** Send only if the reservation's check-in or check-out date falls within (or outside) a specific period. * **Field** - The reservation date to check against. * *Check-in Date* - evaluates the reservation's arrival date. * *Check-out Date* - evaluates the reservation's departure date. * **Operator** * *Between* - the selected date must fall inside the start and end dates. * *Not between* - the selected date must fall outside the start and end dates. * **Start Date / End Date** - the boundaries of the period. **Example:** A "Winter welcome" message that should only go out to guests checking in between `2026-12-01` and `2027-02-28`. Use *Check-in Date* + *Between* with those dates.

Once added, the rule on the template shows where the period stands: **Date range is currently valid**, **Date range starts in** a number of days, or **This date range has expired**. A template whose date ranges have all ended is archived automatically — see [Expired date ranges](#expired-date-ranges). ### **2. Check-in Status** Send based on whether the guest has already checked in at the moment the message is scheduled to be sent. * **Operator** * *Equals* - the guest's check-in status must match the selected value. * *Not Equals* - the guest's check-in status must not match the selected value. * **Status** * *Checked In* - the guest has completed check-in. * *Not Checked In* - the guest has not yet completed check-in. **Example:** A reminder "Don't forget to check in" should only go out to guests who haven't checked in yet. Use *Equals* + *Not Checked In*. **Note:** this rule is only meaningful for messages scheduled around or after the check-in moment. A message scheduled three days before arrival will always evaluate as "Not Checked In".

A Check-in Status rule for guests who haven't checked in yet

### **3. Stay Date** Send based on whether one or more specific dates fall within the guest's stay (from check-in to check-out). * **Operator** * *Any in stay* - at least one of the selected dates must fall within the guest's stay. * *None in stay* - none of the selected dates may fall within the guest's stay. * **Dates** - one or more specific dates. Add dates one by one using the date picker. Each added date is shown as a tag and can be removed. **Example:** A "Happy New Year" message that should go to guests staying on December 31st. Add `2026-12-31` with *Any in stay*. Any reservation overlapping that date will receive the message, regardless of whether the guest checked in that day or was mid-stay. **Example:** A rule to exclude guests whose stay overlaps a local holiday when a specific service isn't available. Add the holiday dates with *None in stay*.

### **4. Day of Week** Send based on which weekday the check-in or check-out falls on. This is useful for recurring, day-specific campaigns that aren't tied to particular calendar dates. * **Field** - The reservation date whose weekday is checked. * *Check-in Date* - evaluates the weekday of the reservation's arrival date. * *Check-out Date* - evaluates the weekday of the reservation's departure date. * **Operator** * *Matches any of* - the weekday must be one of the selected days. * *Matches none of* - the weekday must not be any of the selected days. * **Days** - one or more weekdays (Sunday–Saturday). At least one is required. **Example:** A "Late checkout available" message for guests checking out on a Sunday. Use *Check-out Date* + *Matches any of* + *Sunday*. A matching "Early check-in" campaign uses *Check-in Date* + *Matches any of* + *Sunday*. **Note:** the weekday is evaluated in the **property's local timezone**, not UTC. A check-out just after midnight is counted on the local calendar day at the property, so the day matches what the guest experiences on-site.

A Day of Week rule for guests checking out on a Sunday

### **5. User Count** Send based on how many users are attached to the reservation. This counts the guests who have been **registered or invited to the guest portal** — not the guest party size (number of adults, children and babies). * **Operator** - how the attached-user count is compared against the value. * *Equals* - the count must be exactly the value. * *Less than* - the count must be below the value. * *Less than or equal to* - the count must be at most the value. * *Greater than* - the count must be above the value. * *Greater than or equal to* - the count must be at least the value. * **Number of attached users** - the threshold to compare against (a whole number, `0` or higher). **Example:** An onboarding nudge that should only go out when nobody has registered yet. Use *Equals* + `0`. **Example:** A group-specific message for bookings with multiple registered guests. Use *Greater than or equal to* + `2`. **Note:** this counts users linked to the reservation, which is different from the booking's party size. A reservation booked for four people still counts as `0` attached users until those guests register or are invited to the guest portal.

A User Count rule for reservations nobody has registered on yet

### **6. Guest Group** Send based on whether a guest on the reservation belongs to one of your guest groups. * **Operator** * *Is in any of* - at least one guest on the reservation must belong to one of the selected groups. * *Is in none of* - no guest on the reservation may belong to any of the selected groups. * **Guest groups** - one or more of the workspace's guest groups. At least one is required. **Example:** A returning-guest welcome that should only go to repeat visitors. Use *Is in any of* + your **Returning** group. **Note:** the rule is checked against every guest attached to the reservation — one match is enough for *Is in any of* to pass. Groups are managed under **Guest Groups**; a group deleted after the rule was created is shown in the rule as a deleted group.

### **7. Reservation Source** Send based on where the booking came from — an OTA such as Booking.com or Airbnb, or a direct booking. This is how you send one message to OTA guests and a different one to guests who booked with you directly. * **Presets** - two buttons that fill in the two common cases in one click: **Any OTA booking** and **Direct bookings only**. You can adjust the selection afterwards. * **Operator** * *Came from any of* - the reservation's source must be one of the selected sources. * *Came from none of* - the reservation's source must not be any of the selected sources. * **Sources** - one or more booking sources. At least one is required. **Example:** A message that asks OTA guests to book directly next time. Use *Came from none of* + **Direct**. **Example:** A message only for guests who booked on Booking.com. Use *Came from any of* + **Booking.com**. {% hint style="warning" %} For an "any OTA" rule, always exclude **Direct** with *Came from none of* rather than ticking every OTA individually. The two look identical today, but when a new booking source is added to the platform, *Came from none of* covers it automatically, while a list of ticked OTAs silently leaves it out and those guests stop receiving the message. {% endhint %} **Note:** reservations imported before the booking source was recorded have no source at all. They never match *Came from any of*, and always match *Came from none of* — so an old reservation can slip through an "OTA only" rule built with *Came from any of*.

The Any OTA booking preset: every source except Direct

### **8. On the Itinerary** Send based on whether something is on the guest's itinerary. The two directions operators use most are the upsell nudge ("breakfast is *not* on their itinerary → send the breakfast offer") and the conditional instruction ("parking *is* on their itinerary → send the barrier code"). * **Operator** * *Is on the itinerary* - at least one of the selected items must be on the itinerary. * *Is not on the itinerary* - none of the selected items may be on the itinerary. * **Type** - what kind of thing the rule is about: *Experience*, *Amenity*, *Guidebook* or *Calendar Event*. Pick this first; the list of items below it changes to match. * **Items** - one or more items of that type. At least one is required. * **What counts as having it** - see below. * **Advanced: itinerary status** - which itinerary statuses count. *Confirmed* on its own is the default and is almost always what you want. **Example:** A breakfast upsell for guests who haven't got it yet. Use *Is not on the itinerary* + *Experience* + **Breakfast**. **Example:** Parking instructions that should only go to guests who actually have parking. Use *Is on the itinerary* + *Amenity* + **Parking**. ***What counts as having it*** This setting decides what the rule actually means, so it is worth a moment: | Choice | What it matches | | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | **On their itinerary, however it got there** | Anything on the itinerary, including items the guest added or favourited themselves. This answers *"is it on their plan"*, **not** *"did they pay for it"*. | | **Only if they purchased it** | Only items booked through an inquiry. Offered for **experiences only** — amenities, guidebooks and calendar events are never sold through an inquiry. | | **Only if our team added it** | Items added by an operator or through an inquiry, but not ones the guest added themselves. | {% hint style="warning" %} A guest favouriting an experience in the guest app puts it on their itinerary with **no money involved**. If you are building an upsell or a "thanks for booking" message, choose **Only if they purchased it** — leaving it on the default will treat a favourite as a purchase. {% endhint %} **Note:** a rule covers one type only. To match a breakfast *experience* or a breakfast *amenity*, you would need two rules — but remember rules are combined with AND, so two rules ask for *both*. Use separate message templates for an either/or. **Note:** free-form itinerary lines — text a guest typed in themselves — are never matched. A guest writing "Breakfast" as their own itinerary note does not satisfy a rule that names the Breakfast experience.

A breakfast upsell: only for guests who haven't purchased breakfast

### **9. Length of Stay** Send based on how many nights the reservation covers. This is the rule for messages that only make sense for a short break or for a long stay — a mid-stay housekeeping note, or a weekly-rate offer. * **Operator** - how the number of nights is compared against the value. * *Equals* - the stay must be exactly that many nights. * *Not equals* - the stay must be any length other than that. * *Less than* - the stay must be shorter than the value. * *Less than or equal to* - the stay must be at most that many nights. * *Greater than* - the stay must be longer than the value. * *Greater than or equal to* - the stay must be at least that many nights. * *Between* - the stay must fall within the minimum and maximum. * *Not between* - the stay must fall outside the minimum and maximum. * **Number of nights** - the threshold to compare against (a whole number, `0` or higher). Shown for every operator except *Between* and *Not between*. * **Minimum nights** / **Maximum nights** - the two bounds, shown only for *Between* and *Not between*. The maximum must be at least as large as the minimum. **Example:** A weekly-rate upsell for longer bookings. Use *Greater than or equal to* + `7`. **Example:** A mid-stay check-in message that only suits a short break. Use *Between* + `2` and `4`. **Note:** *Between* and *Not between* **include both bounds** — *Between* `2` and `4` matches a 2, 3 or 4 night stay. Nights are counted as calendar nights in the **property's local timezone**, so a late-evening check-in and a morning check-out the following week count as the nights the guest actually sleeps at the property, not as a rounded number of hours.

A Length of Stay rule with Between: the minimum and maximum fields replace the single number

### **10. Guest Sentiment** Send based on how positive or negative the guests' recent messages are. Every message a guest sends is scored for sentiment, and this rule compares that score against a percentage you choose — from `0%` (very negative) to `100%` (very positive). Use it to hold back a message from guests who are unhappy, or to send one only to them. * **Presets** - the two common cases, one click. You can adjust the condition afterwards. * *Skip unhappy guests* - sets *Is at least* `40%`: neutral and positive guests receive the message, guests with negative sentiment don't. * *Unhappy guests only* - sets *Is lower than* `40%`: only guests with negative sentiment receive the message. * **Guest sentiment** - how the score is compared. * *Is lower than* - the score must be below the value. * *Is at most* - the score must be at or below the value. * *Is higher than* - the score must be above the value. * *Is at least* - the score must be at or above the value. * *Is between* - the score must fall within the two values. * *Is not between* - the score must fall outside the two values. * **Sentiment** - the percentage to compare against (a whole number from `0` to `100`). Shown for every operator except *Is between* and *Is not between*. * **From** / **To** - the two bounds, shown only for *Is between* and *Is not between*. **To** must be at least as large as **From**. While you configure the rule, a scale under the preview shades the part where the message is sent, so you can see at a glance which guests it covers. The scale is divided into five bands: | Score | Sentiment | | --------- | ------------- | | `0–20%` | Very negative | | `20–40%` | Negative | | `40–60%` | Neutral | | `60–80%` | Positive | | `80–100%` | Very positive | **Example:** A review request you don't want to send to an unhappy guest. Use the *Skip unhappy guests* preset (*Is at least* `40%`). **Example:** A service-recovery message — an apology with a small gesture — for guests who are clearly unhappy. Use the *Unhappy guests only* preset (*Is lower than* `40%`). {% hint style="warning" %} Guests who haven't sent a message count as **neutral (`50%`)**. So *Is lower than* `40%` skips them, while *Is lower than* `60%` includes them. The preview in the dialog, and the rule on the template page, say which way your rule goes. {% endhint %} **Note:** the score covers **every guest on the reservation** and their messages from the **last 30 days**, with recent messages weighing most. It is the same number as the sentiment part of the guest's engagement score. Like every rule, it is checked again at the moment the message is sent, so the *Will be skipped* forecast on a reservation's scheduled messages updates as new guest messages come in — see [Checking a reservation](#checking-a-reservation). *Is between* and *Is not between* **include both bounds**.

The Skip unhappy guests preset, with the shaded scale showing who receives the message

### **11. Listing Type** Send based on the type of listing the guest is staying in — only to guests in a **Deluxe** room, for example, or to everyone *except* them. Listing types are the groups you create under **Listings → Listing Types**; see [Listing Types](/the-basics/listings/listing-types.md). * **Operator** * *Is any of* - the reservation's listing must have at least one of the selected listing types. * *Is none of* - the reservation's listing may not have any of the selected listing types. * **Listing types** - one or more of the workspace's listing types. At least one is required. **Example:** An upgrade offer for guests who aren't in one of your best rooms yet. Use *Is none of* + **Deluxe**. **Example:** Balcony instructions that only apply to rooms with a view. Use *Is any of* + **Sea view**. **Note:** a listing can have more than one type, and one match is enough. With *Is any of* + **Deluxe** and **Sea view**, a listing that is only **Sea view** passes. A reservation whose listing has no listing type at all never matches *Is any of*, and always matches *Is none of*. **Note:** the rule looks at the listing's types at the moment of sending, not at the moment of booking. Giving a listing a type, taking one away, or moving the reservation to another listing changes the outcome for its upcoming messages. {% hint style="info" %} The rule only narrows down the listings already connected to the template. A reservation on a listing that isn't connected never receives the message, whatever its type. A template is connected to all listings by default. {% endhint %} The list of listing types needs the **Listings → Read** permission. If your workspace has no listing types yet, the dialog links you to **Manage listing types** to create them.

An upgrade offer: only for guests who aren't in a Deluxe room

A listing type that an active Listing Type rule uses can't be deleted. Delete the rule first, or switch it off. Deleting a type that a switched-off rule uses takes the type off that rule's list, so check the rule before you switch it back on. ### **12. Next Day(s) Availability** Send only when the night(s) right after check-out are still free. This is the rule for an offer you can only honour if there is room for it — *extend your stay by a night*, or *move to a Deluxe for your last evening*. * **Where to look** - which listings count as free. * *This listing* - the night must be free in the guest's own listing, so the guest can stay put. * *Any listing of the same listing type* - the night must be free in at least one listing carrying the same listing type, so the guest can be moved to an equivalent room. The guest's own listing counts too. * **Number of nights after check-out** - how many consecutive nights must be free, counted from the check-out date (a whole number from `1` to `14`). * **Availability** - which way the rule reads. * *Is still free* - send when all of those nights are free. * *Is not free* - send when at least one of them is taken. **Example:** An extend-your-stay offer sent the morning before check-out. Use *This listing* + `1` night + *Is still free*. **Example:** A last-night upgrade to an equivalent room. Use *Any listing of the same listing type* + `1` night + *Is still free*. **Example:** A "we're fully booked, book early next time" note. Use *This listing* + `1` night + *Is not free*. **Note:** the nights counted **start on the check-out date**. A guest leaving on Friday morning does not hold the night that begins that Friday evening, so a back-to-back extension reads as free rather than as a clash with their own booking. {% hint style="warning" %} Availability here is derived from the **bookings in HolidayHero**. Owner blocks, maintenance holds, stop-sells and minimum-stay restrictions that live only in your PMS are not visible to this rule, so a message can offer a night your PMS cannot actually sell. Keep that in mind for the wording of the offer. {% endhint %} **Note:** unlike the other rules, this one is moved by **other guests' bookings**. The *Will be skipped* forecast on a reservation's scheduled messages is refreshed whenever a booking in the same listing is made, moved to other dates or another listing, cancelled or reinstated. With *Any listing of the same listing type*, a booking in any listing of that type counts too. Every night the forecast is checked once more, and like every rule it is checked again at the moment the message is sent — see [Checking a reservation](http://localhost:63342/markdownPreview/1539288386/markdown-preview-index-msdnmi0djif3jjg7ch1g7d1ien.html#checking-a-reservation).

*** **Combining Rules** A message template can have multiple conditional rules at the same time. All active rules must pass — they are combined with AND logic. For example, a template with both a *Date Range* rule (check-in in December) and a *Check-in Status* rule (Not Checked In) will only be sent for December check-ins who haven't checked in yet. If you need OR logic (e.g. "send to summer *or* winter guests"), create separate message templates instead of combining rules on one template. #### **Checking a reservation** You can see what your rules mean for a specific booking before the message goes out. 1. Open the reservation. 2. Go to the **Message Templates** tab. A scheduled message that doesn't pass its template's rules shows **Will be skipped due to condition rules not being met**. Once the moment of sending has passed, it reads **Skipped due to condition rules not being met**. The rest of that tab is explained in [Messages (Templates)](/the-basics/communication/message-templates.md). The forecast is refreshed when a rule on the template is added, switched on or off, or deleted, and when the reservation's dates, check-in status, booking source, itinerary or guest sentiment change. The rules are checked once more at the moment of sending, so the outcome can still change — for example when a guest registers or joins a guest group after the forecast was made. #### **Expired date ranges** When the end date of a **Date Range** rule has passed, the rule shows **This date range has expired** on the template. Once **every active** Date Range rule on a template has ended, the template is archived automatically — in the nightly check, or straight away when you add, switch or delete a rule on it. It moves to the **Archived** tab of the overview with an **Auto Archived** badge and is no longer scheduled for new reservations (see [Archiving](#why-was-my-message-template-archived-automatically)). On the template, the expired rule then says **Template will be auto-archived**. This happens whatever the template's other rules are. A switched-off Date Range rule doesn't count, and a template without Date Range rules is never archived this way. {% hint style="warning" %} This applies to *Not between* rules too. If you used *Not between* to pause a message for a period, delete the rule once that period is over — otherwise the template is archived the following night. If it already was, delete the rule first and then unarchive the template. {% endhint %} **To bring an auto-archived template back**, add a Date Range rule that ends in the future. The template is unarchived straight away and scheduled again for matching reservations. You can also unarchive it from the `⋮` menu on the overview, but as long as all of its active date ranges have ended, it is archived again the following night. A template that an operator archived by hand is never unarchived automatically.
*** **Frequently Asked Questions**

What happens if I add a rule to a message template that was already scheduled?

Rules are evaluated at the moment of sending, not at the moment of scheduling. This means adding or changing a rule affects all future sends, including messages that were already scheduled before the rule was added.

Can I deactivate a rule instead of deleting it?

Yes. Every rule has an active toggle. An inactive rule is ignored during evaluation, so you can keep seasonal or situational rules around without them affecting the template.

Why is my message not being sent even though the schedule is correct?

If a conditional rule doesn't match, the message is skipped at sending time. Check the active rules on the template and verify that the reservation meets all of them. Remember: all active rules must pass (AND logic). The reservation's **Message Templates** tab tells you whether this is the reason: the message shows **Will be skipped due to condition rules not being met**. See [Checking a reservation](http://localhost:63342/markdownPreview/816070197/markdown-preview-index-8k363f7ka9kg215a2b3n8neddi.html#checking-a-reservation).

Can I change a rule after adding it?

No. A rule can only be switched on or off, or deleted. To change one, add a new rule with the right settings and delete the old one.

Why was my message template archived automatically?

All of its active **Date Range** rules have ended. When that happens, the template is archived automatically and shows an **Auto Archived** badge. Add a Date Range rule that ends in the future to bring it back — see[ Expired date ranges](#expired-date-ranges).

How do I send one message to OTA guests and another to direct bookers?

Use two message templates, each with a **Reservation Source** rule. On the OTA template use *Came from none of* + **Direct**; on the direct template use *Came from any of* + **Direct**. Building the OTA side as an exclusion of **Direct** rather than a list of ticked OTAs means new booking sources are covered automatically as they are added.

My "on the itinerary" rule matches guests who never paid. Why?

A guest favouriting an experience in the guest app writes it to their itinerary, with no purchase involved. The **On their itinerary, however it got there** setting counts those. Open the rule's **What counts as having it** setting and choose **Only if they purchased it** instead.

Can I use conditional rules in combination with listing filters?

Yes. Listing connections and conditional rules work independently. A message will only be considered if the reservation's listing is connected to the template *and* all active rules pass.

*** ## Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://support.holidayhero.com/the-basics/communication/conditional-rules.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.