I'm currently running Stayntouch to SiteMinder configuration for a multi-property US operator, and the same conversation keeps happening. Someone on the marketing or ownership side asks why direct bookings look soft on a specific room type, or why an OTA is showing rates that don't match what's in the PMS. The instinct is almost always to look at the campaign. Check the ad spend, check the landing page, check the offer. Nobody starts by checking the sync.
That's the wrong place to start looking, and it's the reason this keeps happening across properties that have nothing else in common.
The word "two-way" is doing you a disservice
SiteMinder and Stayntouch describe their connection as a two-way interface, and technically that's true. Data does move in both directions between the two systems. What that label doesn't tell you is that it isn't the same data moving both ways.
Availability, rates, and restrictions only travel one direction: from the PMS out to the CRS. Reservations only travel the other direction: from the CRS back into the PMS. There's no round trip. When Stayntouch pushes a rate change, SiteMinder doesn't send anything back to confirm it landed correctly. When a reservation comes in through SiteMinder, the PMS doesn't push anything back to confirm the room and rate were interpreted the way you meant them.
"Two-way" means data crosses in both directions somewhere in the system. It does not mean either side is checking the other's work.
That distinction matters because it changes how you should think about troubleshooting. If your OTA rates look wrong, checking the PMS side tells you what was sent. It tells you nothing about whether it was received or applied correctly on the other end. Most teams don't realize they're only ever looking at half the picture.
The exact-match trap
Every room type and rate code has to match precisely between the two systems. Not close. Exact. If a rate code gets renamed in one system during a routine cleanup and not the other, or a room type gets consolidated on one side and forgotten on the other, the mapping doesn't throw an error. It just goes inactive and quietly stops sending updates.
No alert. No notification. No red flag in either dashboard. The first sign is usually a guest complaint about a rate that doesn't match what they saw when they booked, or a revenue report that stops reconciling and nobody can figure out why.
This is the part that makes these errors expensive rather than just annoying. A loud failure gets fixed fast because someone notices immediately. A silent one can run for weeks. I've seen mappings that had been inactive long enough that nobody could say with confidence when the drift actually started.
Build order actually matters
There's a specific sequence for getting a new rate live across both systems: build it in the CRS first, then build the matching code in the PMS, then publish and activate the mapping from the PMS channel manager settings. Skip a step, or do them out of order, and the rate either never reaches the OTA or reaches it with the wrong logic attached on the first push.
I've watched teams build the PMS side first, because that's the system their staff lives in every day, and then spend an afternoon confused about why nothing showed up on Booking.com. The systems aren't wrong. The order was.
Where sell limits get miscounted
Sell limits, the mechanism that lets you overbook a room type past its physical count, run on a formula tied to your property's original inventory number. Not the current count. The original one. If you've renovated, combined rooms, or adjusted your room type mix mid-year without going back into the sell limit configuration, the overbooking math is quietly running on numbers that no longer describe your building.
On top of that, this level of control only applies cleanly at the room type level for CRS purposes. A house-level sell limit doesn't just work automatically. It needs a manual update on the CRS side too, and that's a step a lot of teams don't know exists until an overbooking situation goes sideways.
Restrictions that "should" transfer and don't
Not every restriction type makes it across the integration, no matter how correctly everything else is configured. Minimum length of stay through specific dates, minimum and maximum advance booking windows, house-level restrictions, and rate-type-level restrictions simply aren't part of what this integration path supports. If a revenue manager sets one of these expecting it to reach the OTA, it won't. Not because of an error. Because it was never going to.
There's a second trap sitting inside the restrictions that are supported. Hierarchy-level restriction control only allows one method active at a time, rate-level or room-type-level, never both together. Teams often configure both because it feels like it should mean more control. Only one of them actually takes effect, and there's no warning telling you which one won or that the other is being silently ignored.
This is the gap between "compatible" and "configured correctly." A vendor spec sheet will tell you two systems are compatible. It won't tell you which specific settings actually pass between them, and which ones just look like they should.
Why this is a marketing problem, not just an IT one
Here's where this actually lands on someone's desk. If a rate mapping has quietly gone inactive, or a restriction never made it to the OTA in the first place, the numbers showing up in a booking funnel or an attribution report aren't wrong because the campaign underperformed. They're wrong because the data feeding the report was never accurate to begin with.
A marketing team optimizing against numbers like that isn't optimizing anything. They're chasing noise generated by a sync error nobody told them to look for. Every dollar spent testing creative or adjusting bids against that data is a dollar spent solving the wrong problem.
This is exactly why the backend and the marketing side of a property need to be treated as one system, not two departments that occasionally talk. The campaign can be flawless. If the plumbing underneath it is quietly broken, the campaign gets blamed for a problem it didn't cause and can't fix.
If you're running multi-property distribution across Stayntouch and SiteMinder, or inheriting a configuration you didn't build yourself, this is worth a direct look before you trust the numbers coming out of it. That's exactly the kind of audit a Revenue Diagnostic is built for.