Guides 4 min

PMS, channel manager, booking engine: what each one actually does

Three pieces of software that get confused with each other and solve different problems. What each does, where they overlap, and the order in which it makes sense to adopt them.

Anyone shopping for software to run an accommodation business runs into three terms that look interchangeable and are not. It is common to end up paying twice for the same function, or to discover months later that a piece everyone assumed was included is missing.

The distinction is simpler than the sales material suggests, and it comes down to three questions: where the data lives, where it is shown, and who it is shown to.

The PMS: where the data lives

The PMS (Property Management System) is the property's central record. It knows which units exist, who is in which one on which dates, what has been paid, and who is still due to arrive.

It typically covers:

  • the reservation grid and front desk
  • guest records
  • the folio: charges, payments, fiscal documents
  • housekeeping and maintenance
  • statutory reporting, where the country requires it

The PMS does not sell anything. It is the ledger: if a booking exists, it exists there.

The booking engine: selling on your own site

The booking engine is the piece that lets a guest book directly from the property's own website. It shows availability, applies rates, collects the details and — almost always — takes a deposit or the full amount.

The economics are the whole point: a booking that comes through the booking engine pays no intermediary commission. It pays only the payment processor's fee, which is an order of magnitude smaller.

The booking engine does not replace the PMS. It sells, then writes the booking into the PMS.

The channel manager: selling everywhere else

The channel manager is the translator between the property and external portals — the OTAs: Booking.com, Expedia, Airbnb and the rest.

Without one, a property selling on three portals has to update availability in three separate panels every time a booking arrives or is cancelled. It is mechanical work, and more importantly it is the single largest cause of overbooking: a half-hour delay updating one portal is enough to sell the same room twice.

A channel manager works in two directions:

  • outbound, it pushes availability, rates and restrictions to the portals
  • inbound, it collects bookings from the portals and writes them into the PMS

How they fit together

The clearest way to see it is as one centre and two doors.

Problem it solves Who it talks to
PMS Always knowing the real state of the property Your staff
Booking engine Selling without intermediary commission The guest, on your site
Channel manager Selling everywhere without manual updates The OTAs

The PMS is the centre. The booking engine and the channel manager are two sales channels writing into the same ledger. If they write into different ledgers, the problem is not solved — only moved.

The mistake that costs the most

Running all three as separate products from different vendors, held together by integrations.

It works until it doesn't. The day the channel manager to PMS integration breaks — an API change, a lapsed renewal, a bad update — the property keeps selling without updating availability, and the overbooking arrives before anyone notices. On top of that, when something goes wrong, each vendor points at the other.

This does not mean an all-in-one is always right: if you already have a PMS that works for you, replacing it just to consolidate is a cost that needs justifying. It means the number of breakage points belongs in the comparison, next to the price.

What order to adopt them in

For a property starting from nothing, the sensible order is almost always:

  1. The PMS first. Without a reliable record, everything else amplifies the mess.
  2. Then the channel manager, if you sell on more than one portal. With a single portal the gain is marginal and you can wait.
  3. The booking engine last. Not because it matters least — it has the largest effect on margin — but because it only pays off once you already have traffic on your own site. Putting it online with nobody arriving there produces no direct bookings.

That last point is the one vendors tend to skip. A booking engine is necessary for direct bookings, not sufficient: someone also has to visit the site.

What to ask before signing

  • Do portal bookings reach the PMS automatically, or does someone re-key them?
  • How long after a direct booking does availability update on the portals?
  • Does the booking engine actually take payment, or just capture card details?
  • When something fails to sync, who do I call?

Four unglamorous questions that discriminate between products better than any feature list.

Before You Go!

Try Stay completely free for your property. No credit card required, no commitment. See how our platform can transform your operations.