Decisions and Revenue Track — the life story of decisions

Mid-January, Thursday afternoon. In the Hotel Peaqplus City meeting room, the annual revenue look-back is under way — this year, at Adam’s request, item by item, month by month. At August the page-turning stops. “I still don’t understand this one. In mid-August we raised peak-weekend rates by 15% — and then the last week of the month underperformed. Why did we raise? Whose idea was it? And what did we base it on?”

Silence. Daniel remembers the compset (the competitive set — lesson 44) starting to move up, and that they reacted to it. According to the sales manager, the owner’s revenue expectation was the pressure. And Adam remembers arguing against the increase at the time — though he is no longer sure of that himself. Twenty minutes go by with three people telling three different stories about the same decision — with no referee.

Daniel finally opens Time Machine (lesson 63) and pages back to the day of the increase, in mid-August: pace +9 rooms above the curve, OTB (on the books — the reservations already in the book) at 71%, the compset median indeed higher than in July. So the data of the time can be reconstructed — the photo album keeps it. But the data only says what things looked like — not what people thought about it. The increase’s reasoning, the assumption behind it, the counter-arguments and the decision-maker itself: all of it evaporated without a trace in five months. The debate didn’t get settled; it got tired.

This lesson is about why that is not a memory problem but a methodology problem. An 80-room city hotel makes several hundred revenue decisions a year: typically 4-6 at the weekly meeting, plus daily rate moves, restrictions, promotions, group yeses and nos. And most hotels learn exactly zero from those several hundred — not out of negligence, but because the decisions have no life story: they are born, they act, and they vanish. The decision log and the retrospective routine built on it turn this around: decisions become teaching material.

The “why” is not data — it must be recorded

In lesson 63 we learned: the data state can be recovered — Time Machine shows what you would have seen on a past day. The “what we did” is also reconstructible: the rate history, the restrictions, the bookings are all there in the systems. What no system stores by itself is the decision’s third layer: the why. What assumption did you start from? What did you expect from the move? What was the argument that settled it? Who said don’t?

This layer only exists if you wrote it down at the moment of the decision. It cannot be recovered later — more precisely: later it can only be forged, because memory rewrites itself in light of the outcome (we come back to this in a moment). Revenue management thus lives in a strange asymmetry: the industry invests orders of magnitude more in data infrastructure than in decision infrastructure — yet in the end it is not the data that produces the revenue, but the decision.

The anatomy of the decision log

What does it mean to record a decision “well”? Six elements — fewer is incomplete, more no longer earns the daily discipline:

A few notes on the elements. Number 2 is the easiest — the “what” can be looked up anyway; only clarity is at stake. Number 3, the state at the time, goes into the log (even though Time Machine would produce it) because at the review you don’t want data archaeology for every item: three numbers cost ten seconds at recording time, ten minutes half a year later. The key element, though, is number 4: the reasoning. It is the only one that can be recovered from nowhere — and at evaluation it decides whether you learn anything at all. The reasoning’s value lies in the assumption it spells out: “weekend demand is price-inelastic” is a testable claim that turns out true or not. “I felt we could raise” is not an assumption. Element 5 is the sibling of lesson 61’s experimental discipline: the definition of success is born before the decision, not after. And element 6 is the guarantee that the evaluation becomes a calendar event, not a “someday”.

In practice this is not a notebook question. Peaqplus’s decision layer (Decisions) and its Revenue Track page keep exactly this log: decisions captured at the weekly revenue meeting (lesson 47’s action list grows into a system here), items converted into decisions from discussions started next to report rows (that is lesson 65’s subject), and directly added decisions all live in one shared list, with a source filter. Per decision: title, reasoning, type (pricing, restriction, sales, marketing, distribution), affected period — even several date ranges —, owner and due date. The owner automatically gets a task and a notification; when the task is done, the decision closes by itself — but if the tasks get cancelled, the decision closes with a “not executed” status. That makes visible what a hotel without a log never sees: the decision that was declared but never done. A separate type exists for the observation: something with no action (“weekend pickup has been slowing for two weeks”) can be logged too — no task, a searchable trace; at the review, such early signals turn out to be gold. The state at the time and the expected effect Daniel writes into the reasoning — three numbers plus one assumption sentence, part of the recording routine.

