Pre-approval note for open dates
Send this only after you have checked the calendar and you are willing to accept a request for those dates.
When to send
A pre-approval is a yes to being asked, and it is easy to overstate. Send it when the dates in {requested_dates} are actually open, the guest count fits the listing, and you would accept the request if it arrived in the next day. {guest_name} should be the person on the inquiry. {property_name} should be the listing you just checked, not the other unit on the same account.
Do not send this because you want to sound welcoming while you are still deciding. If a cleaner is away, if the dates overlap a block you forgot, or if the group is larger than {property_name} allows, the honest note is a decline. A pre-approval that you walk back the next morning trains the guest to distrust the thread.
This message does not hold the calendar. Say that in plain words, as the template does. Guests often read a warm yes as “the place is ours.” The sentence that the dates stay available until a request is accepted is the part you should not delete when you edit.
Timing tip
Send it the same day you decide the dates work, while {requested_dates} are still the ones they asked about. If a night passes, open the calendar again before you send. A booking can land on those nights while the draft sits in your notes.
If their trip starts within two days, say so in your own edit and answer faster. A pre-approval that arrives after they have already requested somewhere else is only clutter. For a trip months away, you can send it the morning after you check, but you still re-check the calendar at the moment you press send.
Check-in time belongs here only as {checkin_time}, copied from the listing. The door code does not belong here. Codes that rotate should go out when they work, which is a check-in message, not this one.
Common mistakes
Calling it a booking is the mistake that creates a conflict. “You’re all set” and “see you then” are booking language. This template avoids them on purpose. If you add a sentence, keep the status as a willingness to accept a request.
The second mistake is a new condition. “I can pre-approve if you agree to no visitors” is a rule introduced after they already read the listing. If a limit matters, it has to be on the listing before they request. {checkin_time} is a reminder of a published time, not a negotiation.
The third is sending the pre-approval to the wrong dates. People write “the weekend of the 14th” and hosts approve the 21st because that weekend is the one that is empty. Paste {requested_dates} from their message. If you can only do different nights, say that in a separate reply and let them decide. Do not approve a trip they did not ask for.
What you still do by hand
Pre-approval on the booking site, if the site has that button, is the action that matters. This text explains it. It does not press the button. Send the text and use the site’s control, or the guest may see a message that says yes and a screen that still says the dates are only an inquiry.
After they request, switch to the booking confirmation once the stay is actually accepted. Leave this note in the thread so the timeline shows the order: question, willingness, then confirmation.