Per-person pricing on booking sites: setting occupancy-based rates correctly

Occupancy-based pricing means the booking site holds a separate price for each number of guests in the room, not one room price. In Booking.com's connectivity documentation it is one of four pricing types, alongside standard, derived and length of stay, and it requires an absolute price for every room type, rate plan, date and occupancy.

A guest books a double room for one person and pays the full double rate. Weeks later a family of three arrives on a reservation made for two, and the third bed is free. Both are the same fault: the rate sheet prices people, the booking screen prices rooms, and nobody translated between them. This article shows how the pricing models on booking sites work, how to convert a per-person rate sheet into each of them, what to demand from a channel manager, and how to test every occupancy before a guest ever sees a wrong price.

Why does per-person pricing break on booking sites?#

Because the rate sheet prices the guest and the booking screen prices the room, and the two only meet if someone converts every occupancy into an explicit price.

A resort that quotes per person per night works with a single supplement, a third-adult reduction and child bands on top. A booking site's rate plan normally starts from a room price for a defined number of guests. These are different objects, and neither one converts itself.

Three failure modes repeat. A single traveler pays the double rate because no one-adult price was ever sent. A third adult is priced at nothing because only the maximum-occupancy price exists. A child is charged as an adult because the age bands were never mapped.

The rate sheet is usually correct. The fault sits in the translation layer, which is why the same rate sheet can produce correct prices on the hotel's own website and wrong ones on a booking site. The damage appears later than the mistake: at the front desk when a reservation for two turns out to be three people, in the confirmation the guest compares with your direct price, and in the occupancy mix of the night's business.

Translation starts with an unambiguous source document: a hotel rate sheet with seasons, supplements and reductions in one table. One table, one term for one concept. If the rate sheet says both "single supplement" and "single difference", the mapping will too.

Booking.com's connectivity documentation, "Implementing pricing types" (2026-11-04) (opens in a new tab), is a detailed public description of how a booking site handles occupancy, so this article uses it as the worked example. The same questions apply to any site whose rate plans you maintain.

Which pricing models do booking sites offer?#

Booking.com's connectivity documentation describes four pricing types: standard, derived (also called rate-level occupancy), occupancy-based and length of stay. Each one sets prices from a different starting point, and each one asks a different amount of work from the hotel.

Standard pricing means you set a default price for the maximum number of adult guests, plus a price for one adult. A single room takes only the maximum-occupancy price, so a single room cannot carry its own one-person price under this model.

Derived, also called Rate-Level Occupancy (RLO), means you set a base-occupancy price and give offsets, as a percentage or a fixed amount, for the other occupancy sizes. It is compact to maintain, but every other occupancy is a formula result rather than a decision.

Occupancy-Based Pricing (OBP) allows no offsets. You must give an absolute price for every combination of room type, rate plan, date and number of occupants. It gives the most control and creates the most rows to send.

Length of Stay (LOS) pricing depends on check-in date, number of occupants and number of nights, which suits properties whose per-person economics change with stay length.

The choice is a maintenance decision as much as a pricing one. If your single supplement is a fixed percentage in every season, derived is cheap to keep correct. If it moves by season, by date or by room type, derived will drift and occupancy-based pricing is the honest model. Standard pricing is the simplest model, and it leaves the single traveler exposed, because the only one-adult price it accepts is a single figure rather than a price per occupancy.

What happens when you change the pricing type?#

The documentation warns that changing a pricing type removes all existing prices for the affected room-rates, and every price must then be sent again.

The removal is not a partial edit. All prices for the affected room-rate combinations are gone, and the site has nothing to sell until the new set arrives. When switching to or from occupancy-based pricing or length-of-stay pricing, closed dates, restrictions and inventory must also be set again, so the work is wider than the price file.

Treat a switch as a project with a window, not as a setting someone flips on a Friday afternoon before a holiday weekend. Export the current mapping and the current price file before the switch, so the old state can be compared with the new one line by line. Tell the market manager and the channel manager vendor the date and the target pricing type in advance; the vendor needs to know which format it must send.

Plan the re-send in the same order every time: inventory, then closed dates and restrictions, then prices, then a read-back test.

How do you translate a per-person rate sheet into occupancy prices?#

Convert every line of the rate sheet into an absolute price for each occupancy you actually sell, then check the arithmetic by hand against the rate sheet before anything is sent.