Four forces the log protects against

Why aren’t memory and good faith enough? Because our head is not an archive but a storyteller — and it works against learning in four well-known ways.

1. Hindsight bias. Once the outcome is known, the memory rewrites itself: whatever worked, everyone remembers having supported; whatever didn’t, everyone “told you so”. The January scene is exactly this — Adam honestly remembers opposing the increase, and he may be wrong. Nobody is lying: the brain does this, everyone’s, yours too. The only antidote is contemporaneous written recording — the log is the witness who gave testimony before knowing the ending.

2. Outcome bias. In lesson 63 we stated the principle: judge the decision on the information available at the time, not on the outcome — a good outcome does not prove the decision was good. Without a log this principle is unenforceable, because the “information available at the time” and the “what we thought about it” are not there for the judgement. And the more dangerous direction of the bias is not the unlucky good decision unfairly condemned, but the reverse: the lucky bad decision is the most dangerous teacher. A move built on a faulty assumption, rescued once by a strong market, gets fixed as a “proven tactic” — the team repeats it at higher stakes, until the day the market does not rescue it. The log catches this by having the review interrogate the assumption, not just the result.

3. The volatility of team knowledge. A hotel’s decision knowledge typically lives in one or two heads. When the RM changes — and in this profession people change every few years — that knowledge walks out the door on the last working day: the successor inherits the systems and the rates, but not the “whys”, and starts the same mistakes over. A kept decision log is the hotel’s institutional memory (in lesson 61 we used that phrase for experiments — the log is the general case): the decision culture becomes the organisation’s property, not the current RM’s.

4. The unspoken assumption. The fourth force is not a bias but an absence: most revenue decisions have an assumption behind them that was simply never spoken. The obligation to record brings it to the surface — it is while writing that “let’s raise, the weekend is strong” turns out to really mean “the remaining demand is price-inelastic”, which is now a debatable, checkable claim. And there is a quiet side effect: whoever knows their reasoning will be reread in six months thinks more sharply — lesson 60’s argumentation craft lives on in writing. If you cannot write the assumption down in a single testable sentence, that is not a recording problem but an analysis gap — and better to discover it before the decision than at the review.

The quarterly decision review

By itself the log is just a data store. What makes it teaching material is the retrospective routine: 60-90 minutes each quarter, Daniel and Adam — ideally with the core of the weekly meeting circle (lesson 28) —, with the closed decisions that have reached their review date on the agenda. Three questions per decision, in this order:

1. Did the expected effect land? This needs the pre-agreed metric — without it the answer is opinion, not fact.
2. If not: was the assumption wrong, or the execution? This is the review’s most important cut. Wrong assumption = we believed something else about the world → update the worldview. Wrong execution = we thought right but did it late, half-way or through the wrong channel → update the process.
3. Was it wrong even on the information available at the time? This is where Time Machine comes in — for a recent decision it is one click; for an older one, the log’s element 3, the state at the time, replaces the data archaeology. If the decision was right on the data visible then and the market turned — that is not a mistake but bad luck, and it earns no rule change.

Let’s look at Hotel Peaqplus City’s first full quarter on the new system. In the second quarter, 23 decisions entered the log; by the July review, 14 of them had reached their review date. The tally: 9 landed, 2 wrong assumptions, 1 good decision with a bad outcome — and 2 “not executed”: decisions declared but never done, which without the log would never even have surfaced. Five instructive items up close:

Row 4 is the textbook case of the wrong assumption — and it can be taken apart numerically only because the expected effect was fixed in advance. The assumption was that festival demand arrives in the final week, so at T-8 (8 days before arrival) there was still room to raise. The facts: 31,500 EUR instead of 34,000, i.e. −2,500 EUR (−7.4%), and a mere 9 room nights at the raised rate. Looking back with Time Machine, the diagnosis is unambiguous: the festival pace had already flattened around T-14 — the demand arrived in the T-30 to T-14 booking window, and the increase knocked on a door that had already closed. It was not the execution that failed (the new rate went live the same day) but the worldview: festival guests book earlier than we believed.

