Hi Community,
We have started work on being able to configure occupancy adjustments flexibly not just on base rates, but even on dependent rates and further per stay date and room category.
I will be posting visuals of what can be expected and collect beta signups in the upcoming days. Till then, we had a pressing question - that should help us shape product development better.
If you had the ability to define occupancy adjustments per stay-date/room combination, for every rate (base and dependent), would it be beneficial to be able to set them on a rate level?
We have uncovered arguments in both directions:
Pro of rate level adjustments: Rate level adjustments allow one to quickly configure occupancy adjustments for all room categories and dates in that rate. These can then be granularly over-written as and when necessary.
Con of rate level adjustments: It is never what is booked or sent to OTAs. So can be useless, since defining on the room/date level is much more accurate.
EDIT and extra question:
How would you expect the following to behave:
- A base rate has occupamcy adjustments for a certain date/room combo
- Then on a dependent rate new adjustments are defined - on the rate level (so impacting all rooms/dates)
Which adjustments are preserved in this case - the date specific ones from the base rate, or would you expect the new dependent rate level offsets to propagate to all date/room combos on it?
Hello Saurabh!
This is great news that this is coming to BETA soon!
I think that its very good to be able to set it on all levels. Both on a rate level so that it applies to all spaces on that rate. But in the meantime we might want to push some space categories even further to increase revenue on that space categories. The more granular we can be the better.
So for me I only see PROs on having this possibility.
And I can mention it here at the same time that when you are ready to beta this, we want in :)
EDIT:
I would expect the new rate to take president for that rate. But not change the base rates adjustments.
Have a great day!
Hi Saurabh,
Will the new features be about Negative Occupancy Adjustment negative percentage ?
Regards,
Floriant
@nstockman @Jamilla Brown @gj.vanderlaag @Kayleigh
Hi Saurabh,
Will the new features be about Negative Occupancy Adjustment negative percentage ?
Regards,
Floriant
Hi @floriant ! Indeed - both positive and negative adjustments will be seeing a change. As of today they are configurable only on the base rate - and apply uniformly over all stay-dates/rooms. We want to add a lot more flexibility on that front
Hello!
I think fine grained controll is always good, as long as it’s easy to manage (set and view, keep an overview) and is compatible with RMS systems pushing prices on a room type level (standard occupancy based) - think Atomize ;-)
Having said that, seasonal & room type level occuopancy pricing adjustment can be useful, think about multiple bed room types (4-5 pers max) and low season - maybe you want to sell cheaper to 2 persons that for 4 persons during low 4-person occupancy demand to keep the room type competive on the market… makes sense?
It’s important to be able to keep an overview and not get lost in details. Maybe in the future Atomize could direktly manage occupancy based pricing, too ??
Kind regards,
JP.
Hi Saurabh,
I hope you're doing well! I am a property manager newly embarking with Mews in Québec, Canada. Our property has the specificity of being all-inclusive with a per person pricing.
Your post above about the possibiliy of managing the adjustement (additionnal, negative and kids) would be a monumental leap forward in the case of an all inclusive resort charging a per person price such as us.
Because of our per person pricing, I have to set up negative and additionnal guest adjustement in a way that it reflects that. For example, in a double occupancy room, if my price per person in double occupancy is 100$ and my price in single is 130$, my room price will be 200, negative adjustement -70 and additionnal adjustement 100$.
So far so good, but if, let's say, in another room category, or in a derived rate, the price person person is 110$ (+20 to the room in double occupany), this +20$ (or +20% for that matter) won't be reflected in the adjustements.
For example, my derived room rate will be 220$ (+20), my additonal adjustement will still be +100$, but I would need it to be +110$ to reflect my per person pricing.
Therefore this development would be major, because as of now, I litteary had to ajdust my room rates to 0$ and add a product, through a product rule, to apply a per person rate based on the season, and I had to create specific products for every price rate I want to apply to different room categories (putting my quite close the the maximum of product rules I can apply!). This also makes my ADR completely flawed because I had to artificially put my rooms at 0$.
I am definetly in the “pro” team, and I add to that the fact that it would be a great add on for Mews to help properties charging a per person price independant of the room price.
Also : I’d be interest in being part of a beta tester group
Thank you, don't hesitate to reach out!
Hi Saurabh,
My initial thoughts are, that it would be great to have the option on a rate level. For me it is good to have more flexibility.
For us we offer different rates for different length of stay. To set occupancy adjustments on a rate level might give us the opportunity to move the mix of reservations into our preferred direction. For example we could have half the rooms available for short stay bookings, but keep the other half available for longer bookings only, so that they wouldn’t block each other out. Without the need to limit this to dedicated room numbers. For this specific usecase I can see a benefit in setting the occupancy adjustments on a rate level for a stay-date/room category combination.
Based on this level of granular options it is quite hard for me to come to an answer for your additional question. The part, that an adjustment on rate level would affect all rooms/dates, for me reads different than the initial proposal of “per stay-date/room combination, for every rate (base and dependent)”. Do you have an example?
I would like to see more about what you are currently working on and if suitable for our purposes, would be happy to participate in the beta testing.
Best regards,
Thomas
Hi,
we´re stuck with similar challenges such as those in Quebec. We´re selling per person rates to a travel agency which is not bookable OTA. Seasonal changes make it impossible to display our negotiated rates within the current rate management. Going hybrid here is the way. Would therefore love to join the beta!
Best regards, Niclas
There’s only one thing we need for occupany pricing, and that is percentages.
Being able to set occupany prices per rate is good, sure. But what we REALLY need is a percentage setting.
ie. an extra person in the room will be 25% on top of the room price.
If you’re working with an RMS, you want your extra bed prices to go up and down along with the room price. And not set these manually.
Most OTA’s already offer this 
We (at VAYA) are also facing issues because these adjustments are currently only possible on the base rate. Our base rate is "logis only," and our breakfast and halfboard rates are derived from it. Now, we need different occupancy prices for these breakfast and halfboard rates, but this isn't possible because we can only adjust our base rate…
Additionally, we have the problem with tour operator rates, where it's not possible for us to input the correct prices.
So we are very looking forward to this beta!
This sounds like a great step toward more flexible rate configuration and I looking forward to seeing the visuals and beta!
To your question:
Yes, having the ability to set occupancy adjustments at the rate level (for both base and dependent rates) would be valuable, especially from a setup and maintenance efficiency standpoint. It would allow for faster configuration, especially when launching new rates or promotions, with the option to override specifics at the room/date level when needed.
That said, we’d see this more as a “default” setting. The most critical pricing decisions still happen at the base rate stay date/room level. Which hopefully gets pushed tgrough to our Siteminder connection. I understood this is in the works to be supported before the end of this quarter.
On the behaviour question:
If a base rate has occupancy adjustments defined for a specific date/room, and then a dependent rate has adjustments, I would expect the existing adjustments from the base rate to be preserved since these should have president in hierarchy imo.
Looking forward to the next steps.