A six-person apartment in Athens or a villa on Naxos does not cost exactly the same to serve when two guests stay as when six arrive. Yet many Greek operators publish one nightly price for every valid occupancy. That keeps rate management simple, but it can also make the property look expensive to couples or leave too little margin when a full group books.
Booking.com occupancy-based pricing is designed for this gap. It lets eligible properties and their connectivity providers publish different prices for different guest counts. Used carefully, it can widen demand without turning every low-occupancy booking into an automatic discount. Used carelessly, it can create a confusing rate ladder, weaken peak-date revenue, or fail to cover variable costs.
This guide explains the pricing models Booking.com documents, shows an original worked example for a Greek rental, and gives hosts a practical test plan. It is operational guidance, not a promise of visibility, conversion or revenue. Availability and implementation can vary by property configuration, account and connectivity provider.
What occupancy-based pricing actually changes
Booking.com distinguishes inventory from availability. Inventory is what the property offers for sale, including room types, rate plans, restrictions and prices. Availability is the part a traveller can book for a particular search. Guest count matters because a room that sleeps six is not available to a seven-person search—and its price can also differ between a two-person and six-person search.
In its official Rates & Availability documentation, Booking.com lists four pricing types: Standard, derived or Rate-Level Occupancy pricing, Occupancy-Based Pricing, and Length of Stay pricing. Standard pricing centres on the maximum-occupancy price. The other models can support pricing per guest, but they work differently and may require specific technical support or certification.
| Pricing type | Basic logic | Useful when | Main risk for hosts |
|---|---|---|---|
| Standard | One main price tied to the room’s maximum occupancy | Simplicity matters more than guest-count precision | Couples may see the same price as a full group |
| Derived / RLO | Other occupancies are derived from a base occupancy | You want a consistent ladder from one base rate | A bad offset repeats across many dates |
| Occupancy-Based Pricing (OBP) | A price can be supplied for each supported occupancy | Variable costs and demand differ materially by guest count | More values must be mapped, monitored and tested |
| Length of Stay (LOS) | Price can vary by both occupancy and stay length | Stay-pattern control is central to the revenue strategy | Greater complexity and limited provider support |
Booking.com says pricing types and connectivity functions can carry technical requirements. Its pricing-type configuration guidance recommends using a single pricing type across the property and notes certification requirements for OBP and LOS. A host should therefore confirm what is enabled in the Extranet and what the connected property-management system or channel manager actually sends.
The Greek-host question: discount the smaller group or surcharge the larger one?
Those descriptions sound similar, but the commercial starting point is different.
- Low-occupancy discount: Start with the price you want from a full group, then reduce the rate for fewer guests.
- Extra-guest recovery: Start with the commercially viable price for a couple or base occupancy, then add measured increments as guest count rises.
The second framing is often safer. It forces the host to define a profitable base rate before adding guest-related costs. The goal is not to charge every extra towel separately. It is to produce a coherent price ladder that reflects cleaning time, linen, laundry, utilities, consumables, wear and sometimes local operating constraints.
Fixed costs—rent or financing, insurance, software and basic management—do not disappear when only two guests stay. That is why a six-person home should rarely be sold to two people at one third of the six-person price.
A worked rate ladder for a Greek apartment
Consider an illustrative two-bedroom apartment that sleeps four. The figures below are a calculation example, not market data or a recommended tariff. The host’s public base price for two guests is €132. The model adds €12 per additional guest because the host estimates incremental linen, laundry, utilities and consumables, while keeping the fixed operating contribution inside the base price.
| Guests | Published nightly price | Estimated variable guest cost | Price less variable cost |
|---|---|---|---|
| 1 | €126 | €9 | €117 |
| 2 | €132 | €16 | €116 |
| 3 | €144 | €24 | €120 |
| 4 | €156 | €32 | €124 |
Illustrative chart: nightly price by guest count
1 guest €126 █████████████████████ 2 guests €132 ██████████████████████ 3 guests €144 ████████████████████████ 4 guests €156 ██████████████████████████
The chart shows a gentle staircase, not a cliff. A couple sees a meaningfully lower price than a four-person group, but the property still earns enough to cover fixed costs. The one-person price is only slightly below the two-person price because many turnover costs are almost identical.
What to calculate before copying the structure
- Separate fixed nightly contribution from costs that genuinely rise with each guest.
- Measure linen and laundry by occupied bed, not only by head count.
- Include additional cleaning time when larger groups reliably extend a turnover.
- Model commission and payment costs using the terms that apply to your own account.
- Check VAT, taxes and fees with a qualified Greek adviser; their treatment depends on the operator and accommodation setup.
- Compare the final displayed price, not only the base room rate.
If the base price is already too low, guest increments will not repair the model. Start with the economics, then build the ladder.
Why a lower two-person rate can work in Greece
Greek holiday rentals often serve mixed demand. The same apartment may attract couples during the shoulder season, a family in July, and friends around a city event. One maximum-occupancy price can be defensible on dates when demand is strong. On softer dates, however, it may price the apartment outside a couple’s comparison set.
This is especially relevant when travellers filter and compare across apartments, aparthotels and hotels on Booking.com. A couple does not care that your home can sleep six if its displayed total is far above a well-reviewed double room. A controlled lower-occupancy rate can make the comparison fairer while keeping a larger-group price available.
That does not mean lowering prices everywhere. Pair guest-count logic with the seasonal framework in our Greek shoulder-season pricing playbook. Peak island weekends, August availability and high-compression event dates may need little or no low-occupancy reduction. The same property can use a narrower ladder in high demand and a wider one in need periods, if its system supports the setup correctly.
The channel-manager check most hosts skip
A setting visible in a property-management system is not proof that Booking.com is receiving every intended value. Booking.com’s Connectivity API overview says partners can manage rates, availability, reservations and other property functions, but it also encourages properties to check Booking.com-specific details in the Extranet.
Ask the provider these exact questions:
- Which Booking.com pricing type is configured for this property?
- Can the system send a separate amount for every occupancy, or only derive offsets?
- Do child rate plans inherit price, restrictions, policy and open/closed status from a parent?
- Can promotions or mobile rates apply on top of the occupancy price?
- What happens when an occupancy value is missing?
- Can support show the latest successful rate-and-availability update for a test date?
Booking.com’s documentation on room rates and rate relations explains that child rates may follow a parent’s price, restrictions, policy and status. That inheritance is useful, but it is also why changing one parent rate can have wider effects than expected.
If you distribute across more than one OTA, review how your stack handles inventory and rate mapping. Our guide to Booking.com versus Airbnb in Greece explains why the same property may need different merchandising and pricing logic on each channel.
A seven-day test without risking the whole calendar
Do not roll a new guest-count ladder across the year on day one. Use a controlled validation window.
- Select low-risk dates. Choose seven to fourteen dates outside a peak period, avoiding dates with existing reservations.
- Choose one room and one refundable rate. Keep the test surface small.
- Load three or four occupancies. Use simple, explainable increments.
- Search like a guest. Test one, two, three and maximum occupancy in a private browsing session, using the same dates and market.
- Record the displayed total. Include taxes, fees and any promotion visible to the traveller.
- Check the Extranet. Confirm each guest count and rate plan, rather than relying only on the PMS screen.
- Watch the right metric. Compare search impressions, conversion, average nightly rate and contribution after variable costs—not occupancy alone.
Run the test long enough to capture realistic searches, but stop and correct it immediately if the wrong occupancies, prices or restrictions appear. If you have recently experienced mapping problems, use the control principles in our channel-manager outage drill for Greek hosts before widening the rollout.
Three mistakes that destroy the benefit
1. Letting discounts stack unnoticed
The occupancy price is only one layer. Mobile rates, country rates, campaigns, loyalty discounts or derived child plans may affect the amount a guest sees. Audit the final bookable total for each test search. Terms and stacking behaviour can vary by promotion, account and date.
2. Making the staircase too steep
If two guests pay €120 and four guests pay €200 for the same apartment, groups may perceive the difference as punitive unless the value and costs support it. Large jumps can also shift demand toward awkward occupancy combinations. Use measured increments and review conversion by party size.
3. Ignoring payout and cash-flow reality
A price that looks profitable before commission, payment handling, refunds and timing may feel very different in the bank account. Reconcile the model against your own statements and read our explanation of how Booking.com money reaches Greek hosts.
The decision rule
Occupancy-based pricing is worth testing when your property accommodates meaningfully different party sizes, variable costs rise with head count, and your systems can transmit and verify the complete rate ladder. It is less useful when nearly every booking uses the same occupancy, your pricing stack cannot map the model reliably, or peak demand already supports one strong price.
The best setup is not the most complicated. It is the simplest rate structure that protects contribution, makes sense to travellers and remains verifiable in Booking.com. Begin with one profitable base occupancy, add evidence-based increments, test the guest-facing total, and expand only after the data proves the ladder is helping.
