How to set seasonal room rates (without a spreadsheet you forget to update)

The structure: a default, and the months that break it

A room needs exactly two kinds of price. A base rate — what it costs on an ordinary night, which is most nights — and overrides for the months that are not ordinary. Peak season, a festival month, the quiet stretch after the rains start.

That is the whole model. Twelve slots a year, per room, and you only fill in the ones that differ from the base. A room with no unusual months has one number and nothing else to maintain.

Naming the season is not decoration

An override that just says a number is a number nobody remembers the reason for by the time next year comes around. An override labelled "Holy Week" or "Habagat — low" is a record of a decision, not just a price.

Six months later, when you are setting next year's rates, that label is what lets you reuse the reasoning instead of re-deriving it from a bank statement.

A worked calendar

A twenty-room Puerto Galera resort, base rate ₱3,200. The dry months carry the diving and draw the highest demand; Holy Week sits inside that window and pulls harder than any other week in the year; the habagat months are quiet enough that the base rate is already generous.

The mistake that costs more than getting the number wrong

Setting a season's rate correctly once and then never revisiting it is a smaller error than it looks. The expensive mistake is setting it correctly and leaving it in place a month too long — charging April's rate into a May that has gone quiet, or worse, still charging June's low rate into a July that has picked back up.

A rate that is 10% off in the right direction for the wrong week barely registers. A rate left on the wrong season for three weeks is a real, calculable loss, and it is the more common failure because nobody notices a rate that used to be right.

Building next year while this year is still running

The other reason a spreadsheet rate calendar drifts is that updating it means opening the same document that is also tracking this month's bookings, which feels risky to touch. A system that keeps years separate — next year's grid built and adjusted without disturbing a single live booking — removes the reason to put it off.

Build next year in a slow month, using this year's actual occupancy by month as the evidence for what to change rather than a guess.

What a seasonal rate cannot fix on its own

A correct base rate and correct overrides still assume every booking is priced the same regardless of how far ahead it was made. Two properties with identical seasonal calendars can have very different results if one is disciplined about not discounting a peak-season booking made two days before check-in and the other quietly is.

Seasonal pricing sets the ceiling and the floor for a given month. Whether a booking actually lands near that number is a front-desk discipline question, not a pricing-grid one — and it is worth watching separately, because a perfect seasonal calendar undermined at the desk looks the same in the numbers as a bad seasonal calendar.

Where the numbers for next year's rates actually come from

The honest answer is not a formula. It is last year's occupancy, month by month, read for where demand was clearly stronger than the rate charged for it, and where it was clearly weaker. A month that sold out three weeks early at last year's rate is telling you something plainly, and the correction is not subtle: it should have cost more.

A second, cheaper source of evidence is what competing properties nearby are doing on the dates you are unsure about — not to copy their number, but to see whether availability on comparable rooms is disappearing fast at a given price, which is a reasonable proxy for what the market will actually bear that week.

What does not work well is importing a benchmark from outside your own market. A regional average blends city hotels with beach resorts, high season with low, and tells you almost nothing about your own twenty rooms in your own town.

Different room types, different seasons

Not every room type in a property peaks the same way. A beachfront room with a view sells out first in any strong week and can carry a sharper seasonal swing than an inland standard room that fills more evenly across the year. Pricing every room type off one shared seasonal calendar is simpler to manage and measurably leaves money on the table for the room that everyone wants first.

It is worth building the seasonal grid per room type rather than per property once there is more than one type worth distinguishing — the extra rows cost nothing to maintain and the room that sells out first is exactly the one where a slightly higher peak rate goes unnoticed by the guest and straight to margin.

If you get a season wrong, how bad is it really

Less bad than it feels in the moment. A rate set 15% too low for a strong month is a real loss, but it is bounded to that month and it is visible in the numbers the moment you look — which means it gets caught and corrected for next year rather than compounding silently. The rate mistakes that actually hurt over time are the invisible ones: a season left unchanged for two or three years running because revisiting the calendar dropped off the yearly routine.

That is the actual argument for treating this as a fixed annual task rather than something to get exactly right once. A rough seasonal calendar revisited every year outperforms a precise one nobody has looked at since it was built.