PMS vs channel manager vs booking engine: what each one does

A PMS (property management system) is the hotel's operating record of rooms, guests and money. A channel manager carries availability, rates and restrictions to booking sites and brings reservations back. A booking engine sells rooms on the hotel's own website. Each system owns different data, and most channel errors begin where that ownership is unclear.

The rate was changed this morning, and by the afternoon a booking site still shows the old one. Before anyone calls the provider, it helps to know which of the three systems actually owns that number. This article separates the three by the data each one owns, traces how a booking travels back to the hotel, and gives you a fixed order of checks for the moment a channel shows the wrong price or the wrong availability.

What does a PMS do?#

A PMS, or property management system, is the hotel's own operating record: which rooms exist, who is staying in them, and what they owe.

It defines the room list once: room types, the physical rooms behind each type, and which of them are out of order or being cleaned. It holds the guest record: identity details, stay dates, requests, and the bill (the folio) with every charge on it. It holds the money: charges, payments, corrections made by voiding and reversing rather than deleting, and the night audit that closes the business day.

It also produces the working lists the front desk and housekeeping run on: arrivals, departures, rooms ready, rooms blocked. If a receptionist asks "which room is free tomorrow?", the answer comes from the PMS or from nowhere.

In Türkiye, every stay involves a payment, a fiscal document (an invoice or e-document), a guest identity notification (KBS) and personal data (KVKK). These steps sit inside the stay, so the PMS is where they are usually prepared.

What it does not do: a PMS does not talk to booking sites by itself. Publishing rooms outward is the channel manager's job. For how systems talk to each other in practice, see Hotel PMS integrations explained: APIs in plain words.

What does a channel manager do?#

A channel manager carries availability, rates and restrictions from the hotel out to booking sites, and carries reservations back in.

It sends three things: how many rooms of a given type are for sale, at what price, and under which conditions (minimum stay, closed to arrival, stop sale). It is a messenger, not a stockroom. It keeps no independent room count of its own; if the record it reads is wrong, it distributes the wrong number faithfully and quickly.

Mapping is the work. Each room type and rate plan in the hotel's system must be tied to the matching room type and rate plan on each booking site. An unmapped pair is a room that never sells, or a price that never updates. The details are worth understanding before signing anything: Channel manager mapping: room types, rate plans and testing.

The channel manager does not set prices, decide what to sell, or hold the guest record. Those decisions belong to the hotel and to the PMS. Reservations come back as a message or a record, and whether that record lands automatically or is re-typed by a person decides how long the room stays for sale elsewhere.

A hotel can run a booking engine without a channel manager, and a channel manager without a booking engine. The PMS is the one system a front desk cannot operate without.

What does a booking engine do?#

A booking engine sells the hotel's rooms on the hotel's own website: it shows availability and price, takes the booking and the payment, and confirms to the guest.

It is a shopfront, not a stockroom. It needs a supply of availability and rates from the PMS directly or through the channel manager. It controls what the guest sees: room and rate display, extras, cancellation terms, payment method and the confirmation message.

It is where the direct relationship lives. The hotel keeps the guest contact and the booking without an intermediary, and in exchange carries the marketing that brings the visitor to the page. Metasearch listings and free booking links point at the booking engine, so the page it produces is also the shop window for travelers who never reach the hotel's home page.

A booking engine fed stale availability oversells exactly the way a booking site does. The failure looks different to the guest, not to the hotel. What it does not do: it does not manage other channels and it does not run the front desk.

Which system should be the source of truth for each piece of data?#

One owner per piece of data, written down, is the whole discipline. Every other system should read that owner's record rather than keep its own copy.

Room count and room types belong to the PMS, or to the single inventory record behind it. Two counts is two truths, and the hotel will sell the same room twice. Rates and rate plans should be defined once, in one pricing record, with the channel manager and the booking engine reading it rather than holding separate copies. Restrictions belong with the rate, so that a price and its conditions never travel apart.

The reservation belongs to the system where it was created until it lands in the PMS; after that, the PMS is the record and the channel's copy is history. The guest record and the bill belong to the PMS, always, whatever channel brought the guest.

Write the ownership on one page and give it to whoever answers the phone at 23:00. Most channel disputes are really arguments about a page nobody wrote. For the wider strategy, see Hotel distribution strategy: one inventory across every channel.

How does a booking travel back to the hotel, step by step?#

A booking made on a booking site reaches the hotel as a message, and the room only stops being for sale elsewhere once that message has been recorded and the new count has been sent out.

Step one: the traveler books on the booking site, and that site's own copy of the inventory drops by one immediately. Step two: the site sends the reservation to the hotel, either through an automatic connection or by email and an extranet screen. The route decides how much of the rest happens by hand. Step three: the reservation is recorded in the PMS. This is the moment the hotel's own room count changes. Step four: the channel manager sends the new availability to every other channel, and each channel updates its own copy.

The gap between step one and step four is the window in which a second guest can buy the same room. It cannot be removed entirely; it can be shortened and watched.

Delays usually sit in four places: manual re-entry during a busy check-in, a rate plan that was never mapped, a connection that stopped without anyone noticing, and a hotel that confirms some channels by hand. What shrinks the window: automatic delivery where it is offered, a morning check of the arrivals list against each channel, and an alert when a channel reports a booking the PMS never received. The failure modes are covered in Hotel double bookings across channels: causes and prevention.

A channel shows the wrong price or availability: where do you look first?#

Look at the source before you look at the channel. In most cases the channel is repeating what it was given, or repeating what it was given yesterday.

First, the record that owns the number: is the rate actually what you think, for that date, that room type, that occupancy and that length of stay? Second, the mapping: is the rate plan on the channel tied to the right plan in your system? A plan mapped to the wrong code shows a real price for the wrong product. Third, the last update: did the change leave the hotel at all, and did the channel accept it? A rejected update looks exactly like a channel that ignored you.

Fourth, the channel's own layer: campaigns, member rates, promotions, taxes and fees shown separately, currency, and pages a visitor's browser is holding from an earlier search. Fifth, the guest's search: two adults for one night and two adults for three nights are different questions, and a minimum-stay rule can make a free room look unavailable.

Write down what you checked and when. A pattern across many dates points to mapping; a single date points to a restriction; a single channel points to that channel's own settings.

What should you ask each provider before you sign?#

Ask who owns each piece of data, how a booking reaches you, and what happens on the day you leave.

For the PMS: can I export my guest records and my financial history in a usable format, and over what period? For the channel manager: which room types and rate plans does it map, who does the mapping, and how do I see that a mapping is working rather than merely saved? Also: how will I learn that a connection has stopped, and who is responsible for noticing?

For the booking engine: where does its availability come from, and what does the guest see when the last room has just been sold? For all three: what happens to a reservation that arrives while the connection is down, who re-enters it, and how is it checked against the channel? And what are the notice period, the help during the exit, and whether the contract lets you take the data you brought with you?

Before signing, ask for a test: one rate change and one stop sale on a test date, watched from the source record to the channel and back.

What to do next#

Write the one-page data ownership sheet first: five rows, one owner each, printed and given to the night shift. Then test it with a single rate change watched from the source record to the channel and back. Once you know which system owns which number, the three systems stop looking like rivals and start looking like one chain with clear handover points.