What a CRS is: central reservations for hotels and hotel groups

A hotel CRS, or central reservation system, is the sales-side record of what a hotel or hotel group may sell: room types, rates, restrictions, negotiated agency and corporate agreements, and the reservations that arrive from every source. It sits above the property systems that run the building and below the channels that sell it.

A group reservations office confirms a room by phone while the front desk at the property is selling the last one. Both systems show the room as free, because both believe they own it. That is the problem a CRS is meant to solve, and the problem it creates when it is added without a rule. After reading this you will be able to place a CRS correctly in your stack, decide whether you need one, and write down the one rule that keeps it from selling a room twice.

What is a CRS in a hotel?#

A CRS is the record of the sellable product at sales level: which room types may be sold, at which rates, under which conditions, to whom, and which reservations have already been taken. It holds things a property system usually does not: rate plans that apply across several buildings, negotiated rates for travel agencies and corporate accounts, length-of-stay and closed-to-arrival restrictions, and reservations that are not yet tied to a physical room.

It does not check anyone in, assign a room, schedule housekeeping, close the business day or produce a bill. Those belong to the property management system (PMS), the software that runs the building. A reservation in a CRS is a promise about a room type, not a room number; the room number appears only when the property system assigns it.

Three different products get called a CRS by different sellers: the sales record itself, the guest-facing booking page (the booking engine) and the messenger that pushes rates and availability to channels (the channel manager). Naming them separately prevents most buying mistakes. A useful test: ask what the system would still do if the building closed tomorrow. A CRS would still hold rates and take bookings; a PMS would have nothing to run. Because the CRS is the sales record, it is also where a group's commercial rules live: who may sell, at what price, with which deposit and cancellation terms.

The four systems, in one table#

For more on how these pieces differ, see PMS vs channel manager vs booking engine: what each one does.

CRS vs PMS: what is the difference?#

The PMS runs the building; the CRS runs the sellable product. A reservation crosses from one to the other once, while availability crosses back continuously. Reservations and their conditions travel down from the CRS to the property system; availability, restrictions and stop-sells travel up from the property to the sales layer.

The boundary blurs in practice. Check whether your PMS already bundles a booking engine and a channel manager; if it does, a single property gets CRS-like functions without buying a separate CRS. What a PMS alone handles badly: a rate contract for a travel agency that covers five properties, a central phone line that must quote and hold rooms in three buildings, or a booking taken while a property system is offline for maintenance.

Every handoff is a place where a message can be delayed, duplicated or lost. The fewer handoffs, the fewer ways to sell one room twice. For a group, the pattern is usually one CRS above several property systems, not one large PMS pretending to be both. How the core systems fit together is covered in more depth in Hotel technology stack: how the core systems fit together.

Which system holds the guest record?#

Does a single hotel need a CRS?#

Usually not as a separate product. One property with one inventory can hold its sellable rooms in its PMS, publish them through a channel manager and sell them through a booking engine. What a single hotel actually needs is one inventory, a shopfront, a messenger to the channels, and a written rule about which system owns availability.

A separate CRS starts to pay when a second property appears, when a central reservations line serves several buildings, when agency and corporate rates are priced centrally, or when one booking path must cover more than one brand. Adding one early has a real cost: a second inventory to keep in step, a second place to change a rate, a second set of user accounts, and a new failure mode between the two systems.

Signs you have outgrown the combined setup: the same rate change is made twice, the reservations office keeps its own spreadsheet, agency rates are quoted from memory, or a group enquiry needs three phone calls to answer. A middle path exists: keep the PMS as the record and add a central reservations office that works inside it, before buying a separate sales system. Whatever you choose, the decision is about who owns availability, not about how many products you own.

How does a hotel group use a central reservations office?#

A central reservations office (CRO) is one team that takes bookings for several properties through one path, quoting from centrally held rate rules and routing each confirmed booking to the right property system. It handles what a single front desk cannot: phone and email enquiries that do not name a property, agency requests covering several buildings, and group blocks that may move between them.

What must live centrally: rate plans, negotiated agency and corporate rates, deposit and cancellation policies, commission rules, and the list of who may override a price. What should stay at the property: room assignment, stop-sell for a specific date, allotments released on a schedule, and local packages built from what the building can actually deliver. The booking path needs one entry point and one confirmation the guest can hold, even when the answer comes from three property systems in sequence.

Reporting is the quiet benefit: pickup by property, production by agency, and the source of every booking, all read from one place instead of assembled by hand. The CRO is a team and a rule set before it is software; buying a system without agreeing the rules produces a faster version of the same arguments. For example, if the central office may quote a corporate rate but only the property may release rooms from a block, that split must be written down before the first call.

As one illustration of how this can be built: AI Otel's hotel operating system is built to run single hotels and groups from one login, with travel agents and corporate clients booking through their own portals. It is built and working, ahead of launch.

What to centralize, what to leave at the property#

Who owns availability, the CRS or the PMS?#

Exactly one system owns availability. Every other system holds a copy with an expiry date, and when the copy expires the room returns to the owner. The rule exists because two systems that each believe they own the inventory will eventually sell the same room twice, or hide a room that is free.

A copy is a hold or an allotment: a number of rooms set aside for a channel, an agency or a sales office for a stated period. When the period ends, the unsold rooms go back automatically. Choosing the owner: for a single hotel, the system closest to the physical room, which is the PMS. For a group selling across properties, the CRS can own the sellable pool while each property holds an allotment.

Write the decision down and keep it where both teams can see it. Most double-selling arguments are disagreements about a rule nobody wrote. Run a daily check at a fixed hour: compare what the owner says is free with what each channel shows for the same dates. A difference is a message that did not arrive. Symptoms of a broken rule: rooms blocked that nobody can sell, a booking that exists in one system and not the other, or a rate that changes in one place and not the next. The mechanics behind these failures are covered in Hotel double bookings across channels: causes and prevention.

What should you ask before adding a CRS?#

Ask who owns availability, how fast a change travels, and what happens when the link between systems is down. The answers decide whether the purchase reduces work or adds a second inventory to manage.

Start with ownership: which system owns availability, and is that written into the contract and the setup, not just agreed in a meeting? Then test speed: how fast does a rate or restriction change reach every channel, and how do you confirm it arrived rather than assume it? The messages behind that question are explained in How a channel manager connection works: messages, delays and errors.

Ask what happens when the connection fails: does the property keep selling, who reconciles the bookings afterwards, and how are duplicates found? Ask how a cancellation returns to inventory, and how long it takes before the room can be sold again. Ask who can override a rate or release a block, and whether every override is logged with a name and a time. Ask how group blocks and allotments are released, on what schedule, and who can extend them. And ask about exit: can you export every reservation, rate and agreement in a usable format, or does your history stay behind?

What to do next#

Write one page that names the system owning availability, the system holding the guest record, and who checks the two against each other each day. A CRS is a sales record above the building, a PMS is the building, and the whole design only works when one of them owns the inventory and the other holds a copy that expires. If you want to see how a single system can carry both sides, you can request a briefing.