---
title: "Upsell-software vakantieparken: richten op het reisschema"
description: "De meeste upsell-tools vuren op check-in min zeven. Richt je aanbod op wat wel en niet op het reisschema van de gast staat, getoetst bij elke wijziging."
url: "https://www.holidayhero.com/nl/blog/Conditionele-regels-op-je-communicatie"
published: "2026-10-22T09:09:27+00:00"
updated: "2026-10-22T09:09:27+00:00"
author: "Kevin Hoft"
---

# Conditionele regels op je communicatie

> De meeste upsell-tools timen een aanbod op één datumveld, check-in min zeven, en bereiken iedereen met hetzelfde, wat er ook al in hun week staat. Richt je message template in plaats daarvan op de inhoud van het reisschema van de gast, en schrijf de regel zelf.

- **Categories** — Release Radar

De meeste upsell-software voor vakantieparken draait op één veld. Check-in min zeven. Op die dag krijgt iedereen die volgende week aankomt hetzelfde bericht met dezelfde vier dingen erin, wat er ook al in hun week geboekt staat. Het is een datumtrigger met een commerciële naam. Het is ook de reden dat de tweede mail altijd slechter presteert dan de eerste, en dat de derde in augustus meestal uitstaat.

Vorige week hebben we het reisschema van de gast tot gestructureerde data gemaakt: één lijst, samengesteld in plaats van getypt, gelezen door de gast, de dienst en de vloer. Hoe dat werkt staat in [de post over het reisschema van vorige week](/blog/wie-plant-dag-drie-gastreisschema). Deze week wordt diezelfde lijst targetingdata. Je message templates kunnen nu worden tegengehouden of vrijgegeven op wat er wel en niet op het reisschema van een specifieke gast staat. Dat is een kleinere zin dan hij klinkt en een veel groter mechanisme.

## Pre-arrival e-mail verkoopt twee dingen goed

Pre-arrival e-mail is niet stuk. Hij is smal, en die smalheid wordt aangezien voor een timingprobleem.

Een gast die een week voor vertrek aan zijn keukentafel zit, kan precies twee soorten dingen beslissen. In welke kamer hij zit, en hoe laat hij erin en eruit gaat. Een betere kamer, een grotere plek, een lodge met de hottub. Een eerdere aankomst, een later vertrek. Dat wordt beslist voordat de auto is ingeladen, en daarom hoort de prijs voor early check-in en late checkout in het bericht voor aankomst en converteert hij daar ook echt.

Ibiza Luxury Villas haalt bij ons een upsellpercentage van 50% voor aankomst. Dat getal hoort bij het bericht voor aankomst en bij de twee soorten dingen die het verkoopt. Voor aanbiedingen die op het reisschema gericht zijn hebben we nog geen vergelijkbaar cijfer, en we gaan dit getal er niet voor lenen.

Dus de timing van upsellmail voor aankomst is een opgelost probleem voor de kamer en het aankomstuur, en een doodlopende weg voor al het andere. De barbecuehut op donderdag, de fietsverhuur, de boot, het late diner, een plek bij de kinderclub op de regenachtige ochtend: niets daarvan wordt aan de keukentafel beslist. Dat wordt op de dag zelf beslist, door een gast die naar een middag kijkt waarin niets staat.

## Wat een blast doet met de gast die al geboekt heeft

Dit is het deel dat geld kost in plaats van alleen maar verspilt.

Stuur de boottocht van donderdag naar iedereen die op zaterdag aankomt en een deel van die gasten heeft de boottocht van donderdag al. Ze hebben hem drie weken geleden in het bestelproces geboekt. Ze hebben de bevestiging. Nu hebben ze een mail die hun iets verkoopt wat ze al bezitten.

Een gast leest dat op twee manieren en geen van beide is goed. Of je weet niet wat hij geboekt heeft, wat erger is dan stilte omdat hij het je al verteld heeft. Of je weet het wel en je verkoopt het alsnog. Het eerste is onkunde, het tweede is druk, en de gast kan het verschil niet zien. Wat hij wel kan, is de volgende niet meer openen.

Dat zijn de echte kosten van de blast. Niet de afmelding, die kun je meten. De stille beslissing, genomen door je beste kandidaat voor al het andere in je aanbod, dat jouw berichten niet over hem gaan.

