Tentative and Time Machine — alternative timelines

It’s Friday afternoon, September 4, at Hotel Peaqplus City. Daniel is scanning the group inquiries in the Sales Pipeline, and on the week of October 12–16 he sees a rare pile-up: three tentative groups awaiting a decision, on partly overlapping dates. A tentative group is an optioned offer not yet signed — the organiser asked for and received a room block (group block) but hasn’t committed; a definite group is already under contract. The three offers:

• Group A — a corporate group around a conference: 30 rooms, nights of October 13–15, offered rate 88 EUR, the sales team’s estimated conversion odds: 60%;
• Group B — a company training: 25 rooms, October 14–16, 92 EUR, 40%;
• Group C — a tour-operator circuit: 20 rooms, October 12–14, 78 EUR, 25%.

The peak night is Wednesday, October 14 — all three blocks overlap there. The OTB (on the books — the occupancy already in the book) stands at 14 rooms today, and transient (individual, open-market) demand would, per the long-horizon forecast (lesson 55), build to 48 rooms by arrival on its own. If all three groups sign, the house faces 48 + 75 = 123 rooms of demand on 80 rooms — transient sales would have to be closed, and even then the blocks would squeeze. If none signs, the Wednesday stops at 60% — with a 40%, 32-room hole.

Adam looks in at the door: “That October week — full house or hole?” Daniel’s honest answer: “Both. Depends which timeline.” This lesson is about how an RM works with several possible futures at once — and how they use the preserved past to learn from their own decisions.

A tentative group is not half a booking

The first and most important conceptual step: a tentative group is not “half a booking” but a probability distribution. The 60%-likely, 30-room group A is not “18 rooms” — it is 30 rooms with 60% probability and 0 with 40%. The outcome is binary: the group either comes or it doesn’t; “comes a little” does not exist.

Expected value (EV: probability × impact) is still a useful building block — we worked with exactly this in lesson 29 for group evaluation and in lesson 55 for the manual forecast correction. The three groups’ combined expected value: 30 × 0.6 + 25 × 0.4 + 20 × 0.25 = 18 + 10 + 5 = 33 rooms. For the forecast’s group line, that is the right number.

But here comes EV’s limit, and this is the expert-level point: you can forecast on the EV — you cannot allocate on it. You cannot admit “33 rooms’ worth of groups”, because no such combination exists: in reality one of the eight possible outcomes happens, and none of them is 33. Pricing and capacity decisions must therefore be built not on the expected value but on the full map of scenarios. That is what the scenario table is for.

Worked example 1 — the map of eight timelines

Three binary outcomes give 2³ = 8 combinations. For the peak night, October 14, Daniel writes down for each: the group rooms, the occupancy picture (using transient’s untouched final state of 48 rooms), and how many transient rooms would have to be displaced (displacement — lesson 40) if the house overflows. The probabilities come as the product of the three odds — under the simplifying assumption that the three decisions are independent of each other (we will come back to this):

(Check: the probabilities sum to 18 + 27 + 12 + 6 + 18 + 9 + 4 + 6 = 100% ✓; for example “A only” = 0.6 × 0.6 × 0.75 = 0.27 ✓; on the A + B branch, 48 + 55 − 80 = 23 displaced rooms ✓.)

Three readings jump out of the table:

1. The expected occupancy is 72.1 rooms (90%) — and this number happens on no timeline. (0.18 × 48 + 0.27 × 78 + 0.12 × 73 + 0.06 × 68 + 0.37 × 80 = 8.64 + 21.06 + 8.76 + 4.08 + 29.6 = 72.1.) The 90% is a statistical shadow: the real outcomes are 60%, 85–97.5%, or a full house. Whoever prices to the “expected 90%” prices a house that does not exist.
2. There is a 37% chance the transient has to be squeezed (the four displacement branches together: 18 + 9 + 4 + 6), and an 18% chance a 32-room hole remains. The two extremes are alive at once — which is why you can neither “close boldly” nor “cut the rate to be safe”.
3. The A + B + C branch is the worst full house: 43 transient rooms would be displaced at the 110 EUR BAR, while the 75 group rooms’ weighted average rate sits below 87 EUR (30 × 88 + 25 × 92 + 20 × 78 = 6,500 EUR, divided by 75 rooms ≈ 86.7 EUR). The price of that full house is heavy mix erosion — this branch alone justifies not holding this many open options.

Daniel puts a fourth view next to the table: the plan timeline. Every report has the Tentative toggle: switched on, the numbers show not the actual bookings but the Budget-projected state — the week as if the plan came true. For October 14 the budget expects 68 rooms (85%). Looking back at the table: seven of the eight branches reach the plan level — only the “none” branch (18%) falls dramatically short. So the plan holds with 82% probability, but it is not “certain” — and now you can also see exactly which outcome to fear.

