Platform

Guest messaging

You stop tab-switching to answer guests. Messages from every channel land in one thread per stay, you answer from one place, and you can see whether the channel took it.

One inbox

Each stay gets one thread. Everything the guest sends collects there, whatever channel it arrived on: before the booking, during the stay, and after checkout.

A thread carries the guest name, the property, and the reservation it belongs to, so you answer with the stay in front of you. Search narrows the list by guest or property.

Unread counts belong to each person. Opening a thread clears your own count and leaves your colleagues untouched.

Reply once, delivered where they booked

Write the reply in Supahost and it goes out on the channel the guest booked through. You never open a channel site to answer a question. One reply holds up to 10,000 characters.

Two conditions open the reply box:

The channel connection must support sending messages. A thread that arrived on a connection without that capability stays readable, not answerable.
Your role must include the Guest messages permission. Without it the thread opens read-only and Supahost says so in place of the composer.

Watch the reply land

Supahost accepts your reply first and hands it to the channel second, so a reply is never lost while a channel is slow. Each one shows the furthest state it reached:

Queued means Supahost holds it and the channel has not taken it yet.
Sending means delivery is in flight.
Sent means the channel accepted it.
Delivered means the channel confirmed it reached the guest.
Failed means the channel rejected it. The reply stays in the thread with the failure visible rather than disappearing.

Retry appears on a reply still sitting in Queued and starts delivery again. A Failed reply cannot be retried from the thread today, so send a new reply instead.

Let Leah draft the reply

Leah reads the thread before she writes. She answers from that conversation, the reservation, and the property facts, and from nothing else.

Sending reaches a guest, so it waits for your approval every time. The exception is a saved playbook that you set to run on its own. A playbook fixes the rules before she answers anything:

Scope: which properties, which channels, and which stage of the stay. The stages are inquiry, pre-arrival, in-stay, and post-stay.
Active hours, so she does not answer in the middle of your night.
Tone: concise, empathetic, friendly, formal, or inviting.
Restricted topics she must never settle herself. Refunds, discounts, compensation, payments, availability, date changes, early check-in, late checkout, property moves, sensitive stay details, and safety are all restricted until you remove them.
Minimum confidence, 0.85 by default. Below it she escalates rather than send.
A cooldown after a human reply, 15 minutes by default, so she never talks over you.

A playbook can also run the moment a guest message arrives, which is the closest thing here to an autoresponder. It is still bound by every rule above.

A Suggest only playbook never sends. It reads, drafts, and leaves the reply waiting for a person to approve in the run thread. Autonomous is the only level that sends without you.

She withholds the address, the access method, the door code, and the Wi-Fi details whenever sensitive stay details are restricted, even when the guest asks directly.

Leah, the operations agentHow approvals, threads, and the tool trail work across every surface.

Guest data

For guest personal data, you are the data controller and Supahost processes it on your instructions. The Privacy Policy states this split precisely, including what happens to guest data when you leave.