RM and data quality — governance, GIGO

Thursday morning, 8:05, early May, Hotel Peaqplus City. Daniel opens the morning insight list (the view familiar from lesson 52), and at the top sits a bold, critical-rated statement:

The corporate segment’s April production is 40% below the average of the previous months — 240 room nights instead of 400, the decline has been continuous since the last week of March, and the May same-point comparison also shows a deepening shortfall.

The narrative layer (lesson 53) adds its part in fluent sentences: “corporate demand shows structural weakening; a review of contracted accounts’ activity and targeted stimulation of the corporate segment is recommended.” The statement passes lesson 52’s four-element test: there is a what, a where, a since-when and an against-what. By 8:40 Daniel is drafting an action plan for the 10 o’clock meeting: a −15% “reactivation” discount for the key contracted accounts for the whole third quarter, plus a sales campaign at the top 10 corporate clients. The machine signalled, the RM acts — exactly as lesson 51’s division of labour prescribes.

One thing saves him. While pulling the house-level numbers for the plan, something catches his eye: April occupancy is 72%, on plan — a hair above it, in fact; the house had counted on strong corporate weeks, and at room level it delivered them. His hands stop over the keyboard. If corporate really dropped 160 nights in a month, the house would have to show it. It doesn’t. So where did the volume go?

That question — not the action plan — turns out to be the most valuable work of the morning. Because corporate did not collapse. The data lied, and it lied convincingly. This lesson is about the fact that every tool of the expert level — insight, narrative, forecast, rate recommendation — stands on one shared foundation: the data. And about how to protect that foundation with a system, not with luck.

The GIGO principle — the confidently wrong machine

GIGO (garbage in, garbage out) is one of computing’s oldest principles: even the best algorithm returns a distorted result if its input is distorted. In RM, this principle became truly dangerous in the AI era — precisely because the tools got good.

Think through what has been built on the data foundation over the past six lessons. The insight layer (lesson 52) lifts statements out of segment-level data; the narrative (lesson 53) writes believable text from them; the machine forecast (lesson 55) learns from historical segment patterns; the rate recommendation (lesson 56) builds on the forecast. A single distorted input — one segment booked to the wrong place — flows down the whole chain, and every link amplifies it: the insight shapes it into a statement, the narrative rounds it into a story, the forecast learns it, and the rate recommendation hands it back as a decision-ready suggestion.

And here is the key difference between the old world and the new: bad data is more dangerous than missing data. Missing data is visible — an empty cell, an error message, a “not enough historical data” notice — and it counsels caution. Bad data, by contrast, looks complete, and the system does not doubt it: it writes sentences just as confident from a distorted number as from a correct one. The machine does not know its input is garbage. And the RM — the better the system, the more so — trusts the system. The pairing of a convincingly wrong machine with a human who trusts the machine is what turns garbage data into a live decision.

Lesson 52’s baseline blindness trap was this problem’s milder relative: there, the reference base was distorted. Here we go one level deeper: the fact data itself is false. And the rule gets its extension: a surprising insight’s first check is its baseline — and the zeroth is whether the data is true at all.

The four classic error classes

The vast majority of distortions in a hotel’s data estate fall into four classes. Each has its typical birthplace and its typical symptom — they are worth knowing by name, because half of the diagnosis is recognition.

Two observations on the table. First: three of the four are tied to configuration and process, not to technical accident — which means they are preventable. Second: the symptom of these errors is almost always reallocation, not loss. The booking does not disappear; it lands in the wrong drawer — the house-level numbers are fine while the segment picture, the very thing the expert toolkit is built on, is already distorted. In lesson 15 we saw it: the PMS is the source of truth, the RM’s primary data source — but the data arrives into it through the CHM, the booking engine and the front desk’s hands, and it can be broken at every one of those gates.

The worked example — what the system showed, and what was real

Let’s look at what happened at Hotel Peaqplus City in numbers. The house’s April production is 1,728 sold room nights (80 rooms × 30 days × 72% occupancy). The corporate segment’s stable monthly production is 400 room nights at an 85 EUR contracted average rate (ADR — average daily rate).

In early spring, two things happened, independently of each other. One: on March 26 an update ran in the CHM, after which the corporate negotiated rate plan got a new rate code — but the PMS-side mapping table still pointed at the old one, so the system booked the unrecognised bookings, per its default catch-all rule, to the “OTA – leisure” segment (error class 1). What flowed through this path was the CHM-borne share of corporate production — 160 nights a month; the other 240 nights, entered by hand by the sales team, stayed intact. Two: at the end of February, sales signed two new corporate contracts, but the partners’ codes never made it into the system — their bookings arriving from April flowed through the web engine into the “other” catch-all (error class 4).

