An automated message goes out on a date chosen in advance, with text written in advance. Very effective for what does not change. Useless for the rest. Here are the three stages, in the order they usually appear.
- Schedule your sendsWhat Airbnb and Booking can do, plus a template ready to copy
- The limit of one fixed textIt repeats what the guest already knows and ignores the property
- Adapt, then replyWhat Sentioo adds at the moment the message leaves
What Airbnb and Booking already allow
Both platforms have their own automated messages. You write a text, tie it to a moment in the booking and insert fields such as the first name or the dates. Then the message goes out on its own.
So the question is not whether it can be done. It is that the same sequence has to be set up in each platform, separately, then kept current everywhere. That is why hosts often end up driving these sends from a PMS.
The most useful message in the sequence is the one sent the day before arrival. It is short by design: a long message is a message the guest stops reading. What they did not read, they will ask for.
Five other moments complete the sequence. They are collected in the six templates to copy, along with what is better left out.
One text for everyone eventually grates
Three limits come up in almost every guide in the sector:
- No mid-stay message conditioned on the length of the stay.
- No natural extension to platforms other than the one where the message is set.
- Little personalisation from one property to the next.
They share the same root: the text is decided before the situation exists. This is not a missing setting. It is how the mechanism works. A template does not know the guest already wrote yesterday, that they already have the code or that they are arriving by train and have no use for parking information.
Adapting the message before it goes out
You keep control of the schedule and the text. What changes is what happens the second the message leaves. Your template either goes out as written or Sentioo rewrites it while keeping your tone, the thread history and the property knowledge base.
Here is the same message, for a guest who wrote the day before to say they were arriving by train and already has the code.
Template sent as written
Hello Julien, we are looking forward to welcoming you tomorrow. Check-in is self-service from 5 pm. Here is the keybox code: 4826. If you are coming by car, you can park behind the building. Please confirm your arrival time.
It greets again, repeats a code already sent, mentions parking to someone arriving by train, and asks again for a time already given.

Rewritten by Sentioo
The flat will be ready from 5 pm, so arriving at 8 pm is no problem at all. The code sent yesterday in this thread is still valid. If your train runs late, tell me here.
Same trigger, same deadline, same starting template. The message continues the conversation instead of restarting it.
Your template stays the reference version. It goes out as written if you want it to and serves as the base when you let Sentioo adapt it. The option is set message by message.
The schedule follows the same logic: on top of the three system messages per booking, you can add custom messages per property, with no cap on how many, placed up to thirty days before or after the arrival or departure date.
Connected to your PMS





After the send, handling replies
This is the stage guides on the subject nearly always skip: they stop at the send. Yet a message that lands well often brings a reply, about arrival, access, wifi, parking or a late checkout.
- CopiloteThe reply is drafted and waiting for you. You review, you correct if needed, you send.
- HybrideSentioo replies on its own during your chosen hours and leaves the rest to you.
- AutopiloteThe reply goes out on its own. Anything outside the known scope comes back to you rather than being invented.
Not everything is settled by a text. As soon as it requires action on site or a judgement call that is yours, control has to come back to you. So the right question is not only which messages to send and when. It is also who handles the next reply.
Fixed message, adapted message, reply
| Fixed message | Adapted message | Reply to the guest | |
|---|---|---|---|
| When it goes out | At the planned date | At the same date | When the guest writes |
| Basis of the text | Your approved text | Your original template | The thread and your instructions |
| Reads the thread | No | Yes | Yes |
| Property instructions | Only if written into the template | Read at send time | Read at reply time |
| Several platforms | Set up in each one | Once | Once |
| Outside the known scope | Not applicable | Not applicable | Comes back to you |
How to choose
One or two properties, a single platform, stable text: Airbnb's own tools are enough. You stay inside the platform. You add neither a tool nor a rule.
Several platforms, or a sequence you change often: the PMS becomes the right place to drive from, rather than repeating the same settings in every extranet. Setting it up in Beds24 gives a full worked example.
When the question is no longer when to send but who replies afterwards: that is different ground. It is not the number of properties that decides. It is the volume of unforeseen questions. One very busy property sometimes costs more time than five quiet ones.










