Every vacation rental tool sold in 2026 claims the same thing: "AI that answers your guests automatically." It's the headline feature, the demo that wows, the reason hosts sign up.
We built that AI. It reads every incoming guest message, understands where the guest is in their trip, and writes a reply that sounds like our team wrote it. And then we made a decision that sounds backwards: we never let it press send.
This isn't a limitation we're apologizing for. It's the most important design choice in the whole system. Here's why โ and here's exactly how the pipeline works, including the prompt rules we learned the hard way after letting an AI read more than 2,800 real guest and host messages, in two languages.
By the numbers (our own properties). Out of 1,416 real guest messages, our classifier drafted a host-ready reply for about 84% and deliberately stayed silent on the other 16% โ the "thanks!", "๐", and "perfecto" that need no response. By design, a human approved every message that ever reached a guest. Not one was auto-sent.
The problem with "fully automated" guest replies
A short-term rental message thread looks simple from the outside. A guest asks "what time is check-in?" and the bot answers "3 PM." Easy.
But real threads aren't that. Real threads are: a guest who booked for six adults messaging to ask if fifteen people can come. A guest asking you to "leave a surprise note in the room for my wife's birthday." A guest who says "we'll just take an Uber" โ and a different guest who says "can you still arrange that airport transfer?" Same keywords, opposite meaning, opposite correct response.
When you let an AI auto-send replies to messages like these, three things go wrong:
- It over-promises. AI models are trained to be helpful, so they say yes. "I'll personally make sure there's a note in the room!" Now you, the host, are on the hook for a promise you never made and may not be able to keep.
- It invents details. Ask an unconstrained model for a price or a policy it doesn't have, and it will confidently make one up. In hospitality, a wrong check-out time or a hallucinated fee is a one-star review waiting to happen.
- It upsells at the worst moments. A guest writes "we need extra towels" and the bot replies "Sure! Want to add airport transportation too?" Nothing erodes trust faster than a sales pitch when someone just wanted a towel.
The industry's answer to this has been "better prompts" and "more automation." Our answer was different: keep a human in the loop, but make that human's job take ten seconds instead of ten minutes.
How the pipeline actually works
When a guest message arrives, it doesn't go straight to a reply. It moves through a short assembly line, and a human approves the final step.
Guest message arrives
โ
โผ
[1] Should we even reply? โโ SKIP โโโถ mark reviewed, notify host, done
โ TRIGGER
โผ
[2] What's the booking stage? (pre-arrival / arrival day / during stay / checkout)
โ
โผ
[3] Generate a SUGGESTED reply, using only verified property facts
โ
โผ
[4] Detect intent (is the guest actually asking to book a paid add-on?)
โ
โผ
[5] Push suggestion to the host to approve, edit, or ignore
Two of these steps are the secret sauce, and neither is the part everyone advertises.
Step 1: Decide whether a reply is even needed
Before we spend a single token writing a response, a lightweight classifier reads the message and decides: does this actually need a reply, or is it a conversational dead end?
If a guest writes "perfect, thank you!" or just "๐" or "gracias" โ that's a closing, not a question. Waking the host up to approve a reply to "thanks!" is exactly the kind of noise that makes hosts turn automation off. So those get marked reviewed and skipped.
But โ and this is the part we tuned carefully โ the classifier is biased toward replying when unsure. A message like "we've arrived and we're inside!" isn't a question, but a good host acknowledges it and offers help. A goodbye message deserves a warm send-off. The rule we landed on: skip only a very short standalone acknowledgement with no new information; when in doubt, trigger. Missing a real question is far more expensive than surfacing one extra suggestion.
In practice, that bias plays out exactly as designed. Across our 1,416 real guest messages, the classifier chose to stay silent on 16% โ roughly one in six โ and surfaced a draft for the rest. That one-in-six is pure noise removed: every "thanks!" it absorbs is a phone notification the host never has to see, which is the difference between automation a host actually leaves on and one they switch off in a week.
Step 2: Know where the guest is in their trip
The same question has different right answers depending on timing. "How do I get from the airport?" three weeks before arrival is a planning question โ here are your options, here's the price. The same question while the guest is already checked in and standing in the lobby is a logistics question โ and pushing a payment link at that moment is tone-deaf.
So before generating anything, the system tags the message with a booking stage โ pre-arrival, arrival day, during stay, or checkout day โ and uses a different set of instructions for each. The clearest example: the pre-arrival assistant is allowed to surface a payment link for a paid add-on (an airport transfer, an early check-in, a mid-stay clean) only when the guest signals they want to book it. The during-stay assistant doesn't surface payment links at all. Same property, same guest, same question โ different correct behavior, decided by context rather than keywords.
Step 5: The human gate
Here's the step that makes the whole thing safe. The AI's output is saved as a suggested response and marked for review โ it is never delivered to the guest. Instead, the suggestion is pushed to the host over WhatsApp. The host reads it, and with one tap either approves it as-is, tweaks it, or writes their own.
The result is the speed of automation with the accountability of a human. The host answers in seconds because 90% of the wording is already done. But a person โ not a model โ is the one who decides what the guest actually receives. No promise gets made, no price gets quoted, and no upsell gets sent without a human signing off.
Four personas, two prompts
It helps to picture the assistant as a small cast of specialists, each with a different job depending on where the guest is in their trip:
- The Welcomer handles the pre-arrival stretch โ excitement, logistics, what to expect.
- The Concierge takes over during the stay โ local recommendations, the WiFi that dropped, the extra towel.
- The Send-off runs checkout day โ departure steps, last-minute problems, a gentle nudge toward a review.
- The Salesperson appears only when a guest asks to book a paid add-on โ and is forbidden from speaking first.
That's a useful way to think about the assistant. It is not how we ended up building it.
In practice, we found it far easier to maintain two prompts than four. The guardrails that actually matter โ never impersonate the host, never invent a price, never upsell unprompted โ are identical across all four personas. Split them into four files and they drift: the day you tighten one rule, you have to remember to tighten it in four places. Keep them in one place and a fix lands everywhere at once.
So we collapsed the cast down to two: one prompt for the pre-arrival phase, and one for everything from check-in onward. The booking stage is already passed in as context, so a single "during-stay" prompt behaves like the Concierge or the Send-off just by reading where the guest is โ no separate file required. And the Salesperson was never really an agent at all; it's a single rule โ surface a paid add-on only when the guest asks โ gated by the intent classifier and living inside both prompts.
The personas survive as a mental model: a fast way to reason about how the assistant should behave at each moment. The deployment is deliberately simpler than the metaphor. That gap โ between the model in your head and the code you maintain โ is worth being honest about. Four distinct voices sound impressive in a pitch, but two prompts with shared guardrails are what you can actually keep correct at 2 a.m., when a guest is messaging and the host is asleep.
The guardrails: everything an AI should never say to a guest
The reason a human can approve a reply in ten seconds is that the suggestion is usually already correct. Getting there took a long list of hard rules โ each one written after watching an AI get something subtly, expensively wrong. These are the constraints baked into our prompts:
It never pretends to be the host. The assistant is explicitly told it is helping the host, not being the host. It can't say "I'll personally set that up" or imply it's physically at the property. When a guest addresses it by the host's name, it answers naturally without role-playing as that person. Instead of impersonation, it defers: "the host will confirm."
It never promises future actions. Phrases like "I'll send youโฆ", "we'll arrangeโฆ", or in Spanish "me asegurarรฉ de queโฆ" are banned outright. An AI can't commit a human to do something later. So it describes the process neutrally instead โ "transportation can be booked in advance through the host" โ rather than making a commitment nobody authorized.
It never confirms a custom request. Decorations, surprises, special setups, a birthday note โ anything not already documented for the property gets warm acknowledgement but never a yes. "That sounds lovely โ the host can confirm if that's possible." The model is not allowed to invent a capability the property may not have.
It never upsells unprompted. Paid services are off-limits unless the guest explicitly asks. "Extra towels" does not trigger a transfer pitch. Mentioning an arrival time is not an invitation to sell anything.
It never invents prices, times, or policies. If a fact isn't in the property's verified profile, the assistant says "I'm not sure, but the host can confirm" rather than guessing. Accuracy over fluency, every time.
It doesn't infer dates. It only says "today" or "tomorrow" if the guest said it first; otherwise it uses neutral phrasing like "on your arrival day." Letting a model do relative-date math from message timestamps is a quiet source of wrong answers, so we simply forbid it.
It's honest about which languages it speaks. This one is counterintuitive. Plenty of tools brag about "30 languages." Ours replies only in English or Spanish โ the two languages our team actually supports โ and routes a Portuguese or French or German message to a clear English reply rather than faking fluency it can't stand behind. A confident reply in a language nobody on the team can verify is a liability, not a feature.
Why intent beats keywords
One more piece worth pulling out, because it's where most "smart" messaging tools fall down. We run a second classifier whose only job is to detect genuine purchase intent for add-on services like airport transfers.
The naive way to do this is keyword matching: see the word "airport" or "transfer," flag it, send a pitch. That's wrong constantly. "We'll take an Uber," "we already rented a car," and "we land at 3pm" all contain transport language and zero buying intent. Meanwhile "ยฟtodavรญa puedo contratar el traslado?" โ a guest changing their mind after previously declining โ is pure intent and contains no obvious trigger word.
So the classifier is told to read for intent, not vocabulary: does the guest want to buy, learn more about, or arrange the service? Mentioning a transport keyword while declining or stating self-sufficiency is explicitly not intent. It works across Spanish, English, and mixed-language messages, and it's biased toward not tagging unless intent is clear โ because a false alarm means bothering a guest who already said no.
What this means for hosts
The lesson under all of this is simple, and it runs against the grain of how AI hosting tools are marketed in 2026: the goal isn't to remove the host from the conversation. It's to remove the typing.
A well-built guest-messaging system should:
- Decide when a reply is worth your attention, and stay quiet when it isn't.
- Understand where the guest is in their stay before it writes a word.
- Refuse to promise, price, or upsell anything on your behalf.
- Hand you a finished draft and let you decide what your guest reads.
That's the difference between an AI that runs your inbox and an AI that runs your reputation into the ground. Speed is easy. Speed without losing the trust you built one five-star review at a time โ that's the hard part, and it's the part worth getting right.
BnBuddy helps short-term rental hosts automate guest communication