Your PMS now sends guest messages. When is that enough?

Something changed in hotel software this autumn, and it changes the first question a hotel should ask before buying anything that talks to guests.

On 1 October 2026 Mews launched Guest Messaging and Automations inside its property management system, saying its AI "answers 80% of routine questions instantly: pool hours, parking, late checkout, breakfast" (Hotel Online, 1 October 2026). Stayntouch has an AI chat tool embedded directly in its cloud PMS, claiming it "automates up to 95% of guest requests" (Hospitality Net, read 19 October 2026). Maestro is building on GuestXMS.

Your property management system, the system that holds your reservations, rates and room status, now very likely has a guest inbox in it. So the honest question is no longer "which messaging platform should we buy". It is "do we need one at all?"

We sell guest messaging. We are the last people you should take an unexamined answer from. So here is the examined one.

When the built-in inbox is genuinely enough

Three conditions. If all three are true at your property, stop reading and use what you already pay for.

One channel carries most of your guests. If nearly everything arrives by email, or by SMS, or through the booking platform's own message thread, a single inbox tied to the booking is the whole job. A second system adds a login, not an answer.

Almost every question is about a booking that already exists. "What time can I check in", "can I add a night", "is parking included for my stay". The PMS knows the answer because the PMS holds the reservation. Nothing has to be looked up anywhere else. This is the case the built-in inbox was designed for and it is genuinely good at it.

Your team is happy answering in the languages they speak. If your guests arrive from two or three countries and somebody on each shift speaks those languages, translation is not a problem you have.

That is a real and common property: a single-site hotel, one main channel, mostly booked guests, a team that covers its languages. For that property the built-in inbox is the simplest thing that works, it is usually included in what you already pay, and buying anything else is a cost with no matching gain.

The five places built-in messaging stops

Each of these is a structural limit, not a feature a PMS will add next quarter. They follow from what a PMS is.

1. People who have not booked yet

A PMS is organised around reservations. A person asking "do you have a sea view room for the second weekend in November, and is the pool heated" has no reservation, so there is no record for the conversation to attach to. Some built-in inboxes handle this by creating an enquiry record. Most do not handle it at all, because the moment that matters, somebody deciding between you and two other properties, happens before the PMS has anything to hold.

This is the single biggest gap, and it is the one that costs money rather than time.

2. Channels the PMS does not carry

Most built-in inboxes cover email, SMS, and the booking platform's own thread. WhatsApp through the official Business Platform is a different thing: it needs a business phone number registered with Meta, and a verified business profile if you want the name and badge to show. Some PMS products connect to it and some do not, and "we support WhatsApp" sometimes means a link to the consumer app rather than the official platform. It is worth asking which one, because the two behave differently on cost, on templates and on who can reply.

Our guide to WhatsApp for hotels versus the business app sets out the difference.

3. Languages nobody on the team speaks

A built-in inbox routes the message to a person. If no person on that shift reads Hebrew, or Japanese, or Portuguese, the inbox has done its job and the guest still waits. Automatic translation is a feature of the messaging layer, not of the reservation database, and it is usually the first thing a property discovers it is missing at two in the morning.

4. Anything that has to reach a system other than the PMS

"There is no hot water in 412." The PMS inbox can show that message to the front desk. What has to happen next is a maintenance ticket, and it has to reach a person who is not watching the PMS. The same applies to housekeeping requests, restaurant bookings, and anything that belongs to a tool your reception does not have open.

A message that arrives correctly and then needs a human to retype it somewhere else has not been automated. It has been moved. We wrote about what happens at that handover point separately.

5. More than one PMS in the group

Any group that has grown by acquisition usually runs two or three property management systems. Built-in messaging means two or three inboxes, two or three sets of saved replies, and no way to ask a question like "how long did guests wait last month" across the whole group. This one is not a judgement call: if you run more than one PMS, built-in messaging cannot be your messaging layer, because there is no "it".

The test, and you can run it this week

Do not run a trial. Run a count. Take one ordinary week and sort every guest message your property received into four piles:

1. About an existing booking, answerable from the PMS.
2. From somebody who has not booked, or who is asking about a stay that does not exist yet.
3. Needs a system that is not the PMS: maintenance, housekeeping, the restaurant, a ticket.
4. In a language nobody on that shift reads.

If pile one is nearly everything, your PMS inbox is your answer and this is a decision you can stop thinking about. If piles two, three and four together are a meaningful share of the week, you now know exactly which gap you are buying for, and you can judge any vendor, including us, against that number instead of against a demo.

Most properties are surprised by pile two. If you want a sharper version of this count, we wrote out how to audit the questions your team answers forty times a day.

If you end up running both

Plenty of properties keep the PMS inbox and add a messaging platform, and it works, but only with one rule settled first: decide which system owns the thread.

Two systems watching the same conversation produce two replies to one guest, and sooner or later the two replies disagree. The split that tends to hold is that the PMS inbox stays where staff answer booked guests, because that is where the reservation is, and the messaging platform takes the automated answers and everybody who has not booked yet.

Write that rule down before the second system is switched on, not after the first duplicate reply.

One thing that does not change either way

Cost. From 1 October 2026 Meta charges per message for service messages, the free-form replies sent inside the 24-hour customer service window, and every business phone number gets a free tier of 1,000 service messages a month, with charging from the 1,001st (Meta, WhatsApp pricing, read 19 October 2026).

Meta bills the phone number, not the software behind it. Whether those messages leave your PMS or a separate platform makes no difference to that bill. If you want the arithmetic for your own volumes, our WhatsApp pricing calculator does it by guest country.

The short version

The built-in PMS inbox is a real product and for a single-site property with one main channel and mostly booked guests it is the right answer. It stops at people who have not booked, at channels the PMS does not carry, at languages your team does not read, at work that belongs to another system, and at the second PMS in a group.

Count one week of your own messages before you decide. That number will tell you more than any vendor will, this one included.