Hotel booking technology: how the booking layer fits together

Hotel booking technology is a layer, not a product.

Hotel booking technology is usually sold as one thing and delivered as four. A booking engine sells the room on the hotel’s own website. A channel manager distributes the same room to online travel agencies, metasearch and the GDS. A property management system records the stay and, in most hotels, holds the inventory everything else is selling against. A payment provider handles the card. Some suppliers cover two or three of these; few cover all four equally well.

The distinction matters because the parts fail differently and should be judged differently. A booking engine is judged by guests. A channel manager is judged by whether the numbers going out match the numbers coming back. Comparing them as one category is how a hotel ends up with a polished checkout sitting on a connection nobody monitors.

The same room reaches a guest by two routes.

A guest looking at your hotel is served by one of two systems: your own booking engine or an online travel agency. The room is identical. Almost everything around it is not.

This is not an argument for switching distribution off. Channels create reach a single property cannot buy, and in a soft month that reach is worth paying for. The narrower point is that only one of the two routes leaves the hotel holding a record it can use again, and hotels that treat the routes as interchangeable usually discover the difference after the guest has left.

Ask which system is authoritative before comparing features.

The phrase “integrates with” describes a possibility, not an operating arrangement. Before comparing feature lists, settle which system is authoritative for availability, for rates and for restrictions. Those three are not always the same system, and a hotel that cannot answer for all three will eventually have two systems disagreeing about a sold-out night.

Then establish the shape of each connection. A one-way push that sends availability out but cannot accept a reservation back is a different product from a two-way link, even when both are described as an integration. Ask how reservations arrive, how modifications and cancellations travel, and whether a modification arrives as a modification or as a cancellation followed by a new booking.

Standards help, but only so far. The OpenTravel Alliance publishes message specifications the travel industry uses for availability, rates and reservations, and many suppliers implement them. Two systems that both support the same specification can still disagree about what a rate plan is. Treat a standard as the reason a connection is possible, not as evidence that it is configured correctly for your property.

• Which system is authoritative for availability, rates and restrictions.
• Whether each connection is one-way or two-way, and in which direction.
• How reservations, modifications and cancellations are delivered.
• Who maintains the mapping between room types and rate plans.
• How quickly a sold room disappears from every other channel.
• Who is alerted when a connection fails, and how quickly.

Decide early who holds the card.

Payment design shapes both risk and daily workflow. PCI DSS, published by the PCI Security Standards Council, applies to any entity that stores, processes or transmits cardholder data. The practical question for a hotel is how much of that data ever touches its own systems. A flow where the card is captured and tokenised by the payment provider keeps far less in scope than one where staff retype card numbers into a property management system.

Deposits, guarantees and refunds are separate decisions again. Agree who charges the card and when, what happens to a deposit on cancellation, and how a refund is issued when the booking arrived through a channel that paid by virtual card. Write these rules down before launch. Settled case by case, they become guest complaints.

Guest data has the same problem in a quieter form. A direct reservation normally arrives with a usable email address. A channel reservation may arrive with a relay address that stops working after the stay. If your pre-arrival, follow-up or loyalty workflow assumes a real address, confirm what actually arrives before building on it.

Most booking technology fails quietly.

Outages get noticed. The expensive problems are the ones that keep working while being wrong: a rate that stopped updating on one channel, a new room type that was never mapped, a restriction that applies in the wrong time zone. None of these produces an error message. They produce a disappointing month.

Build a short weekly check instead of waiting for a guest to find the defect. Comparing what you intended to sell against what each channel is actually showing takes minutes and catches most of the list below.

What to ask a supplier before signing.

A demonstration shows a working configuration on a good day. The useful questions are about the days that are not good, and about what happens when you want to leave. Ask for answers in plain language, and treat anything that needs a follow-up call as still unanswered.

Scope the commercial terms with the same care. Booking technology is priced in several incompatible ways—per booking, per room, per month, or as a share of direct revenue—so the cheapest headline is not always the cheapest year. Model your own volume against each structure before comparing quotes.

• Which systems this product replaces, and which it assumes you already run.
• What the connection does when the other side is unavailable.
• How long a sold room takes to disappear from every channel.
• Whether the hotel can export rates, restrictions, reservations and guest records.
• Which party holds card data and which carries the PCI responsibility.
• What the total annual cost looks like at your actual booking volume.