A guest who already booked at full price should never see a discount email for the same dates. Here's the guardrail that protects it, simply explained.
A guest books a week at your resort in July and pays the full published rate. She feels good about it, the way people do when they book directly and skip the third-party markup. Four days later, your own marketing team sends a campaign advertising twenty percent off those exact same dates. She does the maths. She cancels the reservation she already confirmed, rebooks at the lower price, and the hotel has just paid to give away margin it already had in hand.
That scenario is easy to imagine because it happens constantly, in every industry that runs email promotions against a live inventory of commitments. It happens because the team building the campaign and the reservations already on the books live in two different parts of a hotel's operation. Marketing works from a contact list, built on consent and engagement. Reservations sit in a completely separate system, updated by the booking engine, the front desk, sometimes a PMS sync running on its own schedule. Nobody sits down before every send and manually checks a list of ten thousand contacts against who currently holds a confirmed stay. So the two never meet until a guest notices the gap herself, and the notice she leaves is a cancellation.
GuestMaker closes that gap at the moment a campaign actually sends, not before. When a hotel group builds a discount campaign, whether it started from scratch or came in as an old campaign forwarded from another platform, it can switch on booking protection, and every recipient is checked against their own live reservation record before a single email goes out. A guest who already holds a confirmed, upcoming reservation for that hotel simply never lands on the send list for that campaign. Nobody exports a spreadsheet the night before. Nobody remembers to cross-reference anything by hand. The check runs automatically, against the same reservation data the front desk is looking at right now, every time a campaign dispatches. The same principle runs on the WhatsApp side, where journeys that send booking confirmations on their own work without anyone at the hotel pressing send, one automation making sure the right message goes out, this one making sure the wrong one doesn't.
It's a narrow piece of protection on purpose. It isn't trying to predict who might be tempted, or score intent, or guess at loyalty. It answers one concrete question for each recipient: does this person have something left to lose by seeing this offer? If yes, they're held back from that send. If no, the campaign reaches them exactly like anyone else on the list.
The scope here is deliberate, and it's worth being specific about it because the obvious version of this feature would overreach. Only guests with an active reservation still ahead of them get excluded.
A guest who has already checked in is not held back from the campaign, because there's nothing left for her to cancel. The stay is happening. A guest who has already checked out isn't held back either, for the same reason in reverse: the room has been turned over, the folio is closed, and refusing to market to her protects nothing while quietly shrinking the pool of past guests a hotel group actually wants to win back. Both of those guests go straight back into the ordinary contact pool, eligible for whatever campaign fits them, the moment their stay moves out of the "still upcoming" window.
The guardrail only earns its place while there's still a decision on the table that costs the hotel money: cancel the booking, rebook at the lower price. Once check-in happens, that decision is gone, so the exclusion goes with it.
Not every hotel group wants to protect the same slice of its book, so this isn't a single switch. There are three ways to configure it inside the campaign builder, and each one answers a different business question a revenue or marketing lead might actually ask.
Protect every upcoming booking. The strictest setting. Anyone holding an active, future reservation is excluded from the campaign, no matter how far off the stay is or how small the booking. This is the right default for a group that would rather under-send a promotion than risk a single guest seeing an offer for dates they've already paid for.
Protect only the guests arriving soon. Instead of excluding every future booking, a hotel can set a window, protect anyone arriving in the next thirty days, for example, and leave bookings further out untouched. The logic is about attention rather than fairness. A guest whose stay is eight months away isn't sitting in her inbox comparing today's flash sale to a booking she made back in January. A guest arriving next week is exactly that person, checking her confirmation email, still weighing whether she got a good deal. Narrowing the protection window focuses it on the moment a cancel-and-rebook is genuinely plausible, while letting a campaign still reach the wider base of guests whose stays sit comfortably in the future.
Protect a specific date range. Instead of a rolling window, a hotel can pick two exact calendar dates and exclude anyone checking in between them, useful for a campaign built around a particular event or season where the risk is concentrated in a known stretch of the calendar rather than spread evenly across every future booking.
All three sit on the same screen inside the campaign builder, alongside the segment a hotel is already targeting and the one-click translation step for every market. Switching between them is a different choice on the same screen, not a different workflow to learn.
It would be easy to imagine a more elaborate version of this feature: something that scores cancellation risk, weighs loyalty tier, adjusts by channel or by how many times a guest has opened a previous email. None of that is what makes this useful. What makes it useful is that it reliably does one obvious thing, correctly, every time, without a person having to remember to check.
The reservation data this guardrail reads is the same live record the front desk and revenue team already work from, not a marketing-side copy that quietly drifts out of date between syncs. It's the same record that lets a hotel follow a click through to a confirmed booking instead of just counting it as one. That's what makes it safe to leave switched on by default: the check at send time reflects what's true right now, not a snapshot pulled last week.
For a hotel group running promotional campaigns regularly, that difference is the whole point. It's the difference between a discount tool that occasionally embarrasses the brand and one that quietly does its job without anyone thinking about it. The guest who booked in good faith at full price never has to wonder whether the hotel's own marketing forgot she existed. She simply never sees the offer that would have made her regret booking direct, and the group keeps the margin it earned the first time she paid it.
Thirty minutes, your real properties, no generic demo environment.
A guest gets a booking confirmation on WhatsApp at midnight, a check-in reminder two days out, and a review request the morning they leave, and nobody on the hotel team sent any of them by hand. Here's what actually runs behind that.
A click is not proof of a booking. Here is how GuestMaker follows a guest to a confirmed reservation on the hotel's own booking engine, and admits when tracking fails.
One AI action turns an approved campaign into a full language family, protecting guest names, booking links, and phone numbers in every language version.
