Every hotel software vendor says it integrates with your PMS. Almost none of them tell you what that means, and the gap between the strongest and weakest version of the claim is enormous.
At one end, a nightly file containing tomorrow's arrivals. At the other, live reservation events flowing in the moment they happen and confirmed transactions posting back to the right folio. Both get described as "integrates with Mews" on a website. Only one of them lets you run automated upsells.
This matters more than the feature list you are comparing, because integration depth determines whether the features work at all. An upsell tool that tops every comparison but cannot see the rate plan sends breakfast offers to guests who booked bed and breakfast. That is not a product problem. It is a plumbing problem, and it is invisible until you are live.
One-way and two-way, properly defined
One-way means your tool reads from the PMS. Names, dates, maybe room type. It can send messages. It cannot record anything it does, so the PMS never learns that a conversation happened, an upsell was accepted, or a guest asked to arrive late.
Two-way means it reads and writes. The reservation flows in; confirmed outcomes flow back. The PMS stays the system of record, and it stays correct, because everything that happened in the conversation is reflected in it.
There is a third variable that gets missed, and it sits underneath both: how the data arrives.
| What happens | Batch sync | Live events |
|---|---|---|
| Typical frequency | Every few hours, or nightly | The moment something changes |
| A booking made at 14:00 | Known at the next sync | Known at 14:00 |
| A room move at 16:30 | Message may go to the wrong room | Reflected immediately |
| A cancellation | Pre-arrival message may still send | Sequence stops |
| What it can trigger | Scheduled sends | Sends triggered by the event itself |
A batch-synced two-way integration is still better than one-way, but the combination that actually works is two-way and event-driven. Ask about both. Vendors will happily answer one question and let you assume the other.
What breaks when there is no write-back
These are the specific, recognisable failures.
The upsell nobody knows about. A guest accepts a late check-out in WhatsApp on Sunday night and pays for it. The upsell tool has the money. The PMS does not know. On Monday morning the housekeeping list still shows an 11:00 departure, someone knocks, and the guest who just paid for the thing is standing there in a towel. At the end of the month, finance reconciles two systems by hand.
The message with no context. A guest asks "can I get a room with a bath instead?" The messaging tool has a name and a phone number. It does not know which room they booked, what they paid, or whether anything else is available. So the question goes to a person, who opens the PMS, looks it up, and answers. The automation saved nothing on the questions that actually matter.
The offer that should never have been sent. Early check-in offered to a guest arriving at 21:00. Breakfast offered to someone on a B&B rate. An upgrade offered when the hotel is sold out. Each one is a small credibility cost, and together they are why hotels switch pre-arrival automation on, watch it embarrass them twice, and switch it off.
The stay that is not really over. Preferences mentioned in conversation, allergies, anniversary, a preferred floor, live in the messaging tool's history and nowhere else. Next year the guest returns and the hotel has learned nothing, because none of it ever reached the guest record.
What a two-way, live connection actually makes possible
Three things, and they are the same three in every property.
Messages that know the reservation. Not a name and a date. Room type, rate plan, arrival and departure, what has already been paid for, and what language the traveller books in. That is the difference between a generic pre-arrival email and an offer worth sending. At C-Hotels Silt, offers that could read the booking produced over €24,000 in upsell revenue in three months, with 450+ orders written straight back into the PMS.
Offers that suppress themselves. Eligibility is a live question. Can this room actually go early today? Is an upgrade free on those dates? Has this guest already bought breakfast? Without the live read, you are guessing, and the offers that should not have been sent are the ones that cost you.
Revenue that lands where finance looks. A confirmed upsell posted to the correct folio needs no reconciliation, appears in your existing reporting, and is visible to the person at the desk when the guest arrives.
What actually moves, in both directions
This is what AskWhisper's PMS connection carries, across all eight supported systems.
| AskWhisper reads | AskWhisper writes back |
|---|---|
| New and changed reservations, the moment they happen | Completed check-ins and registration details |
| Traveller names, contact details and language | Confirmed upsells, posted to the right folio |
| Arrival and departure dates, room type and room moves | Preferences and notes picked up in conversation |
| Rates, extras and folio lines |
Your PMS stays the system of record. Nothing migrates, nothing is exported, and AskWhisper writes back only what it changed.
That connection is what powers guest journey messaging, automated upsell offers, and digital check-in with keys. None of those three run properly on a one-way feed.
Most of that journey runs on WhatsApp, where the rules on what you can send and when shape every sequence. Our WhatsApp automation playbook covers them.
For Mews, you authorise from inside your own Mews account. There are no API keys to find and no developer involved.
For Cloudbeds, it installs from the official Cloudbeds Marketplace in a couple of clicks, with no custom development.
Connecting takes minutes in both cases. Most properties are fully live within a few days, because the time goes into deciding which journeys and upsells to switch on, not into the connection itself.
Questions to ask any vendor before you buy
Ask these in the demo, and ask for specifics rather than reassurance.
Is this one-way or two-way? If two-way, what exactly does it write back? "It writes notes" is not the same as "confirmed upsells post to the folio."
Real-time or batch? If batch, how often? A four-hour sync cannot support anything triggered by a room move or a cancellation.
Which fields sync? Ask for the list. Specifically: room type, rate plan, folio lines, room moves, language. A vendor that cannot produce this list in the demo does not have a deep integration.
What happens on a sync error? Is there retry logic? Does anyone get alerted, or does it fail silently until someone notices the messages stopped? Silent failure is the common one and the expensive one.
Who owns it when it breaks? With two vendors and one broken connection, you want to know in advance who takes the ticket rather than discovering they each blame the other.
How do I connect it, and what does that require of me? Authorising from inside your own PMS account in a few minutes is a different proposition from a developer project with API keys and a scoping call.
A vendor answering all six clearly is telling you something about the product beyond the integration.
What this does not solve
A deep integration does not fix bad data. If your room types are inconsistently named in the PMS, or your rate plans do not describe what is included, everything downstream inherits that. Time spent tidying the PMS before connecting anything is time well spent.
It also does not remove the PMS from your stack, and no guest communication platform should be asking you to replace it. The reservation, the folio and the audit trail belong in the system of record. A connected layer reads from it and writes back to it. Anything proposing to take that over is proposing a migration, which is a much larger decision than the one you thought you were making.
Which parts of the stack are worth consolidating, and which to leave alone, is the subject of platform versus point solutions.
Ask the six questions above of whoever you are talking to. If the answers are vague, the integration is shallow, and everything built on top of it will underperform for reasons that look like product problems.
Turn lookers into bookers. Just Ask Whisper.