## Wat een regel eigenlijk is

Het is beter dit letterlijk te zeggen dan naar een metafoor te grijpen.

Een message template heeft een schema, dat bepaalt wanneer een bericht de deur uit zou gaan. Daarbovenop kan hij voorwaarden dragen, die bepalen of hij überhaupt de deur uit gaat. Aan beide moet zijn voldaan. Het schema zet het bericht in de wachtrij tegen de timing van de reservering, en dan, op het moment dat het zou versturen, wordt elke actieve voorwaarde getoetst aan die reservering. Faalt er één, dan wordt het bericht voor die gast overgeslagen en hoeft niemand iets te doen.

Er zijn tien voorwaarden: date range, check-in status, stay date, day of week, user count, guest group, reservation source, on the itinerary, length of stay en guest sentiment. Ze combineren met AND, dus elke actieve regel moet slagen. Alle tien staan met hun operatoren en velden in [de handleiding over conditional rules](https://support.holidayhero.com/the-basics/communication/conditional-rules). De handleiding is in het Engels, net als de namen van de voorwaarden in het beheer.

Deze week gaat over **on the itinerary**, en die heeft drie onderdelen die je zelf instelt.

**Een richting.** Is on the itinerary, of is not on the itinerary.

**Een soort.** Experience, Amenity, Guidebook of agenda-item. Kies die eerst, want hij verandert de lijst eronder.

**De items.** Eén of meer, gekozen uit je eigen aanbod. Je typt geen tekst in de hoop dat hij matcht. Je kiest de boottocht uit de lijst met experiences die je echt verkoopt.

En dan één instelling die bepaalt wat de regel betekent, en dat is het deel dat je het makkelijkst verkeerd zet. Hij heet **what counts as having it** en heeft drie antwoorden.

*On their itinerary, however it got there* telt alles op de lijst, inclusief items die de gast zelf heeft toegevoegd of als favoriet heeft gemarkeerd. *Only if they purchased it* telt alleen items die via een inquiry gekocht zijn, en bestaat alleen voor experiences, omdat amenities en guidebooks niet verkocht worden. *Only if our team added it* telt items van je team en uit inquiries, maar niet die van de gast zelf.

**Voor een aanbieding wil je de tweede.** Een gast die in de gastomgeving op het hartje bij de boottocht tikt, zet hem op zijn reisschema zonder dat er op enig moment geld bij komt. Op de standaardinstelling valt die gast nu buiten de aanbieding om de boottocht daadwerkelijk te boeken, en dat is precies het omgekeerde van waarvoor je de regel maakte. De standaard is wél juist voor een instructie, waarbij je iedereen wilt bereiken die parkeren op zijn plan heeft staan, hoe het er ook op kwam. Hij is verkeerd voor alles wat je verkoopt.

## Tien regels, één per voorwaarde

In de volgorde waarin de regelkiezer ze toont, zodat dit ook als kaart werkt. Nummer acht is waar deze week over gaat; de andere negen zijn wat hetzelfde mechanisme verder doet zodra je het hebt.

**1. Date range, het winterwelkom.**

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

Een seizoensbericht dat nooit bij een gast mag komen die in mei aankomt. Het is goed te weten wat er aan het eind gebeurt: zodra elke actieve date range-regel op een template verlopen is, archiveert de template zichzelf. Voor een seizoenscampagne is dat meestal precies wat je wilt. Het is niet wat je wilt als je een date range met not between gebruikte om een bericht twee weken te pauzeren, want de template archiveert zichzelf de nacht dat die periode eindigt.

**2. Check-in status, het check-in-duwtje.**

> Check-in status · equals · Not Checked In

De herinnering die alleen bij de gasten mag komen die het nog niet gedaan hebben. De voorwaarde wordt getoetst op het moment dat het bericht zou versturen, en dat is hier het hele punt en ook de beperking: gepland drie dagen voor aankomst slaagt hij altijd, want niemand checkt drie dagen te vroeg in. Zet hem op een bericht dat op of na het check-in-moment staat, of hij doet niets.

**3. Stay date, het oudjaarsdiner.**

> Stay date · any in stay · 31 December 2026

Stay date vraagt of een datum ergens binnen het verblijf valt, en daarom is dit de juiste voorwaarde en niet een date range op de aankomst. Hij pakt de gast die op de 28e aankwam en de gast die op de 31e aankomt, zonder dat je aankomstdata moet opsommen. Het omgekeerde, none in stay, sluit een verblijf uit dat over een datum heen valt waarop iets gesloten is.

**4. Day of week, de aanbieding voor late checkout.**

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

Op zondag zit de ruimte in je wissel, dus op zondag kost een late checkout je het minst en verkoopt hij het best. De weekdag wordt gelezen in de eigen tijdzone van de accommodatie, dus een vertrek net na middernacht telt op de lokale kalenderdag en niet op een UTC-dag.

**5. User count, het duwtje om te registreren.**

> User count · equals · 0

Het bericht dat naar de boeking gaat die niemand nog heeft geopend. En de valkuil eronder, die een moment waard is omdat de naam misleidt: user count betekent gasten die zich voor de gastomgeving hebben geregistreerd of ervoor zijn uitgenodigd. Het is niet de groepsgrootte. Een reservering die voor vier personen geboekt is, telt als nul tot die gasten zich daadwerkelijk registreren, dus dit bereikt de stille boeking en niet de alleenreiziger.

**6. Guest group, het welkom voor de terugkerende gast.**

> Guest group · is in any of · Returning

Andere woorden voor de gast die er eerder was. De regel wordt getoetst aan elke gast die aan de reservering hangt en één match is genoeg, dus een gezin waarin alleen de boeker een terugkerende gast is, slaagt ook.

**7. Reservation source, volgende keer direct boeken.**

> Reservation source · came from none of · Direct

Bouw de OTA-kant als een uitsluiting van direct en niet door elke OTA aan te vinken waarmee je werkt. Vandaag zien die twee er identiek uit. Het verschil komt de eerste keer dat er een nieuwe boekingsbron aan het platform wordt toegevoegd: came from none of dekt die automatisch, terwijl een aangevinkte lijst die gasten stilletjes buitenlaat en niemand het een seizoen lang merkt. Let er ook op dat reserveringen die geïmporteerd zijn voordat de boekingsbron werd vastgelegd helemaal geen bron hebben, dus ze matchen nooit op came from any of en altijd op came from none of.

**8. On the itinerary, de ontbijtaanbieding.**

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

Waar deze week over gaat, en de kleinste nuttige regel in het systeem. Eén voorwaarde, en de gasten die ontbijt al gekocht hebben krijgen ontbijt niet meer verkocht. Zet die laatste regel, of hij klapt stil om: op de standaard telt een gast die ontbijt als favoriet markeerde als iemand die het heeft, dus degene die het meest waarschijnlijk koopt is degene die buiten de aanbieding valt. De omgekeerde richting is net zo nuttig en kan prima met de standaard, want de parkeercode hoort bij iedereen te komen die parkeren op zijn plan heeft, hoe het er ook op kwam.

Dit is ook de regel om te stapelen. Regel vier op zichzelf biedt late checkout aan bij elk zondagvertrek, inclusief degenen die het al gekocht hebben. Regel vier en regel acht op dezelfde template, gericht op je late checkout-experience, biedt hem aan bij de zondagvertrekken die hem nog niet hebben. Dat is de eerlijke versie, en het zijn twee voorwaarden in plaats van één slimmere.

**9. Length of stay, de huishoudelijke notitie halverwege.**

> Length of stay · greater than or equal to · 7

Niemand die twee nachten blijft heeft een notitie halverwege nodig. Iedereen die negen nachten blijft wel. Nachten worden geteld als kalendernachten in de tijdzone van de accommodatie, en gebruik je between, dan vallen beide grenzen erbinnen: between 2 and 4 pakt een verblijf van twee, drie of vier nachten.

**10. Guest sentiment, het verzoek om een review.**

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

Het verzoek om een review dat je liever niet stuurt naar een gast die een matige week heeft. Eén beperking bepaalt of dit zich gedraagt: een gast die je nooit een bericht heeft gestuurd telt als neutraal, en dat is 50%, dus deze regel neemt hem alsnog mee. Wil je alleen de gasten die actief positief zijn geweest, dan moet de grens boven 50 liggen en niet boven 40.

## Wat een regel niet kan vragen

Vier beperkingen, en elk ervan wordt anders ontdekt door de slimme versie te bouwen en te zien dat hij naar niemand gaat.

**Hij wijst naar items, niet naar dagen.** Dit is de belangrijkste en degene waar mensen zich het vaakst op verkijken. Je kunt vragen om een gast die de boottocht niet heeft. Je kunt niet vragen om een gast die op donderdag niets geboekt heeft. Er is geen voorwaarde die een dag van een verblijf leest en meldt dat hij leeg is. Elke reisschemaregel noemt een item uit je eigen aanbod, dus de versie hiervan die werkt is een benoemd aanbod dat een benoemde gast niet gekocht heeft.

**Eén soort per regel.** Een regel dekt Experience of Amenity of Guidebook of agenda-item, niet meerdere. Bestaat ontbijt in je aanbod als zowel een experience als een amenity, dan zijn dat twee regels, en omdat regels met AND combineren vraag je door ze beide toe te voegen om gasten die geen van de twee hebben. Twee templates met elk één regel, niet twee regels op één template.

**Geen OR.** Elke actieve voorwaarde moet slagen. Zomergasten of wintergasten zijn twee message templates. Er is geen manier om het als één te schrijven.

**Een regel kan niet worden aangepast nadat hij is toegevoegd.** Je zet hem uit of je verwijdert hem, en om er één te wijzigen voeg je de vervanger toe en haal je het origineel weg. Een detail, tot de eerste keer dat je een grens van vier naar drie wilt zetten.

Nog één die minder een beperking is dan een struikeldraad: zodra elke actieve date range-regel op een template verlopen is, archiveert de template zichzelf. Voor een seizoenscampagne is dat meestal wat je wilt. Het is niet wat je wilt als je een date range met not between gebruikte om een bericht twee weken te pauzeren en daarna vergat hem te verwijderen, want de template archiveert zichzelf de nacht dat die periode eindigt.

## De reservering verandert, de regel loopt opnieuw

Dit is het detail dat bepaalt of je hier iets van vertrouwt, dus het krijgt zijn eigen ruimte.

Gasten wijzigen hun plannen. Een reservering wordt op een dinsdagmiddag aangepast in je propertysysteem: de groep groeit met twee, er gaat een nacht af, iemand boekt de boottocht uiteindelijk telefonisch. Elke targetingregel die je maandag schreef beschrijft nu een gast die niet meer bestaat.

Regels worden getoetst op het moment van versturen, niet op het moment van inplannen. Die ene zin doet al het werk. Het bericht gaat gewoon in de wachtrij tegen de timing van de reservering, en dan, op het moment dat het de deur uit zou gaan, wordt elke actieve regel getoetst aan de reservering zoals die er op dat moment staat. Een verzending die niet meer van toepassing is, wordt overgeslagen. Een verzending die nu wel van toepassing is, gaat. Geen actie van je team, geen segment opnieuw draaien, geen verouderde lijst die in een wachtrij staat te wachten om je voor schut te zetten.

Je kunt het ook vooraf zien. De prognose op een reservering ververst zodra zijn data, check-in status, boekingsbron, reisschema of guest sentiment veranderen, en zodra je een regel toevoegt, uitzet of verwijdert. Open een reservering, ga naar de message templates, en een verzending die niet gaat slagen zegt dat ook: will be skipped due to condition rules not being met. Je vertrouwt dit niet op je blauwe ogen. Je kunt bij een specifieke boeking gaan kijken.

Dat is het verschil tussen een regel en een export. Een export is waar op het moment dat je hem trekt en vervalt vanaf dat moment. Een regel is een vraag die het systeem blijft stellen. Het betekent ook dat de uitsluitingsregel geldt op het enige moment waarop dat moet: de gast die de boottocht om 16:00 koopt, krijgt hem om 18:00 niet verkocht.

## Waarom upsell-software voor vakantieparken meer oplevert dan voor een hotel

Een stadshotel heeft een balie, een kort verblijf, en een gast van wie de avonden grotendeels elders al vergeven zijn. Drie nachten, waarvan twee met plannen die in de stad al gemaakt zijn. De balie pakt wat er overblijft.

Een park keert alle drie om. Verblijven duren een week of langer, en daarom bestaat regel negen. De uren zijn ongestructureerd, en dat is zowel het punt van de vakantie als de commerciële opening. En vaak is er één balie voor driehonderd units, of helemaal geen, en dat betekent dat een aanbod dat niet op het eigen scherm van de gast wordt gedaan, niet wordt gedaan. Hetzelfde geldt nog sterker voor upsell-software voor vakantiewoningen, waar de gast op een deurcode aankomt en elk commercieel moment na de boeking op een scherm gebeurt. OVO Network draait 250+ chalets op precies dat patroon.

## Wat dit niet doet

Gewoon hardop, want je komt er in de tweede week toch achter.

**Het systeem vindt het gat niet. Jij doet dat.** Het kijkt niet naar een verblijf, ziet niet dat donderdag leeg is en draagt daar geen aanbod voor aan. Er zit hier geen functie die de week van een gast leest en bepaalt wat er mist. Wat er wel is, is een regel die jij schrijft, gericht op een item dat jij kiest, die het systeem daarna toetst bij elke reservering en bij elke wijziging van een reservering, en waar het consequent naar handelt op een schaal die geen mens bijhoudt.

Dat onderscheid is de hele eerlijkheid van deze release. De intelligentie in de regel is van jou. De onze is de toetsing: onverbiddelijk, elke keer identiek, en kloppend nadat de gast van gedachten verandert.

**De AI schrijft het aanbod niet en prijst het niet.** De tekst is van jou. De prijs is van jou. De beschikbaarheid is van jou.

**Een regel kan niet worden aangepast nadat hij is toegevoegd.** Je kunt hem uitzetten of verwijderen, en om er één te wijzigen voeg je de vervanger toe en haal je het origineel weg. Een detail, en daar loop je tegenaan op de eerste dag dat je een grens van vier naar drie wilt zetten.

**Voorwaarden zijn alleen AND.** Elke actieve regel moet slagen. Alles wat een of-of nodig heeft, zijn twee message templates.

Het moment voorstellen, zodat de software de regel suggereert in plaats van te wachten tot jij hem schrijft, is waar dit naartoe gaat. Het is niet gebouwd, en we vertellen je dat liever dan dat we een demo laten suggereren dat het anders is.

## De aanbevelingen zijn nog steeds niet te koop

Eén ding dat we meenemen uit vorige week, en dat met meer kracht geldt zodra er geld bij komt. De lokale aanbevelingen naast het reisschema zijn degene die jij hebt gekozen. Niets in het aanbod rangschikt ze, niemand koopt plaatsing, en geen derde partij komt op het scherm van jouw gast door het meest te betalen. Dat is eerst een commercieel argument en daarna een principieel argument: een lijst die te koop is draagt geen informatie in zijn volgorde, en een gast die naar een tegenvallende plek is gestuurd geeft de accommodatie de schuld en niet het platform.

## De gast zegt ja

Een blast stelt een vraag aan iedereen. Een regel stelt hem aan de gasten voor wie hij waar is, en stopt met vragen op het moment dat hij niet meer waar is.

Begin met regel acht. Verkoop geen ontbijt aan de gast die ontbijt gekocht heeft. Het is één voorwaarde en één instelling, het kost ongeveer een minuut, en het is de regel die zich de eerste ochtend dat hij loopt terugbetaalt in goodwill. Schrijf daarna het omgekeerde, de instructie die alleen bij de gasten komt voor wie hij geldt, en je hebt de vorm van elke andere regel in het systeem. Meer van dit argument staat op [effortless revenue](/effortless-revenue).

Dan tikt de gast op ja, en begint een andere reeks vragen: wie krijgt het te horen, wie bereidt het voor, en hoe bereikt een bestelling de leverancier die hem echt uitvoert. Routing staat live in preview. Dat is volgende week.

Elke voorwaarde, met zijn operatoren, zijn velden en de valkuilen erin, staat uitgeschreven in [de handleiding over conditional rules](https://support.holidayhero.com/the-basics/communication/conditional-rules). De handleiding is in het Engels.

HolidayHero draait op het propertysysteem dat je al hebt, bij 3.500+ accommodaties, in 100+ talen. De prijzen zijn gepubliceerd, vanaf €6,50 per unit per maand zonder opstartkosten.