Answer every guest on time, also when you are away from the inbox. A flow sends the right message when something happens, and its run history shows you what it did and why.
A flow starts with a trigger, such as New booking request or New inquiry. Steps follow it: conditions, waits, messages, notes, tasks, and more. Open Flows in the sidebar to see your flows and their status: Draft, Shadow, Live, or Paused.
- Select
New flow, or start from a template underA helpful starting point. - Add steps on the canvas and connect them. The editor saves your draft as you work.
- Select
Test and historyto try the draft with sample data or a past event. A test records what the flow would do. It sends no message and changes no booking. - Select
Publishwhen the editor shows no validation issues. - Select
Start shadow runto record what the flow would do with live events for 1 to 90 days, orEnable live flowto start it.
In Flow settings, set the Action mode: Host approval, Auto with guardrails, or Full autopilot. One action can use a different mode. Templates start with Host approval, so you approve each action before it goes out.
A flow can have up to 150 steps. Edits to a published flow take effect only after you publish again.
Two templates give every new guest a fast first reply, also at night.
Inquiry auto-responderwelcomes a guest who sends an inquiry and offers help.Request auto-responderreplies once to each new Airbnb booking request. It thanks the guest and tells them that you will review the request.
The request template checks that the request came from Airbnb. Direct booking requests do not get this reply. Airbnb sends a new event each time a guest changes a request, so the template replies only once to each request.
An auto-reply never accepts or declines a request. You still decide in the request panel of the inbox.
Greet every guest on the day they arrive and thank them on the day they leave, with no task to remember. Two switches send these messages for you, on the guest’s booking channel.
Check-in day messagegoes out at 9:00 AM on the arrival day, in the property’s time zone. It gives the guest the resort confirmation number. A continued stay can move to a new resort booking partway through. On that day, the guest gets the message again with the new number. Each resort booking gets it once.Check-out day messagegoes out at 5:00 PM on the last check-out day, in the property’s time zone. Each reservation gets it once. The day that a continued stay moves to a new resort booking does not send it.
Open Settings, then the Messaging tab, then the Check-in and check-out messages card. Everyone on your team can see the card. Only owners and administrators with the Automations permission can change it. Other people see the switches and the text, but cannot change them. In Flows, anyone with Automations can edit and publish the same flow. A publish there turns the message off, and then only an owner or administrator can turn it on again on the card.
Turn a message on
- Write your text in the
Messagefield, or keep the starter text. - Select
Save message. The first save sets up the message. The message stays off. - Turn on the switch beside the message name.
A switch starts the next day in each property’s time zone. Supahost sends no messages on the day that you turn it on. The first messages go out the next day. Supahost does not send a skipped message later. The card shows when you turned the message on.
Turn the switch off to stop. Supahost sends no more of these messages. When you turn it on again, it starts again the next day. A publish in Flows also turns the message off, so turn it on again after you publish.
Edit the message text
Change the text on the card, then select Save message. Supahost checks each variable before it saves the text, and it refuses a name that it does not know.
- For the check-in message, the card suggests
{{guest.greeting_name}},{{property.name}}, and{{reservation.custom.resort_confirmation_number}}. - For the check-out message, the card suggests
{{guest.greeting_name}}and{{property.name}}. - If the message is on, the next messages use the new text. The switch stays on, and its start day does not change. In rare cases Supahost cannot turn the message back on.
When a switch stays offbelow tells you what you then see. - Before the first publish, the card shows the text that you saved. After it, the card shows the published text, which is what guests get. An edit in Flows that you did not publish then does not show on the card.
Select Open in Flows to change more than the text, such as the steps. The link shows after the first save. The card and the Flows editor change the same flow. A change that you save on the card or publish in Flows shows in the other place.
A check-in message never goes out with an empty gap in place of the number. When a stay has no resort confirmation number, the guest gets no message, and the flow does not wait for the number. Supahost emails the person who last published the message instead. A turn-on publishes a message that nobody published yet. A publish in Flows publishes it too, and so does a save on the card after the first publish. The email names the guest, the property, and the arrival date. It goes out when that person has email on for Automation flows alerts. The alert also shows in Supahost and in the run history. Add the number on the reservation, then send the check-in message yourself.
No double messages
Supahost does not let a switch and a matching flow of your own both send a day message. A switch does not turn on while one of your own live flows sends a guest message at the same moment. That is a flow with the same trigger, time, and offset. This includes a flow that you made from the Check-in day message or Check-out day message template. The rule works both ways: while a switch is on, Flows does not let such a flow go live.
- On the card, you see:
The flow “<name>” already sends this message. Turn it off in Flows first, so guests do not get it twice. - In Flows, you see:
“<name>” is on in Settings › Messaging and already sends this message. Turn it off there first, so guests do not get it twice. - Flows in shadow mode and flows that only alert your team do not count. A flow at a different offset does not count either, such as a reminder the day before check-out.
Supahost compares set clock times only. It does not check a flow that sends at each property’s own check-in or check-out time, also when that time is 9:00 AM or 5:00 PM. Turn that flow off yourself before you turn on a switch.
When a switch stays off
If a switch cannot turn on, the card tells you why:
This flow is in shadow mode in Flows. Go live from its shadow review there, or publish it again, to use this switch.Save messagewaits too, because a save publishes the flow again and ends the shadow test.This flow no longer has its message step. Edit it in Flows.Someone removed the message step in Flows, so the card has no text to edit. Put the step back in Flows.Add a text field named Resort confirmation number in Fields to turn this on.The check-in message needs that custom field, andSave messagewaits until it exists.Save the message text to turn it on.orSave your changes to turn it on.Save the text first.
A save on the card can publish the flow. So the card refuses a save while the flow has changes in Flows that you did not publish. It refuses the same way on the first turn-on of a message that nobody published yet, when the flow has changes like that. Supahost then shows This flow has unpublished changes in Flows. Publish or discard them there first. Steps that you only moved on the canvas do not count. A message that you published before still turns on with its published text. Your unpublished changes stay in Flows.
If someone changes the flow in Flows while you save, Supahost shows This flow just changed in Flows. Reload the page and save again. and saves nothing.
A save on a message that is on also turns it on again. If that fails, for example because a matching flow of your own went live, Supahost shows The new text is saved, but the message could not be turned back on, so it is off now. and the reason. Fix the reason, then turn the switch on. The message starts again the next day.
Variables put each guest’s own details in a message. Under a message field, open Insert a variable, then search Data to insert. Supahost puts the variable in your text, such as {{property.name}}.
Use {{guest.greeting_name}} to greet a guest. It is the guest’s first name. When the name is missing or is only an initial, such as J. or J. R., it reads there. So a message never starts with Hi J.,.
{{guest.first_name}}is the first name exactly as the channel sends it.{{reservation.check_in}},{{reservation.check_out}}, and{{reservation.nights}}give the stay dates and length.{{reservation.custom.<key>}}gives the value of one of your reservation custom fields.
If a variable has no value when the step runs, the step stops before it sends. The run history shows the reason.
A Send message step has three sources:
Templatesends your text as you wrote it.- AI writes a reply from your instructions.
Personalizedwrites its own version of your text. It keeps every fact and question in your text, and it also answers the guest’s questions.
When a guest waits for an answer, these steps use the same sources as the drafts in your inbox: listing details, knowledge, agent rules, and past team replies. A flow step does not check your calendar. Its instructions forbid it to accept, decline, or promise a stay.
If a personalized reply needs review, or your workspace reaches its AI limit, the step uses your text as written. With Host approval or Auto with guardrails, a person sees the reply before it goes out.
The flow sends its own messages. In the inbox, a reply from a flow shows the flow name and Flow as the sender. A flow continues to reply after the person who published it leaves your team.
- A flow reply does not count as a team reply. The conversation still shows
Needs a replyuntil a person answers. - If you pause or publish a flow again before you approve one of its messages, Supahost refuses that message.
After a flow reply goes out, Supahost checks whether it answered the questions that the guest asked since your team last replied. If it missed one, the thread shows This reply missed guest questions under the reply and lists them, so you can answer them yourself. The check never stops or changes a reply.
See what every flow did, and fix a problem before guests notice it. Open Flows, then the Run history tab. The tab shows how many live runs failed in the last 24 hours.
- Filter by flow, by run mode (
Live runs,Shadow runs,Test runs, orAll runs), and by time: 24 hours, 7 days, or 30 days. - Select a tile, such as
FailedorRetried, to show only those runs. - Select a run to see each step, the message it prepared, and the reason for a failure.
Action failed means that the run finished, but one action failed, or a guest message did not arrive. When a step fails for a short time, Supahost tries it again a few times. The run shows how many retries it took.
Replay a failed run
Fix the cause first, such as a missing custom value. Then open the failed run and select Replay run.
The run continues from the step that failed, on the flow version that ran. Steps that finished do not run again. Supahost does not send a message a second time.
- You can replay only live runs. To try a test again, test the flow from its editor.
- You can replay a run for 7 days after its last failure, up to 3 times.
- The flow must still be live on the same version, for the same properties.
- Supahost does not replay a run when an action possibly reached its service already. Check that service, and finish the action there.
- You need the
Automationspermission to replay a run.
Know about a failed guest message in minutes, not when the guest complains. Supahost can post to Slack each time a live run fails. Owners and administrators who have the Guest messages and Automations permissions can set this up.
- Open
Settings, then theAgent rulestab, then theFlow alertscard. - Turn on the switch.
- Select a
Slack account, or connect Slack. - Choose the Slack send message action, and set the channel.
- Select
Save. - Select
Send test alertto check the setup.
Each alert names the flow, the reason, and the property, with a link to the run history. Test runs and shadow runs never send alerts. A step that Supahost tries again sends no alert unless the run fails. A replay that fails again sends a new alert.
Alerts post through the Slack account of the person who saved the card last. If that person leaves or loses the Automations permission, alerts pause until someone saves the card again.
View flowslets a person open flows, their run history, and shadow results without changes. Every premade role has it.Automationslets a person create, edit, test, publish, pause, and replay flows. Owners, administrators, and operations managers have it.
A person without View flows sees a message that asks them to request access from a workspace admin.