
Override Rules for a Dynamic Pricing Tool
An override is a rate you set yourself on dates where the automated number is wrong for a reason the tool can't see. Write the rule before the season, name who approves one, and review the outcome instead of counting how often you stepped in.

An automated rate is a default, not a verdict. The hosts who do well with pricing tools are the ones who wrote down when they override it.
Last updated: October 17, 2026
Every pricing tool ships with a manual override, and most hosts use it the same way. A number looks wrong, they change it, and they move on. That works right up until you can't remember why you changed it. An override is a decision you make on purpose. Write the rule before the season starts, and you won't be rebuilding the reasoning at eleven at night with a guest waiting for an answer.
Key Takeaways
- An override is a decision with a reason. If you can't state the reason in one sentence, it's a guess wearing a rate.
- Four situations earn a manual rate. A dated event, a long stay that blocks a peak, a repair week, and a channel campaign you didn't plan.
- Write the rule before the season, not during it. A rule you wrote in a quiet month is the only kind you can follow in a loud one.
- Log the reason, not just the number. The number already sits in the calendar. The reason is the part you'll want next year.
- Review outcomes, not counts. Ten overrides that beat the default are worth more than one that quietly cost you a booking.
What an override is, and what it is not
An override is a rate you set yourself, on dates where the automated number is wrong for a reason the tool can't see. That's the whole definition. It's a correction with a cause, applied to a date range you can name out loud.
It isn't a way to second-guess every night. Hosts who override daily usually aren't pricing at all. They're reacting. The pattern shows up as a rate that moves each time an enquiry lands, and a calendar that nobody, including the host, can explain a week later.
It isn't a fix for a bad base rate either. If your default is off across a whole season, the problem sits upstream, in your floor, your minimum stay, or the way a room is mapped to a channel. Overriding forty nights one at a time hides that problem and eats an afternoon you'll never get back.
And it isn't permanent. An override needs an end date. A rate you raised for a festival and forgot to lower is the most common way a good season ends with empty midweek nights. The tool did what you told it. You just never told it to stop.
The cleanest test is simple. Can you say, in one sentence, what the tool doesn't know? If yes, you have an override. If you're only saying that the number feels high, you have a mood.
Four triggers worth overriding for
A dated event is the clearest case. A wedding party, a local festival, a conference that fills every bed in the district for three nights. The tool sees a date on a calendar. It doesn't see why that date matters. When you know the reason and the tool doesn't, that gap is your override.
A long stay that blocks a short peak is the one hosts get wrong most often. Seven nights at a decent rate looks like a win until you count the two shorter bookings it displaced. Before you accept, look at what the stay covers and what it locks out. Then price the nights you're giving up into the decision, not just the nights you're selling.
A repair week changes what you're selling. If the water is off for two days, or scaffolding covers the balcony that the photos promise, the unit isn't the same product at the same rate. Lower it or close the dates. A full price on a compromised week buys you one booking and a review you'll be answering for months.
A channel campaign you didn't plan is the fourth, and it's easy to miss. When a promotion runs on one channel and your calendar still holds the older number, the first move isn't to change the rate. It's to check what the channel is actually charging. LOCALSBNB's calendar shows the source price and the source status for each connected channel, so you can see the live figure before you touch anything.
Those four have something in common. Each one names a fact that lives outside the pricing model: a date, a block of nights, a building problem, a campaign. If you can't point to a fact like that, you're probably about to override for a feeling.
Writing the rule before the season starts
The rule fits on one page. It lists the situations that earn an override, who can approve one, and how long it lasts. That's the whole document. Anything longer won't get read in the week you need it.
Write it in the quiet month. Pull up last season's calendar and mark the dates you already know about: the festival, the school holiday, the road closure, the two weeks when the building does its annual maintenance. Those are the dates your rule has to cover, and you have them months before the demand arrives.
Name the approver, even when the approver is you. The point isn't bureaucracy. It's the thirty seconds of pause between noticing a number and changing it. If a co-host or a cleaner can also see the calendar, say plainly who's allowed to move a rate and who has to ask first.
Give every override an expiry. A rule that says "raise the rate for the festival" is half a rule. "Raise it for the four nights of the festival, then return to the default on the Monday" is the version that survives contact with a busy week. The expiry is what stops a temporary decision from becoming your new base rate by accident.
Keep the page where the work happens. A rule in a folder you open twice a year is a rule you don't have. Put it next to the calendar, or pin it in the notes you actually read.


Reviewing overrides instead of counting them
Counting tells you how often you interfered. It doesn't tell you whether you were right. Ten overrides in a season could be ten good calls or ten small leaks, and the count looks identical from the outside.
So review each one against a counterfactual. What would the default have produced for those nights? Did they sell, and at what rate? If the nights sold at your override and the default would have left them empty, you won. If they sold anyway at the lower default, you paid for a decision you didn't need to make.
Do this while the stay is fresh. Two minutes per override, in the week the guest leaves, beats an annual review built from memory. Write the outcome next to the reason you logged, and the log slowly turns into a table of what your market actually does.
Keep the review small enough to finish. Five overrides a month is a coffee. Fifty is a project, and a project gets postponed until it never happens. If the list is too long, that's the signal to look upstream at the base rate, not to review harder.
The numbers you judge against should come from one place. LOCALSBNB's Home dashboard shows occupancy, average daily rate and revenue per available room for the month, so an override can be checked against the same figures you used to set it. If you'd rather ask than open a report, the read-only question layer answers what a channel is charging on given dates without you rebuilding the picture by hand. When you want that kind of evidence in front of you, localsbnb.com is where the calendar, the channel prices and the month's numbers sit together.
One more habit makes the review honest. Note the overrides you decided against. The nights you almost changed and didn't are the control group, and they're free to collect. Six months of those notes tell you more about your own instincts than any dashboard will.

FAQ
How often should I override an automated rate?
Often enough to cover facts the tool can't see, and rarely enough that you can still explain every change. If you're overriding weekly, the base rate or the mapping is probably the real problem.
What belongs in an override log?
Four fields: the dates, the reason, the rate you set, and what the default would have done. Add the outcome after the stay. Anything longer than that stops getting filled in by the second month.
Do overrides carry across every channel?
Treat that as a question to check, not an assumption. Look at the source price and the source status for each connected channel before you assume a change landed everywhere you meant it to.
A pricing tool is only as good as the edge you draw around it. The default handles the ordinary weeks, and your rule handles the handful of dates where you know something the model doesn't. If you'd like the channel prices and the month's numbers in one view while you write that rule, localsbnb.com is a sensible place to start.
This is general advice for hosts, and it isn't legal, tax or insurance advice. Rules and platform terms vary by place and change over time; check the current requirements of your local authority and the current terms of each platform you use.
Reviewed by
Localsbnb Editorial Team