What data a hotel generates and where it lives

A typical hotel operation touches half a dozen or more separate platforms before a guest has even checked in. Reservations flow through a Property Management System (PMS) – systems like Opera Cloud, Mews or Cloudbeds – which holds room rates, length of stay, guest profiles and channel source. The moment the guest orders breakfast, that transaction moves to the POS system. Pre-arrival communications sit in a CRM or marketing platform. The guest's loyalty tier is tracked somewhere else entirely.

Each of those systems was designed to do one thing well. None of them was designed to talk to the others. The result is a business generating enormous volumes of data that is, in practical terms, invisible to the people who most need it.

This isn't a technology failure so much as a structural one. PMS vendors build for front-desk operations. POS vendors build for F&B management. Loyalty platforms build for redemption tracking. The cross-system view that tells you what a guest is actually worth over their lifetime simply doesn't exist in any of those tools – and can't, without something to connect them.

Why PMS reporting isn't enough

PMS reports are good at what they're designed for: room nights, ADR (Average Daily Rate), occupancy and RevPAR (Revenue Per Available Room). These are essential metrics. But they're also limited ones.

RevPAR tells you how efficiently you're selling rooms. It says nothing about what guests spend once they're on property. A guest paying £120 per night who spends £80 in the restaurant and £60 at the spa is significantly more valuable than a guest paying the same room rate who orders nothing. The PMS sees them as identical.

TRevPAR – Total Revenue Per Available Room – attempts to capture the fuller picture, but calculating it accurately requires combining PMS and POS data, something almost no PMS does natively. The operational reporting that most hotel groups actually work from undercounts total guest value by design.

The problem compounds at scale. A group with multiple properties may have consistent room revenue reporting across sites, but F&B performance is tracked separately at each property, loyalty data is aggregated at group level and booking channel analysis is done manually by someone pulling exports into a spreadsheet. That's not analysis – it's data assembly.

The case for a hospitality data warehouse

A data warehouse solves the structural problem by creating a single destination for data from all of those source systems. PMS exports land alongside POS transaction data, OTA booking records, loyalty programme feeds and guest satisfaction scores. Once that data is in one place, it can be modelled consistently and queried in ways that no individual source system allows.

The practical output is a reporting layer that lets your commercial and operations teams ask real questions: Which channel produces guests with the highest F&B spend? Which property has the lowest spend-per-occupied-room, and is that a pricing issue or a product issue? Which loyalty tier members are most likely to book direct on their next stay?

These aren't complex questions. They're the questions that operators ask every day. The reason they're hard to answer isn't analytical – it's that the data required to answer them has historically sat in systems that don't talk to each other.

A data warehouse doesn't replace your PMS, your POS or your loyalty platform. It sits alongside them, pulling data from each into a clean, consistent reporting layer. Your operational teams keep using the systems they know. Your commercial and leadership teams get access to analysis that was previously impossible.

Key data sources to connect

The sources worth prioritising for a hospitality data warehouse are broadly consistent across property types, though the specific systems vary:

Not all of these sources will be available via clean APIs. Some PMS systems offer robust data exports; others require custom extraction. Part of the work in building a hospitality data warehouse is understanding the extraction constraints for each source and building pipelines that are reliable enough to trust.

Guest lifetime value and segmentation

The question hospitality operators most want to answer – who are our most valuable guests? – is also the hardest to answer cleanly. It requires something that doesn't exist in any individual source system: a unified guest identity across multiple stays, potentially across multiple properties.

The technical challenge here is identity resolution. A guest who stayed at your Edinburgh property in March and your London property in October may appear in each PMS under slightly different profile data. Their loyalty number might be attached in one stay but not the other. They may have booked direct in Edinburgh and through an OTA in London, appearing as two different records in your booking data.

Resolving those records into a single guest identity – and then aggregating all revenue and behaviour data against that identity – is where genuine guest lifetime value calculation becomes possible. It's also where most hospitality groups have no current capability at all.

Once identity resolution is in place, segmentation becomes practical. You can identify guests who consistently book suites, guests who generate high F&B spend relative to room rate, guests who respond to loyalty communications and guests who don't. Those segments drive genuinely useful commercial decisions: which guests to target for direct booking incentives, which to offer room upgrades, which properties have the highest concentration of high-value guests and what they have in common.

Revenue management and demand forecasting

Revenue management tools like IDeaS and Duetto are sophisticated systems that already do a great deal with forward-looking demand data. They're also only as good as the data underneath them.

A data warehouse doesn't replace a revenue management system – but it improves what feeds into it. Connecting historical demand patterns, actual achieved rates and booking pace data in a clean, consistent format means the forecasting models have better inputs. It also means your revenue management team can interrogate historical decisions in ways that aren't always easy within the RMS itself.

More practically, a data warehouse lets you build demand views that your RMS may not surface directly: booking pace by channel, the relationship between lead time and average rate, or how demand at one property in your group tends to predict demand at another. These patterns exist in your data. Most operators can't see them because the data hasn't been brought together.

Operational and F&B reporting

F&B is where the gap between available data and useful reporting is often most acute. Most F&B operations run detailed POS reporting at outlet level – covers, average spend, category mix – but struggle to connect that data to the guest context. A busy Saturday in the restaurant looks the same whether it's driven by hotel guests or walk-in covers, and the commercial implications of each are different.

Connecting POS data to PMS occupancy data at the date level gives you occupancy-adjusted F&B performance. A restaurant doing £12,000 on a night when the hotel is at 40% occupancy is a very different result from the same revenue on a night at 95%. That context shapes how you staff, price and promote the outlet.

At a more granular level, linking F&B transactions to individual guest folios – where POS integration allows it – gives you spend-per-guest data that's genuinely actionable. It tells you which guest segments spend in F&B, which don't, and what the correlation is with room rate, booking channel or length of stay. That's the data that drives meaningful upsell strategy.

Multi-property reporting and benchmarking

For hotel groups, the clearest immediate benefit of a data warehouse is often the simplest one: consistent reporting across properties. When every property reports from its own PMS using its own export format, group-level performance reporting is manual, slow and often inconsistent. Metrics that should be comparable across sites end up being measured differently because the underlying exports were built at different times by different people.

A data warehouse standardises all of that. RevPAR, ADR, occupancy, TRevPAR and F&B spend per occupied room are calculated consistently across every property using the same logic. Comparing performance across sites becomes straightforward, and anomalies – a property with consistently lower F&B capture rate, or one where direct booking share is declining – become visible without anyone having to assemble a spreadsheet to find them.

Benchmarking within the group also becomes possible in ways it wasn't before. If your Manchester property consistently achieves higher F&B spend per occupied room than your Bristol property, a data warehouse lets you start investigating why. Is it outlet mix? Pricing? Guest profile? Channel source? Those questions have answers in the data – but only if the data from both properties is in the same place.

Route B builds data warehouses for hospitality operators. Get in touch to discuss your reporting requirements.

Get in Touch