Upsell by itinerary, not by email blast

Most upsell software for holiday parks runs off a single field. Check-in minus seven. On that day, everyone arriving the following week gets the same message with the same four things in it, whatever is already booked in their week. It is a date trigger wearing a commercial name. It is also the reason the second email always performs worse than the first, and the reason the third one is usually switched off by August.

Last week we made the guest's itinerary structured data: one list, assembled rather than typed, read by the guest, the shift and the floor. You can read how that works in the itinerary post from last week. This week that same list becomes targeting data. Your message templates can now be held back or released on what is, and is not, on a specific guest's itinerary. That is a smaller sentence than it sounds and a much bigger mechanism.

Pre-arrival email sells two things well

Pre-arrival email is not broken. It is narrow, and the narrowness is being mistaken for a timing problem.

A guest sitting at their kitchen table a week before travelling can decide exactly two kinds of thing. What room they are in, and what time they get in and out of it. A better room, a bigger pitch, a lodge with the hot tub. An earlier arrival, a later departure. Those are decided before the car is packed, which is why early check-in late checkout upsell pricing belongs in the pre-arrival message and genuinely converts there.

Ibiza Luxury Villas runs a 50% pre-arrival upsell rate with us. That number belongs to the pre-arrival message and to the two kinds of thing it sells. We have no equivalent figure for itinerary-targeted offers yet, and we are not going to borrow that one to stand in for it.

So upsell email timing before arrival is a solved problem for the room and the arrival hour, and a dead end for everything else. The barbecue hut on Thursday, the bike hire, the boat, the late dinner, the kids' club place on the wet morning: none of that is decided at the kitchen table. It is decided on the day, by a guest looking at an afternoon with nothing in it.

What a blast does to the guest who already booked

Here is the part that costs money rather than merely wasting it.

Send the Thursday boat trip to everyone arriving on Saturday and some of those guests already have the Thursday boat trip. They booked it in the order flow three weeks ago. They have the confirmation. Now they have an email selling them the thing they own.

A guest reads that two ways and neither is good. Either you do not know what they booked, which is worse than silence because they have already told you. Or you do know and you are selling anyway. The first is incompetence, the second is pressure, and the guest cannot tell them apart. What they can do is stop opening the next one.

That is the real cost of the blast. Not the unsubscribe, which you can measure. The quiet decision, taken by your best prospect for everything else in the library, that your messages are not about them.

What a rule actually is

Worth being literal rather than reaching for a metaphor.

A message template has a schedule, which decides when a message would go out. On top of that it can carry conditions, which decide whether it goes out at all. Both have to be satisfied. The schedule queues the message against the reservation timing, and then, at the moment it would send, every active condition is tested against that reservation. If one fails, the message is skipped for that guest and nobody has to do anything.

Ten conditions exist: date range, check-in status, stay date, day of week, user count, guest group, reservation source, on the itinerary, length of stay and guest sentiment. They combine with AND, so every active rule has to pass. All ten are documented with their operators and fields in the conditional rules guide.

The one this week is about is on the itinerary, and it has three parts you set.

A direction. Is on the itinerary, or is not on the itinerary.

A type. Experience, Amenity, Guidebook or Calendar event. Pick this first, because it changes the list underneath it.

The items. One or more, picked from your own catalogue. You are not typing a string and hoping it matches. You choose the boat trip from the list of experiences you actually sell.

Then one setting that decides what the rule means, which is the part most likely to catch you out. It is called what counts as having it, and it has three answers.

On their itinerary, however it got there counts anything on the list, including items the guest added or favourited themselves. Only if they purchased it counts only items bought through an inquiry, and is offered for experiences, because amenities and guidebooks are not sold. Only if our team added it counts operator and inquiry items but not the guest's own.

For an offer you want the second one. A guest who taps the heart on the boat trip in the guest app puts it on their itinerary with no money involved at any point. On the default setting, that guest is now excluded from the offer to actually book the boat trip, which is the precise opposite of what you built the rule for. The default is correct for an instruction, where you want to reach everyone who has parking on their plan whatever put it there. It is wrong for anything you are selling.

Ten rules, one for each condition

In the order the rule picker lists them, so this doubles as a map. Number eight is the one this week is about; the other nine are what the same mechanism does once you have it.

1. Date range, the winter welcome.

Date range · Check-in Date · between · 1 December 2026 and 28 February 2027

