How to Automate Guest Messages Without Making Them Feel Automated

Take a Friday with nine check-ins across five properties. Each guest needs check-in codes, parking notes, and the WiFi password before they arrive. One property has a pool. One has a trash pickup at 8 AM Saturday that guests need to know about. Another has a detached garage with its own entry code.

Writing nine distinct messages from scratch is two hours of work, minimum. Copying a template and forgetting to swap the parking info is a support call at 10 PM. Neither is a good use of time at scale.

Scheduled guest messaging is the fix. But it only works if the timing lands correctly, the messages are personalized enough to read like someone wrote them, and the system knows when to hold back rather than fire anyway.

Which messages are worth scheduling

Not everything should run on autopilot. Automation handles high-frequency, low-judgment touchpoints well: the same information every guest at that property needs, delivered at the same point in their stay.

A message sent two to three days before arrival should cover everything a guest needs to show up without a phone call: address, access code, parking, WiFi. Some operators include a link to the guest portal here. Others hold the portal link for check-in day and use the pre-arrival message strictly for logistics. Both work. The point is consistency across your portfolio, not optimization for a single property.

On check-in day, a short reminder in the morning reinforces the critical details without repeating the full pre-arrival message. Check-in time, how to reach someone if something's wrong, any quirk specific to that property. Keep it short. The guest is packing.

One to two days into the stay, a brief check-in asking if everything looks good. This one earns its keep in two ways. It catches problems while there's still time to fix them. And guests who feel like someone is paying attention are more likely to reach out before a small issue turns into a dispute, and more likely to leave a review. The mid-stay message costs almost nothing and has an outsized effect on how the stay is remembered.

Before checkout, the night before or morning of departure, send procedures and the checkout time. If your property has specific requirements, stripping the linens, taking trash out, locking a back gate, this is where to put them. Guests who get this message leave on time. Guests who don't sometimes don't.

Timing is harder than it looks

The single most common failure in automated messaging: a message arriving at the wrong time. Not dramatically wrong. Just wrong enough to feel off.

"Send three days before check-in at 10 AM" needs to mean 10 AM at the property's location, not your time zone, and not UTC. A message landing at 3 AM because the server is in Eastern time and the property is in Hawaii is not a good start.

The subtler version of this problem: automation anchored to a calendar date rather than the actual event. "Three days before check-in" should compute as 72 hours before the check-in timestamp, not "the date that is three calendar days earlier." The difference is whether the message goes out at a predictable, consistent offset from arrival, or at some arbitrary time on the prior date depending on when the cron job runs.

Getting this right requires timezone-aware offset math, not a date subtraction. If you're running properties across time zones, verify when a scheduled message will actually fire before trusting it with guests. Most PMS platforms treat this as an afterthought.

Variables are what make it feel personal

The difference between "Hi Guest" and "Hi Marcus" is not subtle, and it's not the only variable that matters. A message that says "check-in at Coconut Cove is from 4 PM, code is 7732" reads differently than "check-in is from 4 PM and the code is on the door."

The set of variables worth using covers the guest's first name, property name, check-in and check-out dates, door code, WiFi credentials, parking instructions, and a link to the guest portal if you have one. That's enough to make a templated message feel like it was pulled from a specific reservation. A guest can't tell it wasn't.

Where operators go wrong: either they over-personalize, adding variable fields that some properties have and others don't, which creates blank-field failures in the messages for properties where those fields aren't filled in. Or they under-personalize, putting the guest's name in the greeting and then reverting to generic language for everything else. One personalized field doesn't carry the whole message.

Custom variables help for anything that doesn't fit a standard field. Seasonal door codes, a note about the shared driveway, a local restaurant recommendation the owner wants every guest to see. Store it at the property level, reference it in the template, and the right text shows up for each reservation without any manual intervention.

When the system should stay quiet

If a guest has already messaged you asking about check-in procedures, sending your scheduled "here's how to check in" message two days later is redundant and reveals the automation. The guest asked a question, you (presumably) answered it, and now a form letter is arriving as if the conversation didn't happen.

The better behavior: if a guest has sent an inbound message in the thread, the system checks whether the scheduled message is still appropriate. For a pre-arrival informational message, it often isn't. The guest has been in contact. They've likely gotten what they needed. A redundant send signals the system isn't aware of the relationship.

Some platforms let you configure a skip rule: if the guest has replied since booking, hold scheduled messages of a particular type. Others let you cancel pending messages from within an active thread. Either approach is better than firing unconditionally.

Channel matters too. A message that works well for a direct-booking guest may be wrong for an Airbnb guest, where OTA messaging norms and the platform's own automation create different expectations. If you're running multiple channels, configure templates per channel rather than using the same message everywhere.

Auto-send vs. draft for review

For most operators running fewer than ten properties, the right starting point is not full automation. Route scheduled messages to a review queue first. The system drafts the message and fills in all the variables, and a human approves it before it sends. That catches edge cases: a guest who mentioned a specific arrival plan in their booking message, a property where something broke yesterday, a reservation with non-standard details.

As you validate that a particular message type is consistently right, flip it to auto-send. The high-confidence candidates are usually the mid-stay check-in and the checkout reminder. Pre-arrival messages tend to stay in review longer because the stakes are higher if the information is wrong or missing. One bad pre-arrival message is a support call, sometimes a bad review.

The review queue approach also lets you phase in automation without committing to it all at once. You can validate the drafts against your actual reservations before trusting them to send on their own.

The operational case

At ten properties with steady occupancy, manually sending every guest message runs two to three hours a day. Templates help, but templates still require someone to open a thread, select the right message, verify the details, and hit send. At twenty properties, that stops being manageable for one person.

Scheduled messaging doesn't remove judgment from the process. It reserves judgment for the moments that require it: the guest who mentions they're bringing an elderly parent and need accessible access, the mid-stay message that reveals a broken appliance, the checkout note that turns into a rebooking conversation. Those interactions benefit from a real person paying attention.

The routine messages, the ones that are the same every time and that every guest needs, can run without you. Guests don't experience them as automated. They experience them as attentive.

If you're building this out, Pomello's guest messaging tools support per-property variable substitution, event-anchored scheduling with timezone-aware timing, skip rules for active threads, and a review queue for messages you want human eyes on before they send. The companion post on what happens when a guest message goes unanswered covers the triage side, if volume is the piece you're working on.