How to choose a hotel booking engine: questions to ask providers

A hotel booking engine is the checkout on the hotel's own website: it shows live availability and rates, takes the booking and the payment, and writes the reservation into the hotel's system. Choose one by asking what it shows before payment, which payment methods it takes, whether it reads the same inventory as every other channel, and how you leave.

The hotel's own website is the one channel where the hotel sets the price, keeps the guest relationship and the guest's data, and pays no commission to a booking site. Then the guest taps book, and a checkout screen decides whether the sale happens or the guest goes back to a booking site. This article gives you the questions to ask a booking engine provider, in order, so you can compare answers instead of feature lists.

What must a hotel booking engine actually do?#

It turns a visitor on the hotel's website into a confirmed, paid, recorded reservation, without selling a room that is already gone. That is four jobs, in order: show live availability and the correct price for the dates, hold the room while the guest pays, take the payment or a guarantee, and write the reservation into the hotel's system with its rate plan and cancellation terms attached.

It is not the hotel management system and not the channel manager. The management system holds the rooms and the bill, the channel manager pushes availability and rates to other channels, and the engine is the checkout on the hotel's own site. If you are unsure where the boundaries sit, see PMS vs channel manager vs booking engine: what each one does.

Ask where availability comes from: a live read of the hotel's own inventory, or a separate calendar someone updates by hand. The second one sells the same room twice. Ask what happens when a guest abandons payment: does the hold expire on its own, does the room return to inventory, and how quickly. Ask whether the engine can sell the hotel's own extras, such as an upgrade, breakfast or late checkout, inside the same booking, and whether the accepted extra lands on the guest's bill.

Ask for the demo on your own rate plans, not a sample property. Minimum stays, closed-to-arrival dates, child pricing, extra beds and a rate that changes by season are where sample demos fall apart.

Does it show the total price and the pre-contract information before the guest pays?#

It must. Under the Distance Contracts Regulation (Mesafeli Sözleşmeler Yönetmeliği, consolidated text, Articles 5 and 6) (opens in a new tab), a consumer booking at a distance has to be told the total price including all taxes before the contract is made, and on a website the main features, the total price and the withdrawal information must appear together and clearly immediately before the guest commits to pay.

Total means total: room, breakfast if it is inside the rate, taxes, extra bed, parking, and anything compulsory. A price that grows at the payment step is a frequent complaint and, under the rule above, a legal exposure. The three blocks belong on one screen, visible together, not spread across tabs or hidden behind a link at the bottom of the page.

On withdrawal, one line is enough for the engine: unless the parties agree otherwise, the 14-day right does not apply to accommodation to be performed on a specific date or period, and the pre-contract information must tell the guest this; package tours sit outside the regulation. Cancellation and change terms should sit next to the price, in the guest's language, and match word for word what the confirmation email will say. For the wording itself, see Hotel cancellation policy: how to write clear, consistent terms.

The regulation sets the duty; your rate plans decide how it lands on your screen. Confirm your own case with a lawyer or your accountant before you sign.

Which payment methods, currencies and deposits should it take?#

The ones your guests actually use: local and foreign cards, the wallet payments a phone offers, the currencies of your source markets, and a clear choice between prepayment, a deposit and paying at the hotel.

Ask which card verification step the engine supports, the extra confirmation screen the guest's bank shows, and whether the hotel or the provider carries the risk when a payment is disputed. Ask which card-data handling standard the provider meets and who holds the certificate; do not accept the word secure as an answer. Installment rules and costs differ by bank and card type, so confirm them with your acquirer rather than trusting a feature list.

If you price in euro for a foreign market, ask which exchange rate the engine uses and at what moment it is fixed. Central-bank rates are published daily, not hourly. Deposit, full prepayment and pay-at-hotel each shift the no-show risk and the refund work, so write down which one applies to which rate plan and make sure the engine shows it before payment.

