Group-level pricing without the spreadsheet: room-type occupancy adjustments for multi-room hotels
Eight of your ten Double Rooms are booked for next Saturday. Your Single Rooms are only half full. If your pricing runs off one blended occupancy number for the whole property, neither fact shows up anywhere, the Double Rooms sell out at a rate that never adjusted for how close they were to a sellout, and the Singles sit priced as if they were as full as the Doubles.
The usual fix is a spreadsheet: someone checks sell-through by room type a few times a week and manually nudges rates when one category is clearly outselling the others. It works, until the property has more than a couple of room types, or nobody has the hour a week to keep the sheet current, the same limit that shows up across most manual approaches to hotel price management once a property grows past a handful of listings.
PriceLabs has a setting built to do this automatically: Multi-Room Occupancy-Based Adjustments, tracking sell-through separately for each room type instead of one number for the whole property. The rest of this article covers how it works and where it stops applying, without leaning on the acronym to carry the explanation.
What the setting actually does
This setting tracks occupancy separately for each room type and adjusts that room type's price based on its own sell-through, not the property's blended average. Eight of ten Double Rooms sold moves the price on the two remaining Doubles, regardless of what the Single Rooms are doing. Each room type prices against its own pace, in parallel, rather than all of them reacting to one shared occupancy number.
This is the direct replacement for the manual version of the same idea: someone eyeballing a spreadsheet of sell-through by room category and adjusting rates by hand. The automated version runs that same logic continuously, on every room type at once.
Why it needs at least 5 rooms in a room type to work
This adjustment is specifically built for room types with more than 5 rooms. Below that, a single booking or cancellation swings the occupancy percentage too much for the adjustment to mean anything, 1 booking out of 3 rooms is a 33-point swing, not a real demand signal. With enough rooms in the category, the same 1-booking swing is a much smaller, more reliable signal, which is what the adjustment actually needs to work off.
This is also why it's a hotel-specific setting rather than something that applies to a single-unit short-term rental. A one-unit listing has no room type to track sell-through within, it's either booked or it isn't. The feature needs a pool of interchangeable rooms behind it to have anything to measure, which is one of the more concrete differences between how a hotel and a short-term rental get priced day to day.
The booking window setting decides how far ahead it reacts
The adjustment doesn't just look at today's occupancy; it looks at how a room type is pacing at a specific point before arrival. PriceLabs' recommended setting for hotels targets roughly 50% occupancy for a room type 16 to 30 days before arrival. If a room type is running ahead of that pace, the price for that category tightens; if it's behind, the price eases, specifically for that category, specifically at that point in the booking curve.
The practical effect: a room type that's clearly outselling its 16-to-30-day benchmark gets priced up before it fully sells out, instead of after, and a room type lagging behind gets a chance to correct while there's still time left to fill it.
This is not the same as adjusting occupancy across a whole portfolio
It's worth being precise about this distinction, since the two get used almost interchangeably in some places. What's described above adjusts pricing within a single property, room type by room type. A separate, related setting works at the opposite scale: across multiple units or properties, for operators managing several buildings, or several listings in the same building, as a group.
If the situation is "I run one hotel and my Double Rooms sell faster than my Singles," that's the room-type version described in this article. If it's "I manage 14 units across three buildings and want them priced as a group instead of each one shopping against the others," that's the portfolio-level version instead. Getting this backwards means configuring a setting that isn't actually built for the property structure in front of you.
What this replaces, worked through
Take a 40-room hotel with three room types: 20 Standard Rooms, 15 Deluxe Rooms, and 5 Suites. Without room-type-level adjustments, all three price off one blended occupancy figure. If Standards are selling fast and Suites are moving slowly, the blended number sits somewhere in the middle, masking both facts: Standards don't get priced up before they sell out, and Suites don't get discounted enough to move.
With the setting running, each of the three room types tracks its own pace against the same benchmark. Standards outselling their 16-to-30-day pace get tightened on their own schedule. Suites lagging behind theirs get eased on theirs. Nobody has to notice the pattern in a spreadsheet first, the adjustment is already running by the time anyone would have caught it manually.
What this means for your hotel
This setting automates a workflow most multi-room hotels are already doing by hand, tracking sell-through per room type and reacting to it. The difference is that it runs continuously across every room type at once rather than whenever someone has time to check the numbers, and it reacts to a specific booking-window benchmark rather than a gut sense of "this room type feels like it's moving faster."
It's worth setting up deliberately if any room type in your property has 5 or more rooms and its own distinct demand pattern, which describes most multi-room-type hotels once you actually look for it. It's one piece of a larger demand-based pricing strategy rather than a standalone fix, most hotels get the most out of it alongside the other settings already reacting to seasonality and events. Start a free trial and see how each of your room types is actually pacing before deciding what, if anything, needs adjusting.
Frequently asked questions
What does Multi-Room Occupancy-Based Adjustments do?
It's a PriceLabs setting that tracks occupancy separately for each room type in a hotel and adjusts that room type's price based on its own sell-through, rather than the property's overall blended occupancy. It's sometimes referred to by the shorthand MROBA.
How many rooms does a room type need for this setting to work?
More than 5. Below that threshold, a single booking or cancellation swings the occupancy percentage too much to produce a meaningful signal, so the feature is built for room types with enough inventory for a smaller swing to still mean something.
What's the difference between this and adjusting occupancy across a whole portfolio?
This setting adjusts pricing by room type within a single property. A separate setting, Portfolio Occupancy-Based Adjustment, adjusts pricing across multiple units or properties treated as a group. The right one depends on whether the thing you're trying to balance is room types inside one hotel, or separate listings across a portfolio.
Does this work alongside other PriceLabs pricing settings?
Yes. It adjusts rates within the room type based on occupancy pacing, alongside PriceLabs' other demand-based settings like Seasonality and Demand Factor Sensitivity, rather than replacing them.
Related articles
View all
