Unit 4 · Implementing Your Pricing Strategy · Lesson 4.15
Implementing seasonal pricing
Seasonal prices get implemented one date range at a time, with two instruments available: a season-long profile for long stretches, and a date-specific override for short windows like a holiday weekend. They combine, and any percentage-based override needs its own minimum threshold underneath it or prices will drift back down as demand fades.
The full lesson text below is an edited transcript of the video, published 2026-08-24. The complete course is free at the playbook.
Check every seasonal date, not a sample
The first pass is validation, done per seasonal date range: compare what your strategy says those dates should earn against what the calendar currently shows. Because a dynamic pricing tool already responds to high demand, some of your seasonal dates may already be sitting where you want them.
That is exactly why every range has to be checked rather than sampled. In practice the outcome varies widely between listings: sometimes no adjustment is needed anywhere, sometimes every range needs one. Checking all of them is what makes the pricing right year-round instead of right in the months you happened to look at.
Two instruments, and when each fits
For a long stretch, a month-long summer season for instance, a custom seasonal profile is the easier instrument. For a short window such as a single holiday weekend, a date-specific override is the better fit. Neither is more correct in principle; the choice is about how many dates you are moving at once.
They also combine, and the combination is often the real answer: set the seasonal profile across the whole season first, then layer a date-specific override on a particular week inside it to make a granular adjustment. On the sample listing, an override applied to one week inside an already-adjusted March season stacked an additional premium on top of the profile’s effect.
A short window, worked through
The first range was a two-day high-peak weekend, so it took a date-specific override. Current calendar prices were 431 and 420 against a target around 480, so roughly a 15% bump was applied, and after saving, the dates moved close to the target.
One thing was added alongside it: an independent minimum threshold for those dates, set at 380. The reason is mechanical and easy to miss. The adjustment was a percentage, so as demand for those dates declines over time the tool will still walk the prices back down. The threshold is what stops that decline at a level you chose. Any percentage-based seasonal adjustment deserves the same protection.
A long stretch, worked through
The second range was a longer March high peak, targeting around 524 on weekdays and 564 on weekends. Long stretches are trickier because demand is not uniform across them, so the goal changes shape: you want an overall lift that brings the high-demand dates to or above your target, while accepting that the low-demand dates inside the same season will land lower.
The instrument used was a seasonal profile with an adjusted base, raised to 450 after reviewing prices across the range. After saving, March’s higher-demand dates sat close to and above the strategy’s figures, with the weaker dates trailing as expected. Leaving those weaker dates below target is the right call rather than a compromise: pushing them up would mean pricing low-demand nights as though they were peak.