A seasonal message that should never reach a guest arriving in May. Worth knowing what happens at the end of it: once every active date range rule on a template has expired, the template archives itself. That is usually what you want for a seasonal campaign. It is not what you want if you used a date range with not between to pause a message for a fortnight, because the template will archive the night that period ends.

2. Check-in status, the check-in nudge.

Check-in status · equals · Not Checked In

The reminder that should only reach the guests who have not done it yet. The condition is tested at the moment the message would send, which is the whole point here and also its limit: scheduled three days before arrival it always passes, because nobody has checked in three days early. Put it on a message timed at or after the check-in moment or it does nothing.

3. Stay date, the New Year's Eve dinner.

Stay date · any in stay · 31 December 2026

Stay date asks whether a date falls anywhere inside the stay, which is why this is the right condition rather than a date range on the arrival. It catches the guest who arrived on the 28th and the guest arriving on the 31st, without you listing arrival dates. The inverse, none in stay, excludes a stay that overlaps a date when something is closed.

4. Day of week, the late checkout offer.

Day of week · Check-out Date · matches any of · Sunday

Sunday is where your changeover has slack, so Sunday is when a late checkout costs you least and sells best. The weekday is read in the property's own timezone, so a departure just after midnight counts on the local calendar day rather than a UTC one.

5. User count, the registration nudge.

User count · equals · 0

The message that goes to the booking nobody has opened yet. And the trap underneath it, which is worth a moment because the name misleads: user count means guests who have registered or been invited to the guest portal. It is not the party size. A reservation booked for four people counts as zero until those guests actually register, so this reaches the quiet booking rather than the solo traveller.

6. Guest group, the returning guest welcome.

Guest group · is in any of · Returning

Different words for the guest who has been before. The rule is checked against every guest attached to the reservation and one match is enough, so a family where only the booker is a returning guest still passes.

7. Reservation source, book direct next time.

Reservation source · came from none of · Direct

Build the OTA side as an exclusion of direct rather than by ticking every OTA you work with. The two look identical today. The difference arrives the first time a new booking source is added to the platform: came from none of covers it automatically, while a ticked list silently leaves those guests out and nobody notices for a season. Note too that reservations imported before the booking source was recorded have no source at all, so they never match came from any of and always match came from none of.

8. On the itinerary, the breakfast offer.

On the itinerary · is not on the itinerary · Experience · Breakfast What counts as having it: only if they purchased it

The one this week is about, and the smallest useful rule in the system. One condition, and the guests who already bought breakfast stop being sold breakfast. Set the last line or it will quietly invert: on the default, a guest who favourited breakfast counts as having it, so the person most likely to buy is the one excluded from the offer. The inverse direction is just as useful and takes the default happily, because the parking code should reach everyone who has parking on their plan however it got there.

This is also the one to stack. Rule four on its own offers late checkout to every Sunday departure, including the ones who already bought it. Rule four and rule eight on the same template, pointed at your late checkout experience, offers it to the Sunday departures who have not. That is the honest version, and it is two conditions rather than a cleverer one.

9. Length of stay, the mid-stay housekeeping note.

Length of stay · greater than or equal to · 7

Nobody staying two nights needs a mid-stay note. Everybody staying nine does. Nights are counted as calendar nights in the property's timezone, and if you use between, both bounds are included: between 2 and 4 matches a two, three or four night stay.

10. Guest sentiment, the review request.

Guest sentiment · Skip unhappy guests preset · is at least · 40%

The review request you would rather not send to a guest who is having a poor week. One limitation that decides whether this behaves: a guest who has never sent you a message counts as neutral, which is 50%, so this rule still includes them. If you want only the guests who have actively been positive, the threshold has to go above 50 rather than above 40.

What a rule cannot ask for

Four limits, each of which will otherwise be discovered by building the clever version and watching it send to nobody.

It points at items, not at days. This is the one that matters most and the one people assume their way past. You can ask for a guest who does not have the boat trip. You cannot ask for a guest who has nothing booked on Thursday. There is no condition that reads a day of a stay and reports it empty. Every itinerary rule names an item from your catalogue, so the version of this that works is a named offer that a named guest has not bought.

One type per rule. A rule covers Experience or Amenity or Guidebook or Calendar event, not several. If breakfast exists in your catalogue as both an experience and an amenity, that is two rules, and because rules combine with AND, adding both asks for guests who have neither. Two templates with one rule each, not two rules on one template.

No OR. Every active condition has to pass. Summer guests or winter guests is two message templates. There is no way to write it as one.

A rule cannot be edited once added. You switch it off or delete it, and to change one you add the replacement and remove the original. Minor until the first time you want to move a threshold from four to three.

