Seven live analytics tabs turn a hotel group's contact database into direct answers, and every number is one click away from the exact guests behind it.
A marketing manager at a hotel group asks a simple question in a Monday meeting: how many guests who stayed at the coastal properties last quarter have a verified email, a WhatsApp opt-in, and haven't booked again since checkout? In most systems built for hospitality, that question doesn't get answered in the room. Someone opens the reservation system, exports a CSV, opens the loyalty platform, exports another, opens a third tool for consent status, and starts stitching a spreadsheet together. By the time a merged number arrives, three more guests have checked in and two more have unsubscribed.
We've written before about what it takes to get a hotel group's guest data into one real record instead of a dozen half-matching ones scattered across a booking engine, a loyalty program, a WhatsApp inbox, and an email list. That work only pays off if someone can actually see what's in the record once it exists. This post is about the part that turns a unified contact database into something a marketing team opens every day: Contacts Analytics, a seven-view suite sitting directly on top of the same customer data platform doing the matching underneath.
Most hospitality CRM tools that promise analytics are really report generators. Someone configures a job, it runs overnight, and the numbers on screen the next morning describe yesterday. That's fine for a monthly board deck. It is not fine for a marketing manager deciding this afternoon whether a re-engagement send is worth building.
Contacts Analytics was built the other way. Every tab queries the tenant's real, current data at the moment the page loads, not a snapshot computed hours earlier. We tried the snapshot approach first: a nightly job that pre-calculated the heavier numbers and stored them for the dashboard to read. It shipped, and it was wrong within the same day. Every tenant, every number, was up to twenty-four hours stale, whether the underlying data had changed five minutes ago or not at all. We pulled it and rebuilt the suite to query live instead. That's the same decision covered in more depth in skipping the nightly batch job entirely. The two calculations expensive enough to need any caching at all, a property-by-property rollup across a whole portfolio, and the join that connects contacts to their real bookings, refresh themselves quietly in the background rather than making anyone wait, keeping the lag to minutes rather than a full day. Everything else, including the view that shows who is checked in right now, reads straight from the live reservation and contact tables on every load.
The detail that changes how this actually gets used day to day: the numbers that matter on every tab are links. Click "unreachable contacts" and you land directly in the contacts list, already filtered to exactly those guests. No filter builder. No second tool. No colleague rebuilding from memory what "unreachable" was supposed to mean. Click a single property's booking figure on the per-hotel table and you get that property's guests with a reservation, and only those guests.
The same filter language also powers segments, the audience building block every journey or broadcast targets, so a filter proven here doesn't have to be rebuilt from scratch in the segment builder. That sounds like a small convenience until you have spent an afternoon rebuilding, by hand, a filter that a chart already proved existed. It is the difference between analytics that describe your database and analytics that let you act on it.
Can we even reach these people? Reachability & Consent breaks the database down by email consent, WhatsApp consent, both, and neither, and shows which acquisition sources bring in guests who actually opt in versus ones who mostly don't. A source that adds volume but no consent is a source worth reconsidering.
Is the data itself trustworthy? Database Health separates verified email addresses from risky ones and from addresses nobody has checked at all, tracks the unsubscribe rate, and scores completeness field by field: email, phone, date of birth, gender, nationality. A hotel group cannot run a birthday journey off a date-of-birth field nobody has ever measured for gaps.
Where is each guest right now? Lifecycle & Bookings renders a live stay-state rail, pre-stay, in-stay, post-stay, computed directly from reservations rather than from a status field that can quietly drift out of sync, with real named guests in each stage so it reads as people instead of a bucket count. Beside it sits a portfolio-wide view of how much of the contact base actually has a booking attached, rather than just a name and an email sitting idle.
Who are these guests? Demographics & Language covers gender balance, age bands, and the top fifteen nationalities in the base, flags and full country names included, plus a cross-cut of gender against booking status so outreach can be checked against who is actually converting, not just who is in the database.
Where did they come from? Sources & Acquisition rolls every acquisition channel into one canonical table: contact count, share of the base, consent rate. Near-duplicate source labels get folded together automatically, so a channel doesn't get quietly undercounted because someone typed its name two different ways in two different systems.
How does this property compare to that one? The Per-Hotel tab is built for a group running dozens of properties: a sortable, searchable table across the whole portfolio, contacts, reachable share, consent, booking association, growth, and top language, paginated so a comparison across dozens of hotels doesn't turn into dozens of open browser tabs, with a rollup card summarizing whichever page is on screen. It only works because a guest doesn't get double-counted for staying at more than one property, exactly the problem a hotel customer data platform exists to solve.
And what changed recently? Overview sits above all of it with its own date-range control, governing the whole tab at once rather than mixing a windowed chart with an all-time figure beside it, the kind of quiet mismatch that makes a dashboard easy to misread. New contacts, reachable percentage, top language, a growth trend, and a data-quality read on exactly the guests acquired in that window, not the whole historical base, so a marketing manager can judge whether this month's acquisition is worth marketing to before committing budget to it.
None of this works on top of duplicate, fragmented contact records. A per-property comparison is meaningless if the same guest is quietly counted at three different hotels under three different profiles. A reachability figure is meaningless if a chunk of the "unreachable" contacts are just duplicates of someone marked consented somewhere else in the system. Every view in Contacts Analytics inherits its accuracy from the golden-record work underneath it: one real customer data platform, one contact per guest, matched across however many stays, channels, and properties that guest has actually touched.
That is the payoff of building the record properly in the first place. A hotel group running this at scale can, for the first time, look at its own guest database and trust what it sees, then click straight through to the exact guests behind any number that matters. Not a report. A window.
See what the platform looks like end to end on the CDP page, or check pricing for what it takes to put your own contact database on it.
Thirty minutes, your real properties, no generic demo environment.
Most CRM analytics precompute overnight and call the wait good enough. GuestMaker's contact analytics run live instead, and says plainly which part still isn't fast.
Your best guest has stayed at four of your hotels, and your systems have no idea they're the same person. Here's what actually fixes that.
A guest who has stayed at four hotels in your group exists as four separate strangers, until an identity resolution engine turns them into one guest for good.
