Guest revenue
Dates that sold by this point last year and have not sold this year. Short gaps in the next ninety days. Past guests due back. Quotes that went cold. Your systems already hold every one of them. Nobody has the time to go looking.
What it looks for
Each one needs data from more than one system, held in one place, with enough history to compare. That is why the answers are not already on a screen somewhere.
The single most valuable signal, and the hardest to fake. It needs two years of history in your property management system and somewhere to compare them night by night. Nothing in a standard stack computes it.
Not every gap. Only the ones worth someone picking up the phone about, ordered so the most valuable is first.
Ranked by average stay value rather than lifetime value, so your best opportunity today rises instead of your best customer ever.
Most operators never mine them. The quoted price is already sitting in the system, which makes the follow up specific instead of generic.
The honest part
So we do not pretend otherwise. We built a detector for minimum stay gaps, ran it against a real portfolio, and found the revenue management tool was already doing the job properly across almost every home. We retired the detector and kept a silent monitor in case that ever stops being true.
The four above are the ones a pricing tool cannot see, because they need booking history, guest records and quote data together in one place. A pricing tool sets rates. It does not tell a named person which four properties to call this morning.
The difference
A list is the easy half. Every item arrives as work, not as a chart.
Because the loop closes, we can report what was actually recovered. That is the only number that justifies the system.
Measured, not estimated
In week one we reconcile to your own monthly report and agree what a booked night means, which revenue basis you report on, and how you recognise it. Those answers go in writing, because the same month read three different ways gives three different numbers, and we would rather argue about it once than every month.
After that, every month: what the queue raised, who actioned it, and what came back, against the baseline. We do not estimate uplift and we do not claim revenue that would have arrived anyway.
Guest data
Not as a policy, as an architecture. The AI can read two schemas. Both were audited and contain no email address, phone number or postal address at all. The raw and staging layers, where contact data lives, are denied outright and verified by probe.
A test fails the build if that ever stops being true, so the first person to add an email column somewhere cannot quietly break the guarantee. It is the only form of this promise worth making.
Setup
Your PMS, pricing tool and CRM, read only, into one warehouse that belongs to you.
Your revenue basis, your definitions and your thresholds, reconciled against your own report.
The four detectors run daily and issue work to named owners. A person approves every send.
Monthly, what was raised, what was actioned and what was recovered.
We will ask what you run and what it already does for you, then show you what is sitting in your own calendar and guest history. If there is nothing there, that is a useful answer too.