A robust decision — one that holds up on every branch

The table is not there for its own sake: the question is what do I do today, on September 4, when I don’t yet know which branch is coming. Two wrong answers offer themselves. A rate cut is optimal only on the “none” branch (18%) — on the remaining 82% it would cheapen a house that fills anyway. Closing transient early is optimal only on the A + B + C branch (6%) — with 94% probability it would throw revenue away. Both bet on a single branch out of eight.

The expert answer is the robust action list: moves that are acceptable on every branch — not the best on any one branch, but causing serious damage nowhere.

• A deadline ladder on the options. From the partner’s point of view, a tentative is a free option: they get flexibility, the hotel carries the uncertainty. An option needs an expiry. Daniel forces the decisions in steps: group C by September 11, B by September 18, A by September 25 — Friday deadlines, one decision a week. The order is deliberate: C has the lowest odds and the lowest rate, yet holds 20 rooms — C is the cheapest to let go. Every expiry halves the uncertainty: 8 branches become 4, then 2, then 1, and the table is recomputed at every step.
• A ceiling on the option inventory. Lesson 41’s group ceiling logic, live: the house should not hold 75 rooms of open options against a 48-room transient expectation. Daniel sets the ceiling for open group blocks at 55 rooms — A and B fill it; so C gets not a “third guaranteed block” but second-option status: if A or B steps back by its deadline, the block can be C’s; until then we offer C an alternative date. Said out loud, this is less comfortable for the partner — but more honest than a block we could never release on the full-house branches anyway.
• Price: neither down nor closed. The BAR (Best Available Rate — the public best available rate) stays at 110 EUR. The review points are not calendar days but triggers tied to the deadlines (lesson 50’s scenario logic): after every option decision, a recomputed table and a pre-agreed action package — if two groups sign, the transient rate ladder starts upward; if all three fall away, the targeted, rate-image-protecting stimulation package (lesson 46) comes for the remaining weeks.
• A wash reserve on the “safe” branches too. Even a signed group is not 100%: a contracted block typically erodes towards arrival (wash — lesson 29). Daniel keeps a reserve on the materialising blocks in the displacement maths too, which is why he does not close the last transient rooms early even on the full-house branches.

And a discipline note on the independence assumption: if the three groups were coming for the same event, their outcomes would move together — the “none” and “all three” branches would gain probability, the middle ones would lose. The table’s structure still works; the probabilities just have to be entered with the sales team’s knowledge, not by mechanical multiplication.

What happened to the October week?

The deadline ladder did its job. Group C did not respond by September 11 — the option was released, and 4 of the 8 branches remained. Group B cancelled on September 18: the training was postponed to spring. Group A signed on September 25 — for 27 rooms instead of 30: the erosion had already begun in the offer phase. So the realised timeline was essentially the “A only” branch — the branch that stood at 27% in advance: the most likely single outcome, yet with 73% probability something else would have happened. October 14’s final: 50 transient + 27 group = 77 rooms (96%), with the BAR untouched. On this branch, a September 4 panic rate cut would have cheapened a house that nearly filled anyway — and closing early would have thrown transient revenue away. The robust list was the “perfect” decision on no branch — and a mistake on none. That was exactly its job.

Time Machine — the preserved past

The tentative table looks forward: several possible futures. The second tool looks back — and demands the same discipline, in reverse.

The problem it solves is familiar in every hotel: months later — say, in early November — someone asks: “was that September rate increase a good decision?” — and the debate runs on memories. Nobody remembers exactly what the OTB was, what the pace looked like, what could be known at the time. And human memory cheats systematically: once the outcome turns out bad, everyone “saw it coming” — that is hindsight bias: judging yesterday’s decision, made with yesterday’s knowledge, by what we know today.

Peaqplus’s Time Machine replaces that debate with data. Its foundation is the snapshot layer: the system keeps a snapshot of every data refresh — like a photo album with a picture of the house’s state for every day; the PMS always shows only today’s state, the album keeps yesterday’s too. Time Machine is that album’s page-turner: you pick an earlier data-refresh day — the date picker lists every stored refresh, with quick jumps of −1, −7 or −30 days — and the whole interface switches as if you were looking at it that day: that day’s OTB, that day’s pace, report by report. While you are in the past, a yellow warning banner reminds you the data is not current, and at the end of your session the view returns to the present on its own. It is for three things:

1. Retrospective learning — checking your own decisions afterwards, against the information available at the time. The question is not whether the outcome was good, but whether the decision followed from the data visible then.
2. Disciplining the “what would have happened” analyses — a counterfactual debate is only worth anything if you can pin down what could be seen and known then, not what we know today.
3. Pattern building — comparing a similar past date’s state at the time with today’s date’s state today: the date-level version of lesson 37’s curve analysis (“where did last year’s conference Wednesday stand at T-20, compared to where this one stands now?”).