Failed payments deserve their own question: what the guest sees, whether the hold is released, and whether the room returns to inventory or stays blocked for the rest of the day. Ask what appears on the guest's card statement; an unfamiliar descriptor produces chargebacks that cost more than the booking.

Does it sell the same rooms and rates as every other channel?#

It should read one inventory and one set of rate plans, so a room sold on the website disappears from every other channel and a stop-sale reaches the website as fast as it reaches a booking site. Ask which system is the source of truth for availability and rates, and who writes to whom. Two systems that both believe they are right will disagree on a busy night.

Restrictions must travel with the rate: minimum stay, closed to arrival, closed to departure, and release periods. An engine that ignores a minimum-stay rule sells a one-night stay the hotel did not want. Ask what happens when the connection fails: does the engine keep selling on the last known availability, and for how long before someone notices. Ask how the reservation reaches the hotel's management system, and what the hotel sees on screen when that write fails.

Rate parity and the terms you have signed with other channels are a separate question for your adviser. The engine's job is to obey the rules you set, everywhere at once.

Does it work on a phone in your guests' languages?#

Your guests will often meet the engine on a phone, so test it there, in the languages of your source markets, with a real date and a real card. The whole path should work with one thumb: dates, room choice, guest details, payment, with no pinch-zoom and no sideways scrolling. Fields should call the right keyboard, numbers for dates and card details, and the name field should accept the guest's name in Cyrillic or Arabic characters if your markets need it.

Machine translation reads wrong on cancellation terms and pre-contract information, so have a person check the legal blocks in every language you sell. Date and price formats differ by market: a date written 05.03 is read as May in one country and March in another, and a price shown as 1.250 can mean one thousand or one and a quarter. Ask whether the engine can show a price in the guest's currency while the hotel keeps its own currency in the accounts, and which rate it uses to convert. For planning the language side, see Multilingual hotel service: a language plan for your guest mix.

How do you see where bookings come from, and what does the guest receive?#

Every booking should arrive with its source attached, and the guest should receive a confirmation that repeats the price, the cancellation terms and a way to change the booking. Source tracking starts with a small tag added to the link that brought the guest in, so the booking record shows which page, campaign or search result produced it. Without it every direct booking looks the same and you cannot tell what works.

The confirmation email is part of the contract: price, what is included, cancellation terms, hotel address and contact, and the statement about withdrawal. Ask whether the guest can cancel or change from that email, and whether the action updates the hotel's management system and the other channels at the same time.

Reconcile once a week: engine bookings against the management system's records. Differences usually come from a failed write, a duplicate submission or an abandoned hold that was never released. Check the no-show path too: who marks it, and whether the guarantee is charged from the engine or by hand at the desk. The engine cannot fix a website that never explains what the hotel is; content and legal pages feed the same path, and a good checkout on a thin page still loses the booking.

What should the contract cover: pricing, data and exit?#

Three things decide the real cost: what counts as a billable booking, who owns the booking and guest data, and what happens on the day you leave. Pricing models are commission per booking, a fixed subscription, or a mix of both. Commission scales with revenue and costs nothing in a quiet month; a subscription is predictable but is paid whether the website sells or not.

Ask what counts as a booking: cancelled bookings, modified bookings, no-shows, and reservations your own staff entered by hand. On data, ask who owns the reservation and guest records, in which format they can be exported, and how quickly after a request. On exit, ask the notice period, how long the engine stays live after termination, whether old links redirect somewhere sensible, who holds the domain and the analytics, and whether the guest data leaves with you.

Ask about service levels and price changes: what the provider promises about uptime and support response, and how much notice before a price rise. Ask for the contract before the demo, and read the exit clause first. It is the clause you will need on the worst day.

What to do next#

Send the same written questions to every provider and compare the answers side by side, because a feature list cannot be compared but an answer can. Then, before signing, run the two-change test and complete one booking on a phone with your own rate plans. Price transparency is a legal duty, one inventory is an operational one, the phone and the languages decide the sale, and the contract decides how you leave.