PMS, CRS and Channel Manager: How Hotel Software Connects

A hotel property management system (PMS) runs the building, a central reservation system (CRS) holds rooms and rates for a group of hotels, and a channel manager sends availability and prices to the sites that sell your rooms. Each does one job. The trouble starts in the gaps between them.

Explainers often define the three boxes and stop, which is the easy part. The question that decides whether your hotel gets double bookings is different: for each piece of data, which system is allowed to be right?

What does each system actually do?

Each system owns a different part of the guest's journey, and confusing them is the most common cause of buying the wrong thing. This is how they typically divide the work:

Other systems plug into the PMS too. Mews lists channel managers, CRMs, payment gateways, keycard systems, POS and accounting software among the usual integrations, so charges from the restaurant reach the room bill and bookings reach the books.

A single independent hotel often needs a PMS, a booking engine and a channel manager, and no CRS. A CRS earns its place when several properties share stock, rates or loyalty. If you are setting up a stack for the first time, our overview of the tech stack of a modern independent hotel shows how the pieces fit.

How does a booking travel through the systems?

A booking passes through at least three systems, and each handover is a place it can go wrong. Follow one example.

1. A guest books on a travel site. The booking lands in the channel manager.
2. The channel manager sends it to the PMS, where it takes a room off the shelf.
3. The PMS updates availability, and the channel manager passes the new count back out to every other site and to your booking engine.
4. At check-in, the PMS creates the folio. Charges from the restaurant, bar or spa post to it from the POS.
5. At check-out, the payment goes through your payment gateway and the accounting system receives the totals.

If step 3 is slow or fails, two guests can book the last room. Mews notes that without real-time sync, overbookings can occur when availability is not updated across channels. The risk sits in the delay between the systems, not in any one piece of software.

Why do two-way connections matter?

A two-way connection lets changes in either system reach the other in near real time, while a one-way link only sends data in one direction. Mews describes two-way integrations as ones that exchange data bidirectionally, usually powered by APIs.

One-way links have their uses. A system that only reads data, such as a reporting tool, may need nothing more. HTNG, the hotel technology standards body, built a simple one-way standard called HTNG Express for providers that only need to read data from a PMS. Newer technology providers often lack the money to build separate integrations with each PMS, and a single narrow standard lowers that cost.

For anything that touches availability, rates or payments, you want two-way. Ask for it by name, and ask what exactly flows each way.

Who is the source of truth for each field?

For every important piece of data, one system should be the master and the others should follow. Two systems that can both edit the same field will, sooner or later, disagree.

Draw a simple map before you sign anything. A typical starting point:

• Room inventory: the PMS (or the CRS in a group). The channel manager follows.
• Rates and restrictions: wherever your revenue decisions are made, usually the PMS or a revenue tool. The channel manager distributes them.
• Guest profile: the PMS, unless a separate guest database is designed to be the master.
• Payments and folio: the PMS and the payment gateway, with accounting following.
• Content and photos: the channel manager or a content tool, copied to each site.

Imagine a 20-room hotel where the revenue manager lowers a weekend rate in the channel manager, while the PMS pushes its own, higher rate every night. Each system is behaving as built, and guests see the old price again by Monday. Nobody made a mistake; two systems were both allowed to be right.

Write the map on one page and keep it with your supplier contracts. When a staff member changes a rate in the wrong place and the next sync overwrites it, the map tells you which system should have been edited. It also tells you quickly which supplier to call.

Every hotel has one truth per field. The job of integration is to make sure the other systems believe it.

Why do integrations get complicated as you grow?

Direct links between systems multiply faster than the systems do. Connect every system to every other one and the number of links is the number of systems times one less, divided by two. Four systems need up to 6 links. Eight need up to 28. That is arithmetic, not a market statistic, and it explains why a hub is easier to manage than a web.

This is also why standards exist. AltexSoft describes HTNG as the closest thing hospitality has to a regulator, with specifications that cover back-office integration, distribution and payments, most built on OpenTravel's schemas. Without a shared format, systems represent the same data differently, so the same information may not land in the same field. The article also notes that legacy hotels and small businesses need real technical and organisational expertise to apply the standards.

The practical lesson for a small hotel is to skip learning the standards and prefer suppliers that publish an open API or work to recognised specifications, and to treat a closed system that connects to nothing as a future migration cost.

What should you test before going live?

Test the links with real transactions before your first guest depends on them. A demo will not tell you what a bad Saturday does. Keep in mind that several of the explainers behind this post come from software suppliers or trade publications, so they describe how the pieces ideally connect. Your contract and a live test show how your own pieces behave.

Run this checklist:

1. Make a booking on a channel and confirm it appears in the PMS, with the right rate and room type.
2. Cancel it and confirm the room reopens on every channel.
3. Close a date in the PMS and confirm every site shows it closed.
4. Change a rate in one place and see how long it takes to arrive everywhere.
5. Break something. Switch off the connection and see what the systems show, and what alert you receive.
6. Check the error log. Who sees failed syncs, and how quickly?

Then ask the questions suppliers rarely volunteer. Who is responsible when a sync fails? What is the typical sync time? Is there an extra fee per connection? Can you export your data if you leave? Our article on the guest journey in a hotel is a useful companion, because every handover above is a moment your guest feels.

Key takeaways

• A PMS runs a property, a CRS holds stock across properties, a channel manager distributes to selling sites.
• A single independent hotel can often manage without a CRS.
• Prefer two-way connections for availability, rates and payments, and ask what flows each way.
• Draw a source-of-truth map for each important field and keep it with your contracts.
• Fewer, better-chosen connections beat a web of direct links.
• Test with real bookings, cancellations and an outage before going live, and watch the error log.