Pricing consistency across a portfolio is where co-hosting income either holds or leaks

The math in this post is solid and worth sitting with if you are new to co-hosting and wondering where income actually goes.

A few terms first. ADR means average daily rate, the average amount a unit earns per booked night. RevPAR means revenue per available night, which divides total revenue by every night the unit could have been booked, occupied or not. The post is pointing at RevPAR as the number that actually tells you how a unit is performing, and that is right. High occupancy at a low rate means more cleaning costs, more guest communication, and less money.

Dynamic pricing software sets your nightly rates automatically by watching demand signals like local events, competitor inventory, and booking pace. The catch the post names is real: most tools ship with default sensitivity settings tuned to broad national patterns, not your specific market. If you drop it into a mountain cabin market without recalibrating the demand curve by day of week and season, it will misfire on your best nights and your quietest ones.

The fix is not more software. It is knowing your market's specific rhythm first, then using the tool to execute against that pattern rather than a national average.

I am not certain which tools handle local calibration best in your specific market, so I would confirm that with other operators already running in your area before committing to any platform.

One thing worth checking regardless of where you are in this: if you are still working out whether co-hosting fits how you actually operate, the free quiz at projectrena.com/quiz takes four minutes and gives you a starting point.

What market are you co-hosting in, and do you have a quarter of occupancy and rate data you can line up side by side?

The math holds. And the assumption buried in that occupancy-versus-ADR comparison is worth pulling out further: most co-hosts running manual or lightly supervised dynamic pricing are optimizing for the metric the owner sees first, which is occupancy, because a full calendar looks like success. The co-host absorbing the fee hit on underpriced nights rarely surfaces that in a client report.

The calibration point is the one I'd push on. Default sensitivity settings in most dynamic pricing tools are trained on aggregated regional data, and regional in this context can mean a radius wide enough to blend markets that behave nothing alike. The Smokies example is a good one because weekend demand there compresses into a narrower window than most national models expect, so the tool pulls rates up too late and holds them too long into the shoulder. The result is you capture less on the peak and sit dark on nights where a manual nudge down by $15 would have filled it.

The risk you did not name is owner churn. An owner watching occupancy hover around 85 percent has no obvious reason to question the co-host's pricing approach. When a competitor property or a different co-host shows them a RevPAR comparison, the gap becomes visible fast, and the relationship ends on a metric the owner finally understood too late for you to fix it.

On the operational side, running the whole book from a single pricing strategy is usually where the leak starts. Unit-level calibration takes more setup time, but the revenue difference on a five-unit book with meaningful demand variation between units justifies it.

What tool are you currently running, and have you pulled a full quarter of your own occupancy-by-day-of-week data against market comp sets to validate the sensitivity settings?

The assumption doing the most work in your post is that calibrating the tool fixes the problem, but calibration only matters if the baseline comp set is right, and most dynamic pricing software lets the host define that set manually. If a co-host in a mountain cabin market pulls comps from the nearest metro because the software defaulted there, even perfect sensitivity settings are chasing the wrong ceiling. I would add one thing the thread has not touched: the co-host's contract structure changes how much any of this matters to her directly. A flat monthly fee insulates her from pricing mistakes in a way a straight percentage does not, so the motivation to audit the comp set and dial in midweek floor prices is a contract question before it is a software question. The 15 percent model you described actually creates the right incentive, but only if the co-host has visibility into RevPAN by unit, not just the aggregate. What does your contract give you access to on the reporting side, and are you seeing per-unit data or a rolled-up number?

Dynamic pricing software wins on scale, manual wins when you know a micro-event the algorithm missed.

The 78 percent at $195 versus 88 percent at $160 comparison is the one operators get wrong most often, and I've watched co-hosts I know brag about occupancy like it's the scoreboard when they're actually just doing extra laundry for less money.

What I'd want to know before I trusted any dynamic tool on a portfolio like that is whether the comp set it's pulling from actually matches the asset. I ran a Durham flip last spring that I briefly considered holding as a rental, spent about six weeks looking at PriceLabs defaults, and the comps it was benchmarking against included a mix of units that weren't remotely comparable by bedroom count or neighborhood. The midweek floor it suggested would have had me at $112 a night in a zip code where the right answer was closer to $145, because the algorithm was averaging in some weak inventory on the east side. Once I manually tightened the comp radius and adjusted the minimum threshold upward, the Thursday-Sunday blend looked completely different. Default sensitivity on a Smokies cabin versus a midtown condo isn't just a philosophical difference, it will cost you real dollars in opposite directions depending on the night. So the question I'd push back with for anyone running a co-hosting book: how often are you actually auditing the comp set, not just the rates the tool spits out?

The risk the thread has not touched is what happens to the owner relationship when the software is producing numbers the owner can see in real time and does not understand. An owner watching their unit priced at $119 on a Saturday night because the algorithm spotted a soft weekend in the comp set will call the co-host before they call the software company, and if the co-host cannot explain the logic in two sentences, the conversation shifts from pricing strategy to trust. That is the moment co-hosting income actually leaks, not in the Thursday dark night, because a spooked owner starts overriding rates or pulls the listing entirely, and no calibration setting recovers a terminated contract.

The operational fix is to agree in writing, before the software goes live, on a rate floor by unit, a peak floor, and a shoulder floor, so the owner has already signed off on the range the tool is working within. That framing also protects the co-host: when a Saturday comes in at $119 and it is still above the agreed shoulder floor, the owner's complaint has nowhere to go. The pricing conversation moves from "why is my unit cheap" to "are we still inside the agreed band," which is a much shorter call. What does your current owner agreement say about minimum acceptable rates, and is that number defined per unit or as a portfolio average?