The result for April:

A quick check: 400 − 160 = 240; 540 + 160 = 700; 15 + 75 = 90, which against 1,728 nights is 5.2% — and both columns sum to the same 1,728-night house total. So the system did not simply err — it reversed the direction: in reality, corporate was at that very moment the hotel’s fastest-growing segment, while the report signalled a collapse.

And the distortion ripples on. The May same-point comparison (lesson 18) shows a deep corporate shortfall — since part of the new bookings is being booked elsewhere. The machine forecast (lesson 55), learning from the distorted April pattern, puts May corporate at around 250 nights instead of the real ~475 — forecast accuracy degrades for months while the source of the error is not in the model at all. And since the rate recommendation builds on the forecast (lesson 56), the error already sits in the suggested rates. On top of that, the net ADR calculation (lesson 43) breaks too: on the 160 rerouted nights the system assumes an OTA commission that does not exist in reality — the channel-cost picture is false in both segments.

And now the most important number: what would the decision built on it have cost? Daniel’s action plan would have granted the key contracted accounts a −15% discount for the entire third quarter — the top accounts’ quarterly volume is roughly 800 contracted nights, and that volume would have arrived at full rate anyway, since demand had not weakened; only its bookkeeping had broken. The bill: 800 nights × 85 EUR = 68,000 EUR of affected revenue, of which 15% is 10,200 EUR of direct revenue loss — for solving a problem that did not exist. Plus the harder-to-quantify damage: a corporate contracted rate is an anchor that takes one email to move down and an annual renegotiation to move back up — the same asymmetry lesson 44 showed at the rate bridge.

The data-quality protocol — four layers

The lesson is not “pay more attention” — attention does not scale. The lesson is a protocol, in four layers: routine, change discipline, governance, audit trail.

1. The monthly reconciliation routine

Once a month, on a fixed day (practically after month close, before the reporting month is “finalised”), a fixed checklist. Not analysis — reconciliation: the goal is not to be clever but to make the numbers agree.

These six points take roughly one hour a month in an 80-room house. Point 2’s threshold deserves special attention: the “other” category is never zero — there are always a few unclassifiable bookings — but its share and its direction speak. In the Peaqplus City example, the March close was still clean; April’s 0.9% → 5.2% jump, however, raises the alarm on its own — independently of the insight signal, without any explanatory statement.

2. Change discipline

The vast majority of distortions do not “decay on their own” — they are born at change: a CHM update, a new rate plan, a new channel, a PMS version upgrade, a new booking engine. So the rule is simple: after every configuration change, a data check is mandatory — not at the next monthly routine, but within 48–72 hours. The minimal version: on the affected path, follow 3-4 fresh bookings all the way from the channel to the PMS segment code. On the first working day after the March 26 CHM update, a five-minute spot check — “where did yesterday’s corporate booking get booked?” — would have prevented the entire April distortion.

3. Governance — who owns the data?

The routine and the discipline only work if someone is responsible for them. Three elements:

• A data owner. One name — at Peaqplus City, Daniel’s — who is responsible for the quality of the data estate: he runs the monthly routine, he must be notified of every PMS/CHM configuration change before the change, and he holds a veto: no new rate plan goes live without a mapping decision. Without him, data quality is everyone’s responsibility — that is, no one’s.
• A coding rulebook. A one-page, written segment mapping document: which segments exist, which channel / rate plan / account belongs to which, and what the rule is for the edge cases (is the corporate walk-in guest corporate or individual?). This is what rules out error class 2: if the front office and sales work from the same sheet, they cannot code two different ways. The document is alive: it is updated whenever a new rate plan or contract is added.
• An onboarding ritual. A new channel, rate plan or contracted account is not live until its mapping row is written into the rulebook and the systems. Our example’s two uncoded contracts are precisely this step’s absence: sales signed the contracts, but nobody asked the question “and where does it get booked?“

4. Audit trail — the footprint of corrections

Once you find the error, the delicate part comes: the retroactive correction. Recoding the 160 nights back to corporate restores the present — but it rewrites the past: the April report now shows something different from what everyone saw for weeks, and every future year-over-year comparison will stand on this corrected number. If the correction leaves no trace, the historical comparisons break silently: six months later nobody knows that April’s corporate number was rewritten after the fact, or why.

