Dynamic Pricing and When to Override It

Automated pricing is good at the next thirty days and blind to why one date matters. The overrides worth keeping are the ones tied to an event you can name.

Last updated: October 26, 2026

Automated pricing is good at the next thirty days, and blind to why one date matters. It reads how fast a date is booking, how much availability is left, what comparable units are asking and how close the arrival is. What it can't read is the wedding three streets away, or the fact that one bedroom is out of service that week. The overrides worth keeping are the ones tied to a reason you can name, with an end date attached.

Key Takeaways

• The rules see signals, not stories. Pace, availability, comparable rates and lead time, not the reason a date is special.
• Override only what you can name. An event, a supply constraint, a commercial arrangement, an abnormal cost. Four kinds, no more.
• Set the end date when you set the rate. An override that outlives its reason becomes an invisible rule.
• One override per date. Layered changes are how a base rate disappears and nobody notices for a season.
• Count your overrides. If manual changes become normal, the settings are wrong, not the dates.

What automated pricing can see

An automated rate is a rule, or a set of rules, that reacts to what's observable. How many nights have been booked for a date compared with where you'd normally be at this distance from arrival. How much availability is left in the unit and in the area. What comparable units are asking for the same night. The day of the week, the season, the length of the stay, how close the booking is to the arrival date. Those inputs are quantitative, they update constantly, and they're better than a human at watching all of them at once.

Where they're weak is exactly where a host is strong. A rule can only react to what has already produced a signal. If a date has become valuable because of something announced last week, the booking pace won't show it yet. If a date looks hot because three bookings came in fast, the rule can't tell whether that's demand or three enquiries from the same group. And if the cost of servicing a night is unusual, the rule has no idea: it's pricing demand, not cost.

That's not a flaw to be fixed. It's the division of labour. For most of the calendar, the automated rate is a better guess than the one you'd make by hand at eleven at night. For a handful of dates a year, it's wrong in a way that costs real money, and those dates are usually the ones the year turns on.

So the question isn't whether to intervene. It's which interventions are worth the cost of managing them. An override you have to remember is a liability. An override with a reason and an end date is a decision.

The four reasons to override

An event you can name. A wedding, a festival, a fixture, a conference, a road closure that pushes traffic elsewhere. The test is whether you can name it and date it. If you can, the automated rate is working from an incomplete picture and your knowledge is better than its data. If you can't name it, you're guessing, and the rule is probably guessing better.

A constraint on supply. A room out of service. Maintenance that takes the unit off the market for two nights. A minimum stay that makes a single night unsellable at any rate. Here the rule may read reduced availability as strength and push the rate up while you actually have less to sell. Override to reflect what's actually available, or block the date and stop pricing it altogether.

A commercial arrangement. A long stay that fills a dead month. A repeat guest who books the same week every year. A direct booking with terms you've agreed. A relocation stay paid by a company. These aren't the one-off platform booking the rule was built to price, and applying the automated rate to them usually misreads both the risk and the value.

An abnormal cost. A date that needs a second cleaner, a premium for staff on a public holiday, a one-night stay whose turnover costs nearly as much as the night. The rate has to cover the cost of that specific night. Average cost is the wrong input when the night isn't average.

What doesn't qualify is worth listing too, because these are the overrides hosts make most often. The date feels busy. Last year it was priced higher. A listing down the road is asking more. All three are moods dressed as reasons, and none of them gives you an end date.

How long an override should last

Tie the expiry to the reason, not to a number of days. An event has a date. A maintenance window has a finish. A long stay has a checkout. If you can name the reason, you already know when it stops applying, and that's the day the override should end.

The common mistake is a fixed window: raise the rate for a fortnight because that's a comfortable unit of time. A fortnight either outlives the reason, in which case you're charging an event premium on ordinary nights, or it ends before the event does, in which case the override did nothing when it mattered.

The second mistake is layering. One override on top of another, set at different times by different people, and by the end of the season nobody can reconstruct what the base rate was or why that date carries that price. One override per date, replaced rather than added to. If a second reason appears, edit the first one and note both.

Set the end date at the same moment you set the rate, in the same place. An override with an expiry is a temporary decision. An override without one is a permanent change that nobody voted for. And when the date passes, remove it even if the rate it produced looked right, because the next time that date comes around, the reason may not.

Reviewing overrides afterwards

Keep a log with four fields: the date, the reason in one clause, the change you made, and when it expires. That's it. The log is what makes the review possible, and it takes less time than the argument you'd otherwise have with yourself about whether the override worked.

Review it once a month, in two passes. First, the expired ones: overrides whose reason has passed but which are still live. Those are the ones quietly distorting the calendar. Second, the ones that have run: for each, look at what sold at the overridden rate and what stayed empty. You're judging the decision, not only the outcome, because a sound override can still leave a night unsold and a bad one can fill.

The count is a signal in itself. If manual changes have become the normal way you price, the automated settings are the thing to fix. Overrides are for the exceptions; when exceptions become routine, the base rate has stopped describing your property.

Checking what a channel actually charges is part of the review, because an override is only real once it reaches the channel. localsbnb.com shows each connected channel's own source rate and status against the date. The check becomes a look rather than an assumption, and a date where the override didn't land shows up as a difference rather than a surprise at payout.

FAQ

Should I switch automation off for a busy period?

No. Keep it running and override the specific dates you can explain. Turning it off for a whole period replaces a rule with your memory of a rule, and the nights either side of the event usually get priced by mood.

How many overrides are too many?

When manual changes stop being exceptions. If a large share of your dates carry a hand-set rate, the base settings no longer describe the property and the fix belongs there rather than in more overrides.

Does an override apply to every channel?

That depends on how your rates are distributed, and it's worth checking rather than assuming. Look at what each channel is charging for the date after the change, and treat any gap between them as the thing to investigate first.

Automated rates handle the ordinary nights, which is most of them. Your job is the few dates where the rule is working from a picture you can complete. Name the reason, put an end date on it, count how many you're carrying. If you want to see what each channel is actually charging while you decide, localsbnb.com puts the connected channels' source rates and statuses beside the dates they apply to.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice, and it isn't financial advice. How a rate is calculated, what a channel displays and what a booking is worth all depend on your own settings, your market and the current terms of each platform you use. Check both before you change a rate.