How We Price Hudson Valley Short-Term Rentals: The Actual Rules

Ask any short-term rental manager how they price and you'll get the same answer: "We use dynamic pricing. Our algorithm analyzes millions of data points." Ask a follow-up question, any follow-up question, and the conversation gets vague fast. What actually triggers a price change? How big is the change? Who checks it before it goes live? What happens when the software is wrong?

Before writing this post, we went looking for a single management company, national or local, that publishes its actual pricing rules. We couldn't find one. The big brands describe their algorithms in the same interchangeable sentences. The pricing software companies publish more detail about their own products than any manager publishes about how they use them. Owners are asked to hand over their largest pricing decision to a black box, and the results show up in forums as the same recurring worries: I can't tell if it's working. Two tools give me opposite answers. The software changed my settings and I don't know why.

So here is how we actually do it. Not "we adjust for seasonality and demand." The real structure: what we measure, the rule that maps that measurement to a price move, the guardrails that stop the system from doing something dumb, and the human review that every single change passes through. A few details are simplified and we're not publishing the whole playbook, but there's enough here that you could ask any manager, including us, to defend their process against it.

Why occupancy, not competitor prices?

Most pricing advice starts with the comp set: find similar listings, see what they charge, position yourself accordingly. We learned the hard way that this is backwards, at least for well-run homes. Comp-anchored pricing quietly assumes your listing is average. If your home photographs better, reviews better, and sleeps people more comfortably than the comps, anchoring to them caps your upside. And if the comps are themselves priced by software chasing other software, you're triangulating against noise.

Our system is occupancy-driven. The primary question, every week, for every home: how booked are the next 30 and 60 days, compared to what this home should be at, in this season? Paid nights only. Owner stays don't count as demand. Competitor prices, market indexes and prediction tools, and channel data are context we look at, but they cannot change a pricing decision by themselves. If the next 30 days are filling faster than the seasonal target, the price is too low. Filling slower, it's too high. The market answers honestly when you ask it that question, because bookings are money and clicks are not.

The Hudson Valley has five seasons, not four

Generic pricing tools ship with a national picture of seasonality. The Hudson Valley doesn't follow it. Our calendar has five seasons, each with its own occupancy target per home:

• Off-season (early Nov to mid-Apr): the long quiet stretch. Realistic targets here are roughly half of summer's.
• Shoulder spring (mid-Apr to mid-Jun): demand rebuilding week by week.
• Peak summer (late Jun to Labor Day): the main event, NYC weekender demand concentrated hard on Fridays and Saturdays.
• Shoulder fall (September): a real dip most tools miss, sitting right before...
• Peak fall (October): foliage season, which in this region behaves like a second summer with holiday-grade weekends.

The targets differ by season and by home size, because a home that sleeps twelve books differently than a cottage for four. A mid-size home might reasonably target 70-75% occupancy in peak summer and 35% in February. That spread is the whole point: judging a February calendar against a July expectation is how homes end up either underpriced or empty, and it's exactly what a one-size seasonality curve does.

What actually triggers a price change?

A written table. The gap between where a home's next 30 days actually are and where the seasonal target says they should be maps to a specific percentage move. A simplified excerpt:

The real table has more rows, plus a second layer that looks at the 60-day window and adds upward pressure when the further-out calendar is also running ahead. Every move is capped at 25% per week in either direction, and results round to clean $5 increments.

A worked example. Say it's peak summer and a home with a $400 nightly base is targeting 70% occupancy, but the next 30 days are only 45% booked. That's 25 points behind: the rule says cut about 13%. New base: $350. No debate about how it "feels," no waiting to see if things pick up on their own, no panic-slashing either. The same home at 80% booked gets a 5% raise, and if the next 60 days are also filling ahead of pace, the second layer pushes it higher. The math is boring on purpose. Boring math, applied every week, is what consistency looks like.

What stops the system from doing something dumb?

