One inbox for all guest communication: SMS, email, WhatsApp and OTA messaging

A forty-room property answers guests on five surfaces before lunch.

WhatsApp, on somebody's personal phone. The Booking.com extranet. An Airbnb thread. The reception mailbox. A web chat widget nobody opens after 18:00.

Each one is a separate login, a separate notification sound, a separate idea of what a conversation is. None of them knows what the others said. The guest does not care. The guest sent one message.

Most writing about guest messaging argues about what the AI is. This post argues about where the messages are. Before you can automate a message you have to be able to see it, and most operators cannot see all of theirs in one place. A unified inbox for WhatsApp, Booking.com and Airbnb messages is not a nicer chat window. It is one queue instead of five tabs, with the reservation showing alongside the conversation, sitting on top of the PMS you already run.

So start by counting.

Where do your guest messages actually live?

Do the inventory honestly. One property, one week.

• WhatsApp. Usually a personal number belonging to whoever set it up. It works because guests already have it open. It fails because it leaves with the person who owns the phone.
• Email. info@, reception@, reservations@, plus the one address a returning guest kept from 2023. Threads split, get forwarded, and end in somebody's personal folder.
• SMS. Arrival details, door codes, the message that has to land whether or not the guest installed anything. Sent from whatever tool was handy; and when a guest replies, the reply arrives somewhere nobody is watching.
• Guest chat. The widget on your own site. It collects the highest-intent messages you receive — someone reading your rooms page, right now — and it is the surface least likely to be staffed after six.

Four surfaces, before you connect a single channel manager. Nobody buys four inboxes on purpose. They accumulate, one channel at a time, each one added for good reason.

Then, if you sell through OTAs, add theirs. Booking.com messages land in the extranet, next to rates, availability and the review queue — whoever handles pricing sees them first, whoever handles guests often does not. Airbnb keeps its own thread, its own timing rules, its own notifications: read on a phone at the bus stop, answered from a laptop three hours later, if at all. Connect both and you are at six.

What changes when five tabs become one queue?

One queue means the inbox is the unit, not the tab.

Every conversation from every channel lands on one screen. WhatsApp, SMS, email, Booking.com, Airbnb, web chat. They stay in separate conversations. A WhatsApp conversation is not merged into a Booking.com one, and neither is filed away under a guest's name. They sit next to each other in one list and you work it down, with all the required information in plain sight.

The channel becomes a label on a conversation rather than a place you have to go.

Open one and the reservation shows alongside it: dates, room, arrival time, balance, previous stays. So you stop asking three questions before you can answer one. Who is this? Have they stayed before? What did we already promise them? It is on the screen.

Your queue is real and your single overview. When messages live in five systems there is no such thing as "everything answered", there is only "everything answered in the system I happen to have open". One queue can be emptied. Five cannot.

Hans Brinker Hostel consolidated four tools into one this way. Not four features into one feature: four separate products, four logins, four places a guest question could be sitting unanswered, replaced by one queue on one screen. Read how Hans Brinker did it.

What does the guest see?

Nothing.

This is the part worth being blunt about, because it is where most guest-experience products ask for something. There is no app to download, no account to create, no portal link to find in an email from four days ago.

The guest replies where they started and what they prefer. If they messaged you on WhatsApp, the answer arrives on WhatsApp. If they wrote through Booking.com, the reply appears in the Booking.com thread, inside that platform's rules. The consolidation happens on your side of the glass. On the guest's side, they sent a message and got an answer.

That asymmetry is the whole design. Operators need one surface. Guests need the surface they already chose and prefer. Any product that fixes the first by changing the second has moved the problem to the person least willing to do the work.

Answers come back in the guest's own language, across 100+ languages, without you maintaining a separate template set per language, which matters more in European operations than most vendors admit, where a single Tuesday can bring German, Dutch, Spanish and Portuguese into the same queue.

Who picks it up at shift change?

The handover is where guest promises are lost, and the fix is not a better meeting.

Internal notes live on the conversation. Staff-only, invisible to the guest, sitting in the conversation they refer to rather than in a group chat two apps away. "Arriving late, I told them the side entrance stays open." "Second time this month the shower has come up, send maintenance before they mention it again." The next shift opens the conversation and sees the note attached to the exact message that caused it.

That retires the parallel staff WhatsApp group, which is one of the more satisfying deletions in this job.

Handoff notes work the same way when the AI concierge passes a conversation to a person. Rather than a bare alert, the note in the conversation says what was asked, what was tried, and what the AI needs a human to decide. Nobody has to reconstruct the conversation before they can act on it. The escalation arrives with its context already written down.

LabNul50 retired their 24/7 phone concierge on this basis: the exceptions still reach people, but they reach them in a readable state.

What if you run twenty properties, not one?

Then the question is not the inbox, it is the filter.

Channel filters let you cut the queue by channel, status and property. A single manager can look at one property's unanswered messages. A regional lead can look at every Airbnb thread across a portfolio. A night team can look at everything unanswered, everywhere, and nothing else.

Portfolios do not agree on how they want to work, so the queue does not insist. Some groups want one shared inbox across every property with filters applied per role. Others want each property to see only its own and the group view to belong to the head office. Both are configurations, not different products.

Does this replace my PMS?

No. It is worth answering plainly, because it is the first question every operator asks and the answer shapes everything above.

HolidayHero sits on top of the PMS you already bought. We read from it and write back to it — reservation, dates, room, arrival, balance and message. Which is why the reservation shown alongside the conversation is accurate rather than typed in by hand. Mews, Apaleo, Hostaway, Guesty, Lodgify, Smoobu, RoomRaccoon, Beds24 and more are already connected. See the Mews integration or the Hostaway integration.

Your PMS very likely has a mailbox. It has one for the channels your PMS sells through. It does not carry your WhatsApp number, your website's web chat, or the shift note that explains why room 14 is not to be sold before Thursday. The gap is not quality, it is coverage — with its data — and coverage is the entire point of the exercise.

No migration. No switch. Published pricing from €6.50 per unit per month, with no setup fee. GDPR, EU data residency and PCI DSS L1, across 23 countries and 235,431 reservations processed to date, on 99.9% uptime.

What happens over the next eleven weeks?

This post is the first entry in our Release Radar.

For twelve weeks we are shipping one release a week and publishing it the same week, in public, under a new Release Radar category. Fixed days. One block of work at a time.

One rule underneath it: nothing gets previewed before it is live. Everything you read in the Radar is running in production for customers on the day it is published. No roadmap slides, no "coming soon" with a waitlist attached. If it is in the Radar, you can turn it on.

Week one is the container, starting with every guest message in one inbox. On Thursday we publish what fills it, including the share of guest messages that resolve without a human, ungated and with the method stated: the guest messaging numbers.

If you want the container first, the AI Concierge pillar has the full picture, or book a demo and we will show you your own five surfaces becoming one.