design+code
Hotels choose a property management system for the front desk. Then they discover, usually halfway through a website project, that the same decision quietly set the limits on what the booking flow can look like. Here is how the two are connected, and what to check before you sign either contract.
A PMS is selected by operations. The criteria are rate management, housekeeping, night audit, reporting, the training burden on the team. Those are the right criteria for the people who use the system every day.
The website comes later, often a year or two later, with a different agency and nobody from that original conversation in the room. And that is when someone asks whether the booking flow can live on the site rather than sending guests to a third-party domain. The answer is set by a decision made long before, by people who were not asked the question.
This is not an argument for letting the website drive the PMS choice. Operations should win that one. It is an argument for knowing what you are buying on the distribution side at the same time you buy it on the operations side.
The booking engine is the part that takes availability and rates from the PMS, shows them to a guest, and writes a reservation back. It is almost never something you build from scratch, because it has to hold live inventory and take payment, and getting that wrong is expensive in a way that a marketing page never is.
The question is not whether you build it. It is how much of it you get to control. There are three practical levels, and the PMS decides which one is available to you.
The first is a hosted engine on the vendor's domain. The guest clicks Book and lands on booking.vendor.com. It works, it is maintained by someone else, and it is what most small properties run. What you give up is the last part of the funnel: the design breaks, the domain changes, and your analytics need extra work to follow the guest across the boundary.
The second is the same engine embedded in your page, usually in an iframe or a script widget. Visually it is closer to your site. The layout constraints are real, though, and you inherit whatever responsive behaviour the vendor shipped.
The third is a custom front end talking to a booking API. You design every screen, the URL never leaves your domain, and the analytics are clean end to end. This requires the PMS to expose a booking API in the first place, and it costs meaningfully more to build and to maintain, because the vendor will change that API and you will have to follow.
Mews is API-first and publishes an open API with a dedicated booking engine API alongside a hosted engine and a large integration marketplace. If a custom booking flow is on the table, this is the category of system that makes it possible.
Apaleo takes the same position further. It is designed as a core data layer that you compose around, which suits a property that already knows it wants to assemble its own stack rather than accept a bundle.
Cloudbeds bundles the PMS, channel manager, booking engine and payments into one product. That is a genuine advantage for a property without a technical partner, since there is one vendor and one support line. The trade-off is that you mostly work inside their framework. Cloudbeds does offer an API for connecting a third-party booking engine, but going that way means working around the bundle you chose for its simplicity.
Little Hotelier, from SiteMinder, is built for small properties, guesthouses and B&Bs. It is deliberately simple, and simple means the surface you can customise is small.
Oracle Opera is what most large chains run. Integration goes through Oracle's hospitality integration platform, which is extensive and is not a fit for an independent property's budget or timeline.
We are describing categories here, not making a recommendation. The right system depends on how many rooms you have, whether you have anyone technical involved after launch, and how much of your business comes direct rather than through the OTAs. A ten-room guesthouse that takes most of its bookings from Booking.com does not need an open API. A group with three properties and a real direct-booking strategy probably does.
Five things, and they take one email to the vendor.
Can the booking flow run on our own domain, and if so, how. Is there a public API for availability, rates and reservations, and is access included or priced separately. Can we style the engine beyond swapping a logo and two colours. What happens to our analytics and consent management when a guest moves from the site into the booking flow. And how are rate plans and promotions exposed, because a landing page for a specific offer is only possible if the offer is addressable from outside the system.
That last one gets missed most often. A campaign page that cannot deep link to the right rate with the dates prefilled is a campaign page that leaks guests at the exact moment they decided to buy.
When the booking flow is hosted elsewhere, the job of the website changes. It stops being the place where the transaction happens and becomes the place where the decision happens. The rooms need to be photographed and described well enough that the guest has already chosen before they click. The click-through to the engine should be one action from anywhere on the site. The handoff should carry as much context as possible: property, room type, dates, rate.
And the measurement has to be set up deliberately, because the default is that your analytics lose the guest at the domain boundary and you end up unable to say which pages produced revenue. Cross-domain tracking is not complicated, but it does not happen on its own, and we have picked up plenty of hotel sites where it had never been configured.
None of this makes a hosted engine the wrong choice. It just means the constraint is known before the design starts rather than discovered during the build.
We build hotel and hospitality sites, and we integrate whatever booking system the property already runs. We do not sell a PMS and we have no reason to prefer one over another. What we do ask, early, is which system it is and what it exposes, because that answer determines what we can design.
If you are choosing a PMS and want the website implications spelled out before you commit, or you already have one and want to know what your current site is leaving on the table, we are at bonjour@dellamattia.com.