Hence the rule: every data correction is logged — when, who, what, why, and at what volume. A sample entry: “May 6, D.: corporate +160 nights/month retroactively to Mar 26, CHM rate-code mapping error; affected reports: April close + same point.” Two practical principles alongside the log: perform the correction for the whole affected period at once (half-corrected data is worse than consistently distorted data — at least the distorted kind can be corrected in your head), and notify the owner of the machine-learning layer: if the forecast has already learned from the distorted weeks, it must relearn after the correction, otherwise the error lives on in the model even after it has vanished from the data.

The suspicion reflexes — when to doubt the data

The protocol is the regular defence. But the daily reflex is needed too: when should you suspect that it was not the market that moved, but the data that broke? Four patterns where the first question is always data quality:

• A structural break with no trend. Real demand deterioration arrives on a slope — it builds over weeks, and typically shows in several signals at once (pickup, booking window, compset). A configuration error arrives as a step: from one day to the next, in a single cut. If a configuration change can be tied to the date of the break (a CHM update, a rate-plan modification), suspicion is close to certainty.
• One segment moves, everything else stands still. Next to the −40% corporate, the house total does not flinch — which physically means the volume did not vanish; it was rebooked. A genuine segment collapse shows in the total too; a reallocation shows only in the breakdown.
• The report and the house count disagree. If the segment report’s sum differs from the front desk’s reality of the day — the house has 62 rooms occupied, the report sums 65 — then you have a data problem, not an analysis problem. Reconciliation first, analysis after.
• Round-number and impossible-value anomalies. Multiplying 0 EUR ADRs, revenue rows that exactly double, yesterday’s booking posted onto a date next year — these are not “odd market phenomena” but the signatures of data errors.

Notice what they share: each one is cheap — none requires analysis, only a glance at the total, at the date of the break, at the house count. The technical branch of lesson 50’s diagnosis tree was exactly this reflex, translated to date level; and lesson 52’s baseline-blindness rule reaches its full form here: a surprising insight’s checking order is data → baseline → diagnosis. And this is not distrust of the machine — it is honouring lesson 51’s division of labour: the system tells you what the data shows; whether the data tells the truth is a question only you can ask — the machine has no organ for it.

Back to Thursday morning

Daniel’s morning ended up like this: from the question “where did the volume go?” it took ten minutes to reach the “other” category’s 5.2% and the two uncoded accounts, from there the corporate bookings that had flowed into OTA leisure, and the CHM’s change log surfaced the March 26 update. What went to the 10 o’clock meeting was not the reactivation discount plan but three sentences: “Corporate did not fall — it grew: +19%. The data’s bookkeeping broke at a CHM update, plus two new contracts ran without codes. We are fixing it, and introducing a monthly data-check routine.”

Adam’s single question — “and if you hadn’t noticed?” — was the asymmetry calculation itself. The decision that almost got made would have cost 10,200 EUR, plus years of renegotiating a corporate rate level that had been moved down. The protocol that would have prevented it: one hour of routine a month, a five-minute spot check per change — roughly a day and a half of work a year. And the damage, on top of everything, would have stayed invisible: after the bad decision, corporate “recovers” (it was never ill), the action plan looks successful, and everyone would have learned the wrong lesson.

In the next lesson (58) we go deep into total revenue management — where F&B, spa and event data enter the picture next to the room data. That is: more data sources, more gates where the garbage can seep in. What you built here, you will need there — with interest.

Key takeaways

• GIGO: every member of the expert toolkit is built on the data foundation — insight, narrative, forecast and rate recommendation carry a single distorted input all the way through and amplify it. Bad data is more dangerous than missing data: the missing kind is visible, while the bad kind looks complete — and the machine errs from it exactly as confidently as it tells the truth from clean data.
• Four error classes cover most distortions: CHM mis-mapping, inconsistent segment coding, PMS sync errors, missing codes. Their shared symptom is reallocation: the house total checks out while the segment picture is already false.
• The power of the numbers: of the 400-night monthly corporate, 160 nights flowed onto a wrong rate code and 75 nights of new contracted volume ran uncoded into “other” — the system showed −40% while reality was +19%. The panic discount built on it would have cost 10,200 EUR; the preventive protocol costs a day and a half a year.
• The protocol’s four layers: a monthly reconciliation routine (segment sums = total; “other” < 3%; uncoded bookings; mapping spot checks; ADR outliers; duplicates) — change discipline (a check within 48–72 hours of any configuration change) — governance (a data owner, a written segment mapping rulebook, “no go-live without mapping”) — an audit trail (every retroactive correction logged, otherwise the historical comparisons break silently).
• The suspicion reflexes are cheap: a step-shaped break with no trend, a single moving segment against a flat total, a report–house count mismatch, impossible values. A surprising insight’s checking order: data → baseline → diagnosis — “is the data true?” is the zeroth question, and only you can ask it; the machine cannot.