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 guest finishes booking on your booking engine at 11:40pm. Nobody on your team is awake to send a confirmation, and nobody needs to be. Within a minute, a WhatsApp message lands on their phone with the dates, the room type, and a link to the reservation. Two days before arrival, a second message arrives with directions to reception, parking, and what time the pool opens. The morning after checkout, a third asks how the stay went and links to a review. None of these required a person to notice the guest existed, decide what to say, or click send.
That's the part of WhatsApp on GuestMaker the rest of this blog hasn't covered yet. What a WhatsApp bot for hotels actually does goes deep on what happens when a guest messages first, how the AI reads your knowledge base, replies in whatever language the guest is writing in, and knows who it's talking to, alongside a companion post on why a hotel chatbot can fail to recognize its own guest. If that's the question on your mind, start there. This post covers the opposite direction: what goes out on WhatsApp before a guest types anything, running on its own, day and night, without anyone on your team watching it happen.
The building block for this is called a journey: a visual workflow you design once in GuestMaker's journey builder, made of triggers and steps. A trigger can be a real guest event like a new booking, a date tied to a reservation such as an upcoming check-in or a recent checkout, or a schedule that isn't tied to any single guest at all. A step can be a WhatsApp template message, an email, a delay, a conditional branch that sends different guests down different paths, or one of several other actions.
You build the journey once. After that, it runs itself. A guest books a room and the confirmation goes out without anyone touching a keyboard. The same mechanism sends the pre-arrival message with practical logistics, the check-in reminder a day or two out, and the post-stay follow-up asking for a review, all triggered by the guest's own booking and stay dates rather than by someone remembering to check a spreadsheet. When a property runs this well, the guest experience is consistent for every guest, not just the ones who happened to arrive on a day the front desk wasn't slammed.
You don't have to design every one of these from a blank canvas either. GuestMaker ships with a library of ready-made journey templates covering the scenarios most hotel groups actually need: booking confirmation, pre-arrival guidance, check-in reminders, post-stay follow-up, and others, each available as an email-only version, a WhatsApp-only version, or a combined one. You pick the shape that fits how your guests actually communicate and adjust it from there, rather than starting from nothing.
Journeys handle the guest's own booking. Broadcasts handle everyone else: a seasonal offer, a property announcement, a message to a segment of guests who haven't stayed in a while. You build the segment in GuestMaker's CRM, pick the WhatsApp template, and send.
Because it's WhatsApp, the sending side is more accountable than most channels. Every broadcast uses an approved template, and delivery status comes back from Meta's own webhooks: sent, delivered, read, failed, per recipient, not an estimate. Any link inside the message carries click tracking, so you can see whether a guest who received an offer actually tapped through to look at it. And a Do Not Disturb service checks the guest's own time zone before sending, so a broadcast built for a Tuesday afternoon doesn't land on a guest's phone at 2am in their own time zone.
The mechanics under a broadcast and a journey step are the same system, which matters more than it sounds. A WhatsApp template button isn't a static link either way: it can carry a real deep link built from the actual guest's own reservation and merge tag data. An online check-in link inside a pre-arrival message opens pre-filled to that specific guest's stay, not a generic check-in page they have to hunt their own booking down on. That works identically whether the message is a one-off broadcast to a segment or a step inside a journey firing automatically off a reservation date. Build the link logic once and it works everywhere the template gets used.
None of this happens by chance. The templates themselves have to clear Meta's own approval process before they can be sent at all, which is its own thing worth understanding if you've ever had a WhatsApp template rejected or stuck in review. The WhatsApp template that gets approved the first time covers what's underneath that, separately from this post.
Automation you don't have to babysit is only useful if it's also automation you can trust not to embarrass you. GuestMaker runs a similar kind of quiet, unwatched logic elsewhere in the platform. The discount that never reaches a guest who already booked is the same idea from the other direction, a guardrail that runs in the background checking something so a human doesn't have to catch it after the fact. Journeys and broadcasts are the automation that sends; that post is the automation that stops something from sending wrong. Both run without anyone standing over them.
Everything above is one-directional: GuestMaker to guest, triggered by an event, a date, or a segment. But it's the same WhatsApp conversation a guest can reply to at any point, and that reply gets a real answer, in whatever language the guest wrote in, from an AI that knows which reservation it's talking about. When a guest asks about availability or pricing directly inside that conversation, rather than through your booking engine, the AI checks live availability and sends up to three real room options as image messages, cheapest first, each with a photo, an actual price, and a link straight to that room on your own booking engine. It's on by default, a hotel can turn it off, but nobody has to turn it on, and it isn't a mockup or a generic "book now" nudge. It's live inventory, answering in the same channel a check-in reminder just came from a day earlier.
If something in that conversation needs a person, an actual staff member and not another automated reply, it routes through GuestMaker's escalation system to your team rather than dead-ending on a guest who's stuck. That side of the platform, how the AI understands a guest's message and when it hands off, is already covered in depth elsewhere on this blog, in the post on what a WhatsApp bot for hotels actually does.
The value of a journey isn't really the individual message, it's that you stop being the reason it didn't go out. A booking confirmation that depends on someone remembering to send it will eventually not get sent, on the one night the front desk is short-staffed or the one Sunday nobody's checking a shared inbox. A journey built once keeps running on the nights nobody's watching, at a volume no single person could keep up with by hand, for as long as the trigger keeps firing. That's the difference between a WhatsApp bot that answers questions and a WhatsApp channel that runs your guest communication for you. Most hotel groups need both. This post was about the half that doesn't wait to be asked.
Thirty minutes, your real properties, no generic demo environment.
How GuestMaker checks and scores WhatsApp template drafts before submission, follows Meta's review status, and helps hotel teams prepare templates for review.
Most hotel teams picture a WhatsApp bot as a stiff decision tree. Here is what actually answers a guest at 11pm, and where a real person still steps in.
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.
