What the season costs
The rate is wrong for six weeks of the year because fixing it means a support ticket and a lead time.
Ask an operator why the Fourth of July week is priced the same as the second week of June and the answer is rarely strategy. It is that the rate lives in a screen somebody else controls, or in forty individual listings, or behind a request to a vendor with a lead time on it.
So the rate gets set once in April and left. The peak weeks subsidise the shoulder weeks, and the operation works hardest in the weeks where it earns least per unit.
Date range comes first. Peak, shoulder and off-season are different rate structures rather than one price with manual overrides piled on top.
Day of week layers over it. A Saturday in July does not price like a Tuesday in July, and in delivery-based categories the Saturday is the constrained resource.
Length of stay is the one that moves revenue most in vacation markets. A seven-day hire costs seven times the daily rate only if you decide it should, and multi-day pricing expressed as rules beats a wall of discount codes.
Take a fleet turning $12,000 in a peak week. If the peak weeks are priced 10% under where the market clears and there are six of them, that is $7,200 left on the table on a single category, with no extra unit, driver or mile involved.
Illustrative numbers again. The measure to watch in your own accounts is revenue per available unit through the peak weeks rather than total revenue, because total revenue hides underpricing behind volume.
Build the rate calendar before the season rather than during it. Mark the weeks where you turned away demand last year and price those first.
Look at last season's peak and shoulder side by side. Where the two rates are the same, that is a decision you made by not making one.
Then leave yourself the ability to change it. A rate you cannot edit yourself on a Tuesday afternoon is a rate that will be wrong for the rest of the summer.
Rates sit against date ranges, with day-of-week rules layered over them and length-of-stay pricing as a native rule rather than a discount code.
The operator edits all of it directly. No support ticket, no vendor lead time, which is the reason most rates go stale in the first place.
Season revenue at 30 rentals a week: $0
Click a week to move it between bands. Rates are yours to set on the day demand moves, without waiting on anybody.
There is no automated demand-based pricing engine. Rates change when you change them.
For most seasonal rental operators that is the wanted behaviour, and it is worth being clear that it is not yield management and does not pretend to be.
With rates held against date ranges, day-of-week rules layered over them, and length-of-stay pricing expressed as a rule rather than as discount codes. Peak, shoulder and off-season should be separate structures rather than one price with manual overrides.
The practical constraint is who can change a rate and how fast. Where editing a rate needs a support ticket or a vendor lead time, peak weeks end up priced like shoulder weeks, and the measure that exposes it is revenue per available unit through the peak weeks.
Yes. Rates are edited by the operator directly, with no support ticket and no vendor lead time.
No. There is no automated demand-based pricing engine. Rates change when you change them.
Yes. Length-of-stay pricing is native, so a seven-day hire costs seven times the daily rate only if you say so.
A demo takes six fields and someone who understands rental operations calls you back. Where Bodhisys is the wrong fit you will hear it on that call rather than after three meetings.
