Dynamic Pricing for Holiday Parks: How ADR and RevPAU Turn Empty Pitches Into Revenue
Quick answer:
ADR (Average Daily Rate) and RevPAU (Revenue Per Available Unit) are the two numbers that tell a holiday park whether it's actually making the most of the pitches, lodges, and caravans it already owns — and dynamic pricing is the practical tool that moves both numbers in the right direction without needing a single extra booking. A park tracking these figures in real time through holiday park management software can spot underperforming weeks and adjust price before they become empty weeks, rather than finding out in a spreadsheet three months later.
Hotels figured this out decades before holiday parks did, and the story of how is instructive. Airlines pioneered the idea that a seat flying empty is revenue gone forever — it can never be sold again once the plane leaves the gate — so price should flex constantly to fill every seat at the best available rate. Hotels borrowed the idea and built entire revenue management departments around two numbers: how much each room earns per night, and how much each available room earns whether it's occupied or not. Holiday parks have exactly the same perishable-inventory problem — an empty pitch on a Tuesday in May is gone forever the moment Wednesday arrives — but most still price the way corner shops price bread: one number, set months ago, rarely revisited.
What ADR and RevPAU actually measure
ADR is simple: total accommodation revenue divided by the number of units sold. It tells you how much guests are paying, on average, once they've decided to book. RevPAU is the sharper number, because it divides total revenue by every available unit — sold or not — which means it punishes empty pitches the way they should be punished. A park can have a healthy ADR and a mediocre RevPAU if plenty of high-paying bookings are propping up an average while dozens of units sit empty on quieter nights. Watching both together, rather than either alone, is what separates a park that's genuinely optimising its pricing from one that's just hoping the good months make up for the quiet ones.
Why "one price for the season" leaves money on the table
Setting a single seasonal rate is understandable — it's simple to communicate and easy to manage manually. But it ignores everything that actually drives demand: a bank holiday weekend isn't the same as the Tuesday after it, a heatwave forecast changes last-minute demand for pitches with pools nearby, and a park two miles from a sold-out festival could fill every empty unit at a premium if the price moved to reflect it. Every one of those moments is revenue a flat-rate park simply doesn't capture, not because the demand wasn't there, but because the price never moved to meet it.
How dynamic pricing works without feeling like extortion
The phrase "dynamic pricing" makes people nervous — nobody wants to feel like an airline seat, priced differently from the person next to them for no obvious reason. Done well in a holiday park context, it isn't about squeezing every guest for the maximum they'll tolerate; it's about letting price respond to genuinely different levels of demand, the same way it always has for restaurants (weekday lunch versus Saturday night) without anyone calling it exploitative. A park using dynamic pricing well typically adjusts rates for known high-demand periods, local events, and lead time, while keeping the logic transparent enough that a returning guest never feels punished for booking loyalty over last-minute urgency.
Where the data has to come from
None of this works from instinct alone. Reliable dynamic pricing depends on clean occupancy history, booking lead-time patterns, and accommodation-type performance — exactly the data a fragmented setup of spreadsheets, a separate booking widget, and a standalone EPOS system makes painfully hard to assemble. This is the underrated case for holiday park management software that keeps booking, occupancy, and revenue reporting inside one system: the pricing decision for next weekend needs this week's actual occupancy trend, not a guess based on how busy the season "feels."
Turning reports into decisions, not just record-keeping
A lot of parks already produce occupancy and revenue reports — they're just produced too late and read too rarely to change anything. The parks getting real value from ADR and RevPAU treat the numbers as a weekly decision-making habit: which unit types are underperforming this month, which weeks are trending soft three weeks out, and where a modest price adjustment now could fill units that would otherwise sit empty. That habit, more than any specific pricing formula, is what separates parks steadily growing revenue per unit from parks that grow revenue only when the whole market happens to be busy.
Multi-park operators face this at a different scale
For a group running several sites, the pricing conversation gets more complicated, not less — each park has a different mix of accommodation types, a different local demand pattern, and a different competitive set nearby. Trying to manage that from separate spreadsheets per site makes it almost impossible to spot which park is quietly underpricing itself relative to its actual demand. Centralised reporting across sites is often what finally reveals it: one park in the group hitting strong RevPAU while a nearly identical site twenty miles away is leaving 15% of potential revenue unclaimed, purely because nobody was comparing the numbers side by side.
A quiet mindset shift, not a system overhaul
The parks that adopt dynamic pricing most successfully rarely describe it as a big transformation. They describe it as noticing patterns they'd previously ignored — the same three weeks every June that always sell out early, the same shoulder-season Mondays that never quite fill, the same last-minute surge whenever the weather forecast turns unexpectedly good. Dynamic pricing, at its simplest, is just building a set of rules around patterns the team already half-knew from experience, and letting the system apply them consistently instead of relying on someone remembering to adjust a rate sheet manually every few weeks. That consistency is where most of the revenue gain actually comes from — not from any single clever price change, but from never again forgetting to make one.
Key takeaways
- ADR measures what guests pay once booked; RevPAU measures how well every available unit is performing, sold or not — track both.
- A flat seasonal rate ignores real demand swings from events, weather, and lead time, leaving predictable revenue unclaimed.
- Good dynamic pricing responds to genuine demand differences, not arbitrary guest-by-guest pricing.
- Reliable pricing decisions depend on clean, real-time occupancy and booking data in one system.
- Multi-park operators benefit most from centralised reporting that reveals which sites are underpricing relative to demand.
ADR (Average Daily Rate) is revenue divided by units sold. RevPAU (Revenue Per Available Unit) is revenue divided by every available unit, whether sold or not, making it a more complete measure of how well a park is using its total inventory.
Yes. Dynamic pricing scales down as well as up — even modest, rules-based adjustments for known high-demand periods can meaningfully improve revenue without requiring a dedicated revenue management team.
Parks wanting to see their own ADR and RevPAU trends in one place, alongside booking and guest data, can explore how Parkcore's management reporting brings pricing decisions and real occupancy data together on a single screen.
Bio for Stephen Richards: Born in Colwyn Bay North Wales, Steve's introduction it Computers was at secondary school in 1974. That first year, Machine Code was hand written onto gridded paper and sent to Connah's Quay Technical College where is was copied to punch card and then entered into a mainframe computer. The results printed out were sent back for the following week!
Steve left School in 1976 joining the Royal Air Force to work on RADAR and communications equipment. His last 5 years involved working in an Automatic Test Equipment (ATE) department on the System Management Team and also writing models for Microchips. It was a good job that he had kept up with computers which had become rather a passion by the time he started in ATE.
During that time the main Mainframe we replaced in a £3.9 million upgrade reducing the run time of the biggest ATE program from just under 2 weeks to the time it took for a finger to come off a depressed return key!
Leaving the RAF after 18 years service Steve worked for a Charity (Apex Leicester Project) before returning to electronics at Sonatest in Milton Keynes which after 3 or 4 years led to a Job at Telematica the then development arm of Trafficmaster PLC (Tm). Eventually brought in-house at Tm he worked moved into the IT Support Team with his last project moving email from a Linux Box to Microsoft Exchange for the 300 users in the company each of whom typically had 5 email addresses.
In 2006 Steve left to start his own company back in North Wales, Computer Technical Solutions was an MSP and moved to become an MSSP following another of Steve's passions Cybersecurity. Officially retiring in 2025, by May 2026 that overactive mind started thinking about all of the software he had seen not just for MSSPs but also for his clients that was either extremely expensive or that didn't exist with a complete answer to the needs of the SME.
By August 2026 two significant pieces of software have been created. Netmon the Network Monitoring Software and the second release Parkcore aimed at Caravan/Lodge Holiday Parks..... And so it begins!