
Seasonal Pricing Across Two Rainy Seasons and Three Peak Windows
A tropical year usually has two wet stretches and three short peaks, not one high season. A single annual curve smears a ten-day peak across a whole month, so it overprices the wet weeks and underprices the peak. The fix is five blocks, each with a floor rather than a rate.

A tropical year rarely has one high season. It has two wet stretches and three short peaks, and pricing them as a single curve leaves money on the table in both directions.
Last updated: October 14, 2026
Most pricing calendars are built as one curve: a low season, a high season, and a slope between them. A tropical year doesn't cooperate. It has two wet stretches and three short peaks, and a single curve overprices the rain while it underprices the windows that fill in ten days. The fix isn't a better curve. It's five blocks with a floor each.
Key Takeaways
- One annual curve smears a short peak across a long month. A ten-day window priced by a monthly multiplier overprices the other twenty days and underprices the ten.
- The wet season isn't empty, it's different. Longer stays, later decisions and a lower rate can still beat a short peak stay once the cost of a turnover is counted.
- Five blocks beat twelve months. Wet A, Peak 1, Wet B, Peak 2 and Peak 3 each behave differently, and each needs its own boundary.
- Set a floor, not a rate. A rate is one number you defend once. A floor is a rule that survives a busy Tuesday.
- Test the blocks against nights sold, not against how the season felt. The block that sold out early and the block that ended empty are two different mistakes.
Why one annual curve misprices a tropical year
An annual curve starts with a sensible idea. Take last year's numbers, work out a multiplier for each month, apply it to a base rate. It's easy to defend in a spreadsheet and easy to explain to a partner.
The trouble is resolution. A monthly multiplier applies the same figure to every night inside that month. If your peak is a ten-day window, the curve gives you twenty days of peak pricing that nobody asked for, and ten days that are priced below what the window could carry.
That's the first direction of loss. The second is quieter. When the peak is smeared, the nights just before and after it get the same treatment as the peak itself, so the transition weeks never get the lower floor that would fill them. You end up with a calendar that looks full in the middle of a peak and oddly empty at its edges.
There's a third problem, and it's the one that makes hosts give up on seasonal pricing. A single curve can't express two wet seasons that behave differently. The first wet stretch follows a peak, so it starts with bookings already on the books. The second sits between two peaks, so it starts from nothing and needs a longer lead time. One multiplier can't hold both.
So the curve isn't wrong because the arithmetic is bad. It's wrong because the unit of time is too coarse to describe what's actually happening.
Segmenting the year into five blocks
Five blocks is the smallest number that keeps the year honest: two wet stretches and three peaks. Name them by function rather than by month, because your boundaries will move and the names shouldn't.
Draw the boundaries from booking behaviour, not from the calendar. A block starts when the pace changes: when the enquiries for a window arrive earlier, when the minimum-stay pattern shifts from two nights to five, when the guest type changes from a weekend couple to a longer stay. Those signals are in last year's booking dates, and they're a better boundary than the first of the month.
Each block then carries three things. A start and end date. A floor, which is the net you won't go below for any night inside it. And a release rule, which says how far ahead the block opens and what moves the rate inside it.
The boundaries do more work than the labels. If Peak 1 starts four days earlier than you thought, the four days you priced as wet are suddenly the most valuable nights of the month. Getting the boundary roughly right matters more than getting the multiplier exactly right.
One warning about block count. Five isn't sacred. If a fourth peak appears because of a local event, add a sixth block for it rather than stretching the one next to it. The point is resolution, and the number follows from the demand, not from a template.
Setting a floor for each block, not a rate
A rate is a single number, and a single number is always wrong on some night. A floor is a rule, and a rule keeps working when the week gets busy.
Build the floor from the costs that arrive with every stay: cleaning, linen, utilities, the channel's cut and the tax you remit. Add the smallest contribution you'd accept for the night, and you have a number you can defend without opening a spreadsheet at midnight.
Then let the rate move above it. Inside a block, the rate can climb with pace, with the length of stay, with how close the arrival date is. It never goes below the floor, and that's the only part of the system that has to hold.
The wet-season floor deserves its own arithmetic, because the obvious move is to cut the rate until something books. That ignores the other side of the sum. A wet-season stay is usually longer, so the fixed cost of a turnover spreads across more nights. Five nights at a lower rate can contribute more than two nights at a peak rate, once cleaning and laundry are counted once instead of twice.
So compare contribution per stay, not rate per night. The formula is short: nights multiplied by the gap between rate and variable cost, minus the fixed cost of the turnover. Run it for a wet-season stay and a peak stay, and the wet floor usually comes out higher than instinct suggests.
The peak floor is higher for a different reason. A peak night can't be resold, so the floor has to carry the cost of the nights it displaces. That's also why the release rule matters more in a peak than the floor does.


Testing the curve against last year's nights
The test is not whether the season felt good. It's whether each block did what you expected, and the answer sits in three numbers per block: nights sold, average daily rate and revenue per available night.
LOCALSBNB's Home dashboard shows occupancy, ADR and RevPAR, so you can read a block as a whole instead of scrolling a booking list. Read them together, because each one alone misleads. High occupancy with a low ADR says the floor was too low. A high ADR with empty nights at the end says the floor was too high or the block opened too late.
Then sort the result into two mistakes. A block that sold out early was priced below what the market would have paid, and the correction is a higher floor or a later release. A block that ended with nights unsold was priced above what the market would pay, and the correction is a lower floor or an earlier release multiplied by a longer lead time.
Neither mistake is a failure of the method. Both are readings, and each one tells you which of the three block settings to move.
There's a useful check on the channel side too. LOCALSBNB's calendar shows each connected channel's source rate and source status, so when one block sells differently on one channel, you can see whether the difference came from the rate you set or from a channel that stopped reporting. localsbnb.com keeps that view alongside the three performance numbers, which is the point where a seasonal review stops being a guess.
Change one setting per block for the next cycle. Five blocks with five changes each is twenty moving parts, and you'll never know which one worked.

FAQ
Do I need five blocks if my wet seasons look similar?
Probably not. If the two wet stretches behave the same way in pace and length of stay, run them as one block. The number should follow the demand, not the other way around.
Should the wet-season rate go as low as it needs to fill the calendar?
No. Compare contribution per stay rather than rate per night. A longer wet-season stay spreads the turnover cost across more nights, so a lower rate can still contribute more than a short peak booking.
How do I find the boundary between a wet block and a peak block?
From last year's booking dates. The boundary sits where the pace changes, where the minimum stay shifts, or where the guest type changes. A calendar month is the least reliable boundary you can use.
How often should the blocks change?
Once a year, with one adjustment per block. Reviewing the blocks every month turns a pricing system into a reaction to the last enquiry.
A year with two wet seasons doesn't need a cleverer formula. It needs finer resolution: five blocks, a floor inside each one, and a review that reads the three numbers side by side. If your current calendar still runs on one curve, localsbnb.com is a workable place to see what each block actually sold before you set the next one.
This is general advice for hosts, and it isn't legal, tax or insurance advice. Costs, demand patterns and platform terms vary by place and change over time; check your own numbers and the current terms of each platform you use.
Reviewed by
Localsbnb Editorial Team