How to build a seasonal pricing calendar for a hotel

The most common pricing document in hotels looks like this: a spreadsheet is opened in January, three seasons are written down, each gets a rate, and the file is closed. In July demand comes in higher than expected; the rate stays the same. In November demand drops; the rate still stays the same. That document is not a calendar. It is January's forecast.

This article builds a seasonal rate calendar in five steps: reading historical data by day, drawing up the demand calendar, defining season bands, setting the floor and the ceiling, and establishing the update rhythm. At the end there is a fictional example table and the four mistakes I see most often.

What a seasonal calendar is — and is not

A seasonal calendar is the document that sets the starting rate (BAR — Best Available Rate) for every day of the year. "Every day" matters: the calendar prices days, not months or three seasons. A Wednesday and a Saturday in the same week can sit in different bands; the first day of a public holiday can carry a different rate from its last.

The calendar is not an alternative to dynamic pricing; it is its base. Dynamic pricing moves the BAR set for a given day up or down on pickup and competitor rates. Without a calendar there is no reference to move; without dynamic pricing the calendar freezes in January.

Step 1: Read historical data by day

Monthly average occupancy is useless for a seasonal calendar; July's 85% contains 60% Tuesdays and 100% Saturdays. What you need is daily occupancy and ADR for the last two years. Export the end-of-day reports from the PMS; two years is 730 rows and reads comfortably in one table.

Three columns per day are enough: occupancy, ADR, day of the week. As a fourth column note whether anything special happened that day: public holiday, trade fair, concert, school break. That column is the raw material for the next step.

If one of the two years was abnormal (a major renovation, a pandemic year, a regional event), do not use it as a reference; working with one year of clean data beats working with two years of wrong data.

Step 2: Draw up the demand calendar

The demand calendar is the list of everything that will push next year's demand off its usual path: public holidays and bridge days, school breaks (local ones and those of your main source markets), religious holidays, trade fairs and congresses in the city, concerts and sporting events, regional festivals. In a city hotel the fair calendar is the heaviest item; in a resort it is the school calendar.

Compare this list with the fourth column of your historical data: what happened to occupancy and ADR in fair week last year? That comparison shows which events genuinely create demand and which merely sit on the calendar.

Step 3: Define the season bands

A band is a group of days carrying similar demand. Three bands (low, shoulder, high) fall short in most hotels because demand does not divide the year into three. Practical rule: if the occupancy of days within one band differs by more than 15 points, split it. Most hotels end up with five to seven bands under that rule.

Bands are assigned to days, not dates. Not "1 July–31 August: high season", but "July–August weekends: highest, weekdays: high, holiday week: peak". Three different bands inside the same month is normal.

Step 4: Set the floor and the ceiling

Each band has a BAR; the calendar as a whole has one floor and one ceiling. The floor is cost per occupied room (CPOR): total rooms department cost divided by rooms sold. No band rate, no discount and no contract rate goes below it; every room that does raises occupancy and lowers profit.

The ceiling is bounded by two things: the competitive set's highest seasonal rate and the highest rate the hotel has genuinely sold in the past. The second is usually lower than the first and more reliable; holding a rate on a list and selling at it are different things.

Step 5: Establish the update rhythm

The calendar starts ageing the day it goes live. The update rhythm is weekly: each week the OTB for the next 90 days is compared with OTB on the same date last year. Where a date is clearly ahead, its band moves up one step; where it is behind, restrictions (minimum stay, channels) are reviewed before the rate is.

When demand comes in low, the first reflex should not be to cut the rate. The first question is: which channel and which segment is not booking this date? The answer is usually in visibility or in restrictions, not in price.

Example: Sample Hotel's calendar

The figures below are fictional and do not belong to any real property. Sample Hotel has 120 rooms, sits in a city centre and is open all year; its CPOR is 1,400 TL and the highest rate it has genuinely sold is 4,000 TL. A five-band structure:

Note that the bands are distributed by day type, not by month. March contains both band 2 and band 4; a fair week lands in band 5 whichever month it falls in. The calendar gives each of the 365 days one of these five labels, and the weekly rhythm then moves the labels.

The four most common mistakes

1. Building the calendar and never touching it

The most common mistake of all. The January calendar is applied in July without a glance at pickup; when demand is strong money is left on the table, when it is weak the hotel runs to last-minute discounts. The weekly update rhythm is the only cure.

2. Settling for three seasons

A low–shoulder–high structure sells 55% days and 85% days in the same band at the same rate. The number of bands comes from the real distribution of demand; a calendar cut to three for convenience pays for that convenience on its strongest days.

3. Not separating weekday and weekend

Almost every hotel sees different demand on different days of the week. Two BARs inside the same band (weekday, weekend) is the cheapest and most effective improvement a calendar can get.

4. Not feeding the event calendar into rates

Knowing the date of the fair and putting that week into band 5 are different things. In most hotels the event calendar lives in the sales team's heads and never reaches the rate file. The demand calendar (Step 2) exists precisely to close that gap.

How to set it up in your own hotel

1. 01Export the last two years of end-of-day reports from the PMS: date, occupancy, ADR, day of the week, a note for the day.
2. 02Draw up next year's demand calendar: holidays, school breaks, fairs, events. Write each with its effect last year.
3. 03Group days into bands by occupancy, applying the 15-point rule. Assign bands to day types, not dates.
4. 04Calculate CPOR and write it in as the floor; bound the ceiling by the highest rate genuinely sold. Spread the band multipliers between those two limits.
5. 05Set a weekly update meeting: compare 90-day OTB with last year and move the band of any date that deviates. If the meeting takes more than 20 minutes, something is wrong with the calendar.

Related concepts

• BAR — the starting rate the calendar gives each day.
• CPOR — where the floor rate comes from; rooms sold below it lose money.
• Pickup and OTB — the two inputs of the weekly update.
• MLOS and closed to arrival — the restrictions to touch before the rate when demand is soft.
• Rate shopping — checking the ceiling against the competitive set; the subject of a coming article.

Summary

1. 01A seasonal calendar prices days, not months; three bands in one month is normal.
2. 02The number of bands comes from demand: split any band with more than 15 points of occupancy spread.
3. 03The floor is CPOR; the ceiling is the highest rate genuinely sold.
4. 04Weekday and weekend carry separate BARs even inside the same band.
5. 05The event calendar belongs inside the rate file, not in the sales team's heads.
6. 06The calendar is updated weekly; a document built in January and unchanged in July is a forecast, not a calendar.