One adult: the per-person price plus the single supplement gives the one-adult price. Decide once whether the supplement is a fixed amount or a percentage of the double rate, and whether it is constant across seasons or set per season. Two adults is normally the per-person price with no supplement, and it is the anchor every other occupancy is compared against.

Third adult: the per-person price minus the third-adult reduction. If the reduction brings it to zero, that is a commercial decision and must be sent as an explicit zero price, not left blank for the site to guess. Children: each age band needs a rule the rate plan can express, covering free places, the extra bed charge and the maximum number of children per room. The booking site's child policy and the rate sheet must say the same thing, band by band.

Rounding deserves one decision, not many. Fix one rounding rule, apply it in the rate sheet, and let the channel manager carry the result unchanged. Rounding inside the channel manager creates a second source of truth that drifts with every season.

For example, a rate sheet says 100 per person per night, a 30 percent single supplement, a 25 percent third-adult reduction and children under 6 free. One adult becomes 130, two adults 200, three adults 275, and two adults with a 4-year-old stays at 200. The same four figures have to appear on the booking screen for that date. Keep the child rules, as in a hotel child policy with age bands, free places and extra beds, in one place and reuse them across every rate plan; a policy written twice will disagree with itself by the second season.

What must the channel manager carry?#

It must be able to send a price per occupancy, not only a price per room type, and it must map each occupancy to the right rate plan on the right site.

Ask the vendor directly which pricing types it supports on the sites you sell, and which type it assumes by default. A tool that only sends room prices will silently collapse your per-person ladder into one figure. This question belongs in the same conversation as the broader channel manager mapping of room types, rate plans and testing.

Mapping has four dimensions, not two: room type, rate plan, occupancy and board. A rate plan that mixes occupancies will produce correct prices on some dates and wrong ones on others, which is harder to spot than a consistent error. Ask whether restrictions can be applied per occupancy; if a minimum stay or a closed-to-arrival rule can only be set for the room type, a third-adult price cannot be closed on its own.

Confirm what happens to prices already sent when the mapping changes, and whether the tool can re-send a full price set on demand rather than only on change. Test the round trip: send a price, read it back from the site, and compare with the rate sheet. A tool that reports success is not the same as a site that displays the right number. Write the mapping down and keep it with the rate sheet, so the next person to change a season can see which occupancy becomes which rate plan.

How do you test every occupancy before opening sales?#

Test each occupancy on sample dates across seasons, in every rate plan, and compare the price the site displays with the rate sheet to the last unit.

Choose sample dates deliberately: one low season, one shoulder, one high season, one public holiday and one date carrying a minimum-stay rule. On each date, price one adult, two adults, three adults, the maximum occupancy, and two adults with one child in each age band.

Check a one-night and a three-night stay separately, because length-of-stay rules and weekend supplements can change the total without changing the nightly price. Check the single room or single-use room on its own; under standard pricing it will only carry the maximum-occupancy price, and you need to know that before a guest discovers it.

Check what the site does when the last room at two-adult occupancy is sold, and whether the three-adult price remains available. Follow one test reservation all the way through: confirmation, reservation record, occupancy field and price in the property management system. A correct display with a wrong record is still a wrong booking. Repeat the whole set after any pricing-type change, any season change and any rate plan added.

How do you keep ADR reporting clean when guests pay per person?#

Split the per-person price into a room component and a board component before you divide, because average daily rate compares room revenue with rooms sold, not with guests.

Average daily rate is room revenue divided by rooms sold. When the rate includes board, the figure is not comparable with a room-only market and should not be presented as if it were. The same logic is explained in more depth in ADR in all-inclusive hotels: separating room and board revenue.

Occupancy-based pricing makes the split visible: a third adult adds board and an extra bed, not another room, so the extra-adult amount belongs in the board column, not the room column. Decide the split at the rate-sheet level, keep it constant across seasons, and carry both components into the property management system so the report is built from stored values rather than from an assumption.

Keep the guest count next to the room count in every report, so a rise in revenue per room can be read against the occupancy mix that produced it. Reconcile monthly: rooms sold from the system against rooms sold from the booking sites, and room revenue against the split you defined.

What to do next#

Take one room type and one season from your rate sheet and build the occupancy ladder by hand: one adult, two, three, maximum, and each child band. Then check whether your channel manager and the site's pricing type can carry those exact figures. If they cannot, change the pricing type in a low-season window, re-send inventory, restrictions and prices in that order, and run the occupancy test set before sales reopen.