One more that is less a limit than a tripwire: when every active date range rule on a template has expired, the template archives itself. That is usually what you want for a seasonal campaign. It is not what you want if you used a date range with not between to pause a message for a fortnight and then forgot to delete it, because the template will archive the night the period ends.

The reservation changes, the rule runs again

This is the detail that decides whether you trust any of it, so it gets its own space.

Guests change their plans. A reservation gets edited in your property system on a Tuesday afternoon: the party grows by two, a night comes off, somebody finally books the boat trip on the phone. Every targeting rule you wrote on Monday is now describing a guest who no longer exists.

Rules are checked at the moment of sending, not at the moment of scheduling. That one sentence is doing all the work. The message is queued as normal against the reservation timing, and then, at the moment it would go out, every active rule is tested against the reservation as it stands right then. A send that no longer applies is skipped. A send that now applies goes. No operator action, no re-running a segment, no stale list sitting in a queue waiting to embarrass you.

You can also see it before it happens. The forecast on a reservation refreshes whenever its dates, check-in status, booking source, itinerary or guest sentiment change, and whenever you add, switch off or delete a rule. Open any reservation, go to its message templates, and a send that will not pass says so: will be skipped due to condition rules not being met. You are not trusting this on faith. You can go and look at a specific booking.

That is the difference between a rule and an export. An export is true at the moment you take it and decaying from then on. A rule is a question the system keeps asking. It also means the exclusion rule holds at the only time it has to: the guest who buys the boat trip at 16:00 does not get sold it at 18:00.

Why upsell software for holiday parks gains more than a hotel does

A city hotel has a desk, a short stay, and a guest whose evenings are mostly spoken for elsewhere. Three nights, two of them with plans already made in the city. The desk catches what is left.

A park inverts all three. Stays run a week or longer, which is why rule nine exists. The hours are unstructured, which is the point of the holiday and also the commercial opening. And there is often one desk for three hundred units, or none at all, which means an offer not made on the guest's own screen is not made. The same holds harder for upsell software for vacation rentals, where the guest arrives on a door code and every commercial moment after booking happens on a screen. OVO Network runs 250+ chalets on exactly that pattern.

What this does not do

Said plainly, because you would find it out in week two anyway.

The system does not find the gap. You do. It does not look at a stay, notice that Thursday is empty and propose an offer for it. There is no capability here that reads a guest's week and decides what is missing. What exists is a rule you write, pointed at an item you choose, which the system then evaluates on every reservation and on every change to a reservation, and acts on consistently at a scale no person could match.

That distinction is the whole honesty of this release. The intelligence in the rule is yours. Ours is the evaluation: relentless, identical every time, and correct after the guest changes their mind.

The AI does not write or price the offer. Copy is yours. Price is yours. Availability is yours.

A rule cannot be edited once it is added. You can switch it off or delete it, and to change one you add the replacement and remove the original. Minor, and it will bite you the first time you want to move a threshold from four to three.

Conditions are AND only. Every active rule has to pass. Anything that needs an either or is two message templates.

Proposing the moment, so that the software suggests the rule rather than waiting for you to write it, is where this is going. It is not built, and we would rather tell you that than let a demo imply otherwise.

The recommendations still cannot be bought

One carry-over from last week, which applies with more force once money is involved. The local recommendations beside the itinerary are the ones you picked. Nothing in the offer library ranks them, nobody buys placement, and no third party reaches your guest's screen by paying the most. That is a commercial argument before it is a principled one: a list that can be bought carries no information in its order, and a guest sent somewhere poor blames the property rather than the platform.

The guest says yes

A blast asks a question of everybody. A rule asks it of the guests for whom it is true, and stops asking the moment it stops being true.

Start with rule eight. Do not sell breakfast to the guest who bought breakfast. It is one condition and one setting, it takes about a minute, and it is the rule that pays for itself in goodwill the first morning it runs. Then write the inverse, the instruction that only reaches the guests it applies to, and you have the shape of every other rule in the library. More of this argument sits on effortless revenue.

Then the guest taps yes, and a different set of questions begins: who is told, who prepares it, and how an order reaches the supplier who actually fulfils it. Routing is live in preview. That is next week.

Every condition, with its operators, its fields and the traps in each, is written up in the conditional rules guide.

HolidayHero runs on top of the property system you already have, across 3,500+ properties, in 100+ languages. Pricing is published, from €6.50 per unit per month with no setup fee.