Resource
Same time last year: the report your PMS will not give you.
Which dates had sold by this point last year, and have not sold this year? It is the most valuable question you can ask a calendar. No standard tool answers it, and when we built it ourselves, we got it wrong first.
01What the question actually is
It is not occupancy. Occupancy tells you how full you are. It does not tell you whether you are behind.
The question is narrower and more useful. Take today's date. Look at every future night. For each one, ask: had this night already sold by this same date last year? If it had, and this year it has not, that night is behind pace. Not lost, because it may still sell. But behind, and with a track record of selling.
Do that night by night across the whole portfolio and you have a list. Every item on it is a date that your own history says is bookable, and your calendar says is empty.
It is different from a pickup curve, which tells you how bookings are arriving on average. This is per night, per home, and it names the specific dates. That is what makes it actionable rather than interesting.
02Why your PMS will not give it to you
Three reasons, and none of them is a flaw in the software.
- A PMS reports the calendar as it is now. It does not keep a memory of what the calendar looked like on the same date last year. To compare, you need to have recorded the state of every future night, every day, for at least a year. That is a warehouse job, not a PMS job.
- It needs two clocks. The date a booking was taken and the dates the guest stays are different things. This question needs both at once: which stay dates had been booked, as of which booking date. Most reports pick one clock and stay there. See below.
- It needs two years of history in one place. If you changed PMS eighteen months ago, the answer lives in two systems. If your portfolio grew, you need to know which homes existed last year to compare like with like.
So the question is answerable, but only by a layer that sits above the PMS and remembers. Which is why almost nobody has it.
03Booking date and stay date are not the same question
This trips up nearly every conversation about pace, so it is worth being precise.
| Measure | Clock | Answers |
|---|---|---|
| Booking production | The date the booking was taken | How fast are bookings arriving? What is the sales team producing? |
| Stay-date revenue | The nights the guest is in the property | What did the business earn in a given period? |
Same time last year needs both. It asks about stay dates (which future nights) as of a booking date (what had been booked by today's date, one year ago). A report that mixes the two clocks in one tile produces a number that is correct for a question nobody asked.
The rule: separate models for the two clocks. Never in the same tile. Operators ask for both in the same breath and are then confused by an answer to the other one.
04The mistake we made, and what it taught us
The first version was built on the pricing tool's daily snapshots. The pricing tool already records the state of every night every day, because it needs that to set rates. It was the convenient source, and it was already in the warehouse.
The operator challenged the number. They thought it was low. So we measured the snapshot data against the PMS, the actual booking system of record.
The snapshots were missing hundreds of nights, and one home entirely. Rebuilt on the PMS, the same-time-last-year opportunity came out roughly a third larger than the first version had said. The convenient source had understated the answer by about thirty per cent, silently, with every individual row looking plausible.
The rule that came out of it is simple and we now apply it to every signal: revenue and availability facts come from the PMS. Pricing and market context come from the pricing tool. Convenience of access never decides the source of truth.
It is worth saying that the operator was right to push. A number that nobody challenges is a number nobody has checked.
05What to do with the answer
A list of dates that are behind pace is only useful if someone acts on it, and only trustworthy if it is ranked honestly.
- Rank by value, not by count. A behind-pace week in a large home in high season outranks five behind-pace midweek nights in a studio.
- Give every item an owner and a deadline. A date that is behind pace today is worth a targeted offer to a past guest. The same date in three weeks is a last-minute discount. The action changes as the deadline approaches, so the deadline has to be on the row.
- Close the loop. Record whether the date sold, when, and at what rate, so next month you can report what was recovered rather than what was flagged.
If you take one thing from this
Ask your current tools this question, in these words: which future nights had already sold by today's date last year, and are still open now? If the answer is a report, read it carefully for which clock it uses. If the answer is a pause, you have found a gap in the stack, and it is one of the more valuable ones to fill.