This is the part nobody publishes, and it's the part that matters most. Any pricing rule, ours included, will occasionally recommend something wrong, because the inputs can lie. A system with no mechanism for catching its own bad recommendations isn't a strategy. It's automation with good marketing. Ours runs every recommendation through a set of guardrails that can block or redirect it:

The cut floor. Once cuts have accumulated to 20% below a home's seasonal anchor price, the system refuses to cut further, no matter what occupancy says. Instead it flags the listing itself for an audit: photos, copy, reviews, amenities. This guardrail fires more often than you'd expect, and what it usually finds is a conversion problem, not a price problem. A listing that won't book at 20% off doesn't need a 25th percent of discount. It needs better photography or an honest look at its last few reviews. Cutting further just donates margin while the real issue sits unfixed.

The cooling-off rule. If a price changed within the last 72 hours, no new change, period. The market needs time to answer before you ask it another question. Without this rule, software happily chases its own tail, cutting on Tuesday because Monday's cut hasn't "worked" yet.

The long-booking check. One 18-night booking can make a quiet home look nearly full, and its absence can make a healthy home look empty. We cap how much any single reservation can influence the occupancy math, so one big booking, or one big cancellation, can't swing a price decision by itself.

Silence isn't a signal. Some homes book once or twice a month by nature, big houses with long stays and long lead times. For a home like that, a week of no bookings after a price cut proves nothing. The system knows each home's baseline booking velocity, and it refuses to treat expected silence as evidence the price is wrong. This single rule prevents more compounding mistakes than any other, because the natural human (and software) response to silence is another cut.

The human lock. When a person has made a deliberate pricing decision, the system cannot re-litigate it the following week. Decisions stick until a human unsticks them.

What about holidays?

Holidays break the weekly model, so they get their own system. Guests book Memorial Day, July 4, and the Christmas-to-New-Year's stretch three to six months out. If holiday pricing and minimum-stay rules aren't in place before that booking window opens, it's too late: a two-night booking lands in the middle of July 4 week and the rest of the week strands around it. We set holiday rates and minimum stays roughly six months ahead, with longer minimums for bigger homes on the biggest weekends.

Then we check pace against the same holiday last year at 30 days out and again at 14. Here's the discipline part: a single behind-pace reading triggers nothing. This spring, one holiday weekend was pacing 25% behind the prior year. Two days later it was 6% behind, no price change, the market just breathed. We require two consecutive weekly readings meaningfully behind before touching a holiday premium, because at the scale of a small portfolio, one reading is noise, and cutting on noise gives away the recovery you were about to get for free.

Every change passes a human

The whole system runs weekly: measure, compare, apply the rule, run the guardrails. Then a person reviews every recommendation before anything touches a live listing, with the context the rules can't see. A roof repair scheduled for that quiet week. An owner who'd rather hold rate than chase occupancy. A review situation worth resolving before raising prices.

Some weeks the right number of changes is zero, and the session log says exactly that. Writing the decisions down each week, including the decision to do nothing, is what makes the system auditable later: when a price cut works, we know why, and when it doesn't, that's recorded too, so the same mistake doesn't get made twice.

Questions to ask any manager (or yourself)

If you're interviewing property managers in the Hudson Valley, or self-managing and pricing by feel, a few questions cut through the algorithm talk fast:

• What specifically triggers a price change on my home, and how big is the change?
• What stops the software from cutting my rate every week into the ground?
• Who reviews changes before they go live, and how often?
• When were my holiday minimum stays set, and when do they get reviewed?
• Can I see the log of pricing decisions on my home from the last month?

Anyone running a real process answers these easily. Vague answers to all five means the honest description of the strategy is "we turned the software on." These five are the pricing section of a longer interview checklist we keep: 33 questions to ask a potential short-term rental manager.

If you'd like to see what this looks like applied to your home, start with what your home could earn, read about how our management fee works, or talk to us. And if you're weighing the regulatory side too, our town-by-town guide to Ulster County short-term rental rules covers that half of the homework.