And the two tools connect: the Tentative toggle can be switched on inside a past day’s state too — “how did the plan timeline look on last week’s data”.

Worked example 2 — the September rate increase on the scales

The disputed decision: Saturday, September 19. On September 1 (T-18) Daniel raised the BAR from 115 to 125 EUR. The final: 70 rooms (87.5%) — last year the same Saturday closed at 74. Adam’s question at the Monday revenue meeting on September 21 (lesson 47): “didn’t we fall behind because of the increase?”

Daniel steps back with Time Machine to September 1 — the state of twenty days earlier, one click. The picture at the time: OTB 58 rooms (72.5%), last year’s same point 54 rooms (67.5%) — a +5 pp lead; the previous 7 days’ pickup +11 rooms, accelerating. A leading position with accelerating speed: in lesson 37’s language, a textbook rate-increase signal. Given the information available at the time, the decision was right.

And the outcome? The numbers help here too. This year’s revenue for the Saturday: 70 × 125 = 8,750 EUR. The strictest counterfactual assumption — that without the increase the entire 4-room shortfall would have vanished, i.e. the lag was purely about price —: 74 × 115 = 8,510 EUR. So even under the assumption least favourable to the decision, the increase earned +240 EUR on the night. (Check: 8,750 − 8,510 = 240 ✓.) The real cause, incidentally, lay elsewhere: in the second week of September two competitors launched aggressive campaigns — unknowable on September 1, but it enters the playbook as a lesson: after a rate increase, competitor rate-watching is tightened for two weeks (lesson 32).

Notice what Time Machine did here: it separated the quality of the decision from the quality of the outcome. Outcome-based, September 19 is a “shortfall”; decision-based, it is a well-signalled, well-timed increase that made more money even on weaker occupancy. Without that separation the organisation would draw the wrong lesson — and next time would not dare make the right increase either.

One profession, two-way time

The two tools’ shared philosophy: an RM does not work on a single timeline. Forward, there are several possible futures — the tentative table is the normal-operations version of the scenario thinking we used in lesson 50 for pickup decisions and in lesson 62 in crisis mode. Backward, there are the preserved past states — because the quality of your decisions can only be judged against the information of the time, and without that, the “decision quality ≠ outcome quality” principle remains an empty slogan: a good decision can have a bad outcome (the September increase against a campaign week), and a bad decision a good one (the panic rate cut “rescued” by an unexpected demand wave). The loop closes in the next lesson: Time Machine preserves the state of the data at the time — lesson 64 is about recording the decision itself, with its reasoning, so that retrospective learning has both halves.

Manually vs. Peaqplus

Manually, the tentative table’s raw material has to be scraped together from the sales records and the PMS (property management system): which offer is live, for which dates, at what odds — typically in email threads and in people’s heads. With past states it is worse: most hotels simply have no preserved past state — at best accidentally saved report exports; the retrospective debate stays memory-based, and hindsight bias works unopposed.

In Peaqplus, the ingredients are ready. The Sales Pipeline provides the tentative offers’ status, dates and displacement evaluation (lesson 40); the daily pickup report and the date-by-date OTB/pace picture live in the Business Intelligence module (lesson 50) — the scenario branches’ occupancy picture is built on it. The Tentative toggle switches any report to the Budget-projected view — the “what if the plan came true” timeline. Time Machine returns the state of any stored data-refresh day from the daily snapshots — with quick jumps, the yellow banner, and combinable with the Tentative toggle. What the system does not take off your shoulders: assembling the 2³ combination table, judging the probabilities and the robust action list — that remains your craft; the system adds the timelines.

Key takeaways

• A tentative group is a probability distribution, not half a booking. Expected value (EV) is right for the forecast (lesson 55), but you cannot allocate on it: the outcome is binary, and the “expected 90%” is a number that occurs on no timeline.
• The scenario table is the decision basis: 2^n combinations, each with an occupancy picture, displacement and probability. In the example, an 18%-probability 32-room hole and a 37%-probability transient squeeze were alive at once — which is why neither the rate cut nor early closing was defensible.
• Make robust decisions, not single-branch-optimal ones: a deadline ladder on the options (a tentative is a free option for the partner — it needs an expiry), a ceiling on the open block inventory (lesson 41), price triggers tied to the deadlines, a wash reserve on the full-house branches. Every option decision halves the uncertainty.
• The snapshot photo album is the antidote to hindsight bias: Time Machine returns any stored day’s state — judge the decision against the information of the time, and compute the counterfactual under the strictest assumption. The September increase still earned +240 EUR on the night.
• Decision quality ≠ outcome quality. Scenarios forward, preserved states backward — lesson 64 completes the learning loop by recording the decisions themselves.