Row 5 is the mirror image — and the review’s most important acquittal. The outcome is negative: the group’s 40 room nights at 92 EUR brought 3,680 EUR, while the transient demand that later erupted would have taken the same capacity at a ~128 EUR average — 5,120 − 3,680 = 1,440 EUR of displaced value (displacement — lesson 40). But the log and Time Machine together prove: at the moment of the decision, OTB stood at 31%, pace at −12, and no available information pointed to an event announcement three weeks later. On the knowledge of the time, accepting was the right call. Verdict: good decision, bad outcome — no rule change, no scapegoat. Punishing this row would teach the team never to take secure business for a weak weekend — that is, burning in a bad rule because of one stroke of bad luck.

From pattern to rule

After the individual verdicts comes the review’s higher level: pattern hunting. One decision’s lesson is an anecdote; three similar ones are a rule candidate. Daniel runs through the quarter’s rate-increase decisions and notices: three times they raised inside T-14, and twice out of the three — the festival weekend plus a smaller June case — the raised rate found practically no buyers any more. The pattern’s name: the late increase. The review’s output is a concrete playbook change: “Event and peak-weekend rate increases are decided by T-21 at the latest. Inside T-14 we raise only if the last 7 days’ pickup (lesson 50) proves the demand is still alive.” One or two new rules a quarter — that is the right cadence; nothing from a ten-rule review survives.

And here two earlier lessons meet. In lesson 61 we saw that an independent hotel can carry 4-6 planned experiments a year — but the decision log produces dozens of natural experiments for free: well-documented decisions (state at the time + expected effect + outcome) can be arranged into quasi-test pairs after the fact. Weaker evidence than a pre-planned control, but enough for pattern hunting — and the T-21 rule can even become the hypothesis of a pre-designed, date-paired experiment next quarter. And from lesson 56, the accept/override log of the rate recommendations is the machine twin of the same logic: every override is a decision-log entry — system suggestion, manual rate, reasoning — and the quarterly review reveals in just the same way where the machine consistently wins and where the hand does. The two together are the basis of the machine–human calibration.

Back to the January meeting room

A year later, mid-January, the same meeting room, the same genre: the annual look-back. This time Adam stops at September: “Mid-month we loosened the weekend restrictions — why was that again?”

Daniel opens the Revenue Track, finds the September item among the closed decisions, and reads it out: the decision’s date and owner; the state at the time (pace −9, two compset members had cut rates); the reasoning with its assumption; the expected effect; and the November review’s verdict — landed, +34 room nights in the measurement window. Thirty seconds. Facts instead of debate, a log instead of memories.

The difference is not that Daniel remembers better. It is that out of last year’s several hundred decisions, this year’s lesson count is not zero but six playbook rules and two assumptions about the world falsified in writing — and a team that phrases things more precisely, because it knows: whatever it writes down today will be reread in six months. The hotel makes as many decisions as last year. It just no longer forgets them.

Key takeaways

• The systems store the “what”, and Time Machine returns the data state of the time — but a decision’s reasoning is not data: if you don’t write it down at the moment of the decision, it is lost — or worse: memory rewrites it in light of the outcome.
• The six elements of a well-recorded decision: date + decision-maker, the decision itself, the state at the time (OTB/pace/compset), the reasoning with a testable assumption, the expected effect with a metric and a horizon, a review date. The key is the reasoning — as an assumption, not as a “gut feeling”.
• The log protects against four forces: hindsight bias, outcome bias (the lucky bad decision is the most dangerous teacher), team knowledge evaporating at RM changeover, and unspoken assumptions — whoever knows they will be reread thinks more sharply.
• The quarterly review’s three questions: did the expected effect land? — if not, was the assumption wrong or the execution? — and was it wrong even on the information of the time? A good decision with a bad outcome gets an acquittal; a mistake that forms a pattern (at Peaqplus City: the late increases) becomes a playbook rule — one or two a quarter, not ten.
• The decision log is the free raw material of lesson 61’s experiments and the human twin of lesson 56’s override log — together, in the Revenue Track, the hotel’s institutional memory: the decision culture becomes the organisation’s, not the current RM’s.