A guest books on Thursday for a stay starting Monday. On Sunday evening your system sends the pre-arrival message: door code, parking, what time the cleaner finishes. The send is logged. The dashboard shows it green.
On Monday at 22:10 the guest is standing on the street messaging the Airbnb thread, because they never received a door code. You scroll back through WhatsApp and the message is there on your side, with one grey tick and no delivery.
Nothing broke. The message was refused by a rule that was working exactly as designed, and nobody told you, because the rule exists between your software and Meta's and the guest has no idea it is there at all.
The Mechanic: A Window the Guest Opens
WhatsApp treats a business differently from a person. A person can message anyone in their contacts at any time. A business messaging through the WhatsApp Business Platform cannot.
The rule, in its general shape: a business may send free-form messages to a user only inside a service window that the user themselves opened by sending an inbound message. Inside the window, you send whatever you like: plain text, a photo of the lockbox, a voice note reply. Outside it, free-form messages are not delivered. Only a pre-approved message template goes through, and a template is a piece of content submitted to Meta in advance, reviewed, categorised, and sent with variables filled in.
Each new inbound message from the guest restarts the window. A guest who replies every day keeps it permanently open. A guest who books and never types a word has never opened one at all, which means every message you have ever "sent" that guest was either a template or nothing.
This window is commonly documented as twenty-four hours from the guest's last inbound message, which is why the whole thing is usually called the 24-hour window. Treat that number, the template categories, the approval rules and anything about pricing as current policy rather than physics: they are Meta's, they have changed more than once, and the only reliable source is the current WhatsApp Business Platform documentation. Check it before you design anything expensive around a specific duration. The mechanic (inbound opens, free-form inside, template outside) has been the stable part.
Who This Actually Applies To
The distinction that causes most of the confusion is between the two different WhatsApp products a host might be using.
If you are typing messages by hand in the WhatsApp Business app on a phone, you are in a different regime. Hosts working this way generally do not run into the window as a hard delivery rule, though there are separate limits and there is nothing stopping a recipient reporting or blocking a business that messages them unprompted.
If you are sending through the WhatsApp Business Platform (the API, whether you built on it directly or your guest-messaging tool did), the window is the governing rule for every outbound message your system generates. Most hosts arrive here without noticing, because the tool they bought sits on the Platform and never explains why. The trade-offs between the two are the subject of the app-versus-Platform decision for hosts, and the window is the single biggest operational difference between them.
One practical consequence: if you are evaluating tools, ask which of the two they sit on, what happens to a send outside the window, and whether they show you the delivery status or only the send status. Those three questions belong in any serious evaluation of a WhatsApp automation tool.
The Four Failures Hosts Actually Hit
The pre-arrival message that silently fails. This is the expensive one. The guest booked on an OTA, never messaged you directly, and your automation fires the check-in instructions forty-eight hours before arrival. There is no open window, the message is free-form, and it does not arrive. The guest turns up at the door with nothing.
The operational note that never lands. "Your cleaner is on the way", "we need to swap the mattress this afternoon", "the water will be off between 10:00 and 12:00". These are sent hours or days after the guest last typed anything, which is exactly when the window is closed. They are also the messages whose failure you find out about in person, when the cleaner knocks and the guest is in a towel.
The send that looks successful and fails afterwards. Messaging APIs generally accept a message for delivery and report the real outcome later, on a separate status callback. So a send can return success, appear in your log as sent, and be marked failed or undelivered a moment later by a webhook your dashboard may or may not surface. If the tool you are using only shows the first event, every window failure in your account is invisible to you. This is the failure that convinces hosts the whole channel is unreliable.
The escalation at 01:00. A neighbour reports noise. You send the guest a message and it does not arrive, because the guest last typed at check-in three days ago. The one message in the entire stay that needed to land in sixty seconds is the one the window blocks. That is a specific argument for having a phone number and an escalation path that does not depend on WhatsApp at all, which is part of handling a noise complaint before it becomes a licensing problem.
Which Messages Have to Be Templates
Sort your messages by who spoke last, not by how important they feel. The question is never "is this urgent?" It is "did the guest message me recently?"
| Message | Who initiates | Window status at send time | What it has to be |
|---|---|---|---|
| Booking confirmation and welcome | You | Almost always closed | Template |
| Pre-arrival check-in instructions | You | Usually closed | Template |
| Day-of-arrival door code | You | Closed unless the guest replied | Template |
| Answer to a guest question | Guest | Open | Free-form |
| Follow-up in a live conversation | Either | Open | Free-form |
| Cleaner or maintenance ETA | You | Usually closed | Template |
| Mid-stay check-in, upsell, offer | You | Usually closed | Template, and a marketing-category one |
| Checkout reminder | You | Usually closed | Template |
| Review request after checkout | You | Closed | Template |
| Incident or emergency notification | You | Unpredictable | Template, plus a non-WhatsApp fallback |
The right number of templates is small. Most hosts need somewhere between six and twelve covering the whole reservation lifecycle, each written once and reused with variables for name, property, date and code. Writing them is a craft of its own: what a template can contain, how variables behave, and why the wording that passes review is not the wording you would type by hand, and it is covered in how to write WhatsApp message templates for a rental operation.
Note the mid-stay row. A message that promotes something (late checkout for a fee, a partner restaurant, a returning-guest discount) is generally treated as a different category from an operational notice, with different rules and different costs. Do not assume an approved utility template can carry an offer inside it.
Getting the Guest to Open the Window
Every design that works does the same thing: it makes the guest send one message early, as close to booking as possible, and then keeps a reason to reply alive through the stay.
- Put a click-to-chat link where the guest already is. In the OTA thread, in the booking confirmation email, on the printed card in the property, as a QR code by the door. A link that opens WhatsApp with a pre-filled first message costs the guest one tap and opens the window from their side.
- Make the first template ask a question. A template that ends in a statement gets read. A template that ends in "what time do you expect to arrive?" gets a reply, and the reply is what unlocks everything you want to send afterwards. Quick-reply buttons, where your template type supports them, lower that cost further. Check the current documentation for which template types carry buttons and how a button tap is counted.
- Time the opener so the window is open when it matters. An opener sent at booking does nothing for an arrival six weeks later. Send something that earns a reply in the day or two before arrival, so the window is open across check-in, which is when unplanned messages actually happen.
- Treat every inbound as a scheduling event. When a guest replies, that is the moment your queued free-form messages should flush. If your system does not know the window state, it cannot do this, and it will keep sending into a closed window.
- Never depend on it for the one message that must arrive. Emergency and access-failure paths need a phone call or an SMS behind them. A channel that can be closed by the guest's silence is not a safety system.
What to Queue, What to Escalate, What to Drop
Once you can see the window state, outbound messages sort into three buckets, and the sorting is a policy decision rather than a technical one.
Queue it. Anything that is useful but not time-critical: the restaurant suggestion, the mid-stay "everything alright?", the note about the market on Saturday. Hold these until the guest opens a window, then send them as free-form. A queued message costs nothing; a template for it costs money and a review cycle.
Template it. Anything that has to arrive on a schedule regardless of guest behaviour: pre-arrival instructions, the door code, checkout, the review request. These are worth the approval effort precisely because you cannot control whether the window is open when they fire.
Escalate it off-channel. Anything where a failure costs you the night: the guest who cannot get in, the leak, the noise call, the notification that someone is coming into the property in twenty minutes. These need a template and a fallback: a call, an SMS, a knock.
Drop it. If a message is not worth a template and the window never opens, it is not worth a workaround. Hosts who build elaborate machinery to force delivery of a mid-stay upsell are spending engineering on a message the guest did not ask for.
The broader pattern, matching each message to the right mechanism and the right moment, is the subject of the guide to WhatsApp guest communication, of which the window is the least visible and most punishing part.
Honest Limits
Templates get rejected, and the reason is often thin. A template can be refused for wording, for category mismatch, for a variable at the start or end of the body, for reasons you will infer rather than be told. Plan for revision cycles rather than a single submission.
Approval takes time you will not have in an incident. Review is not instant, and you cannot write a new template at 01:00 because something unusual happened. Whatever you might need to say in an emergency has to exist as an approved template before the emergency, or it does not exist.
The window state is not always knowable to you. If your tool does not expose when each conversation's window opened and closed, you are guessing. Ask for that view specifically; a send log is not the same thing.
None of this is visible to the guest, and none of it is their problem. They do not know a window exists. From their side, a host who is silent is a host who is ignoring them, and any explanation you offer sounds like an excuse. This is pure operator tax: work you do so that nothing appears to happen.
The numbers in this article will drift. The duration, the template categories, the pricing model and the rate limits are Meta's to change, and they have. Read this page for the mechanic and the design pattern; read the current WhatsApp Business Platform documentation for the rules that will actually be applied to your account this month.
No tool exempts you from it. Welco runs on WhatsApp and is bound by exactly the same window as anything else on the Platform. What a tool can do is make the window visible, hold queued messages until a guest replies, and stop you from believing a message arrived when it did not. What no tool can do is deliver a free-form message into a closed window, and any vendor implying otherwise is describing something that is not theirs to grant.
The Operational Picture
The window is not a bug to route around; it is the shape of the channel. Design for it by keeping a small set of approved templates for everything you initiate, engineering one early reply from the guest so free-form conversation is available when it matters, queueing the rest, and keeping a phone number behind the messages that cannot fail.
Welco is a WhatsApp AI assistant for vacation rental hosts. Guests message from their own WhatsApp, replies go only to verified guests, and reservations sync by iCal without a PMS, but the customer service window applies to it as it does to everything else, and the honest version of the pitch is that it manages the window rather than removing it. If you want to see how that behaves against your own reservation flow, access is by demo request.