Pulse Chat and the conversational RM tool

Thursday afternoon, 2:40 p.m., Hotel Peaqplus City. Adam leans through Daniel’s door: “The bank needs it by tomorrow morning for the loan review: how has corporate revenue developed January through July this year versus last year, and how much is already on the books for the rest of the year?”

Daniel remembers what this question meant two years ago: a report export, last year’s export, merging them in Excel, segment filtering, one mistyped cell reference, half an hour minimum — and all of it on an afternoon when the pricing review is due the same day. Today he opens Pulse Chat and types: “Corporate segment revenue and room nights by month, January–July this year.” The answer is a table and a chart. Second question: “And the same for last year?” Third: “How much corporate revenue is already on the books for August–December?” Four minutes, three questions — the bank’s answer is ready: 262,000 EUR of corporate revenue in January–July this year against 241,000 EUR last year (+8.7%), and the August–December book is also running above last year’s same point.

This lesson is about what changes in RM work now that you can reach your hotel’s data in natural language — through a chat interface driven by a large language model (LLM). And above all about what demos rarely show: the conversational tool’s value turns on the asker’s skill. Asking well is a learnable craft — that is this lesson’s methodological core.

What the conversational interface changes — three shifts

1. The query’s translation step disappears. In the traditional way of working, a translation step is wedged in front of every question: the question in your head (“what was city break’s average rate last August?”) has to be translated into the system’s language — which report, which filter, which date range, which column. That translation takes knowledge (where does the data live?) and takes time. On the chat interface you ask the question the way it sits in your head — the system decides which data and which query answers it. The practical consequence is not that reports become redundant (they do not — we will come back to this), but that the cost of an ad-hoc question falls to a fraction. And what is cheap gets used more: more checking questions, more “let’s have a quick look”, more data touches around the daily decisions.

2. The power of the follow-up: a conversation holds context. Every opening of a report starts from zero; a conversation remembers. If you have asked for July’s segment breakdown, the next question can be as short as: “and the same for last year?” — the system knows that “the same” means July’s segment breakdown. This is not a convenience detail; it is the natural shape of analytical work: analysis is rarely a single question, it is almost always a question chain — a broad question, a surprising detail, a narrowing, a check. In report-based work every link is a new report setup; in chat it is half a sentence.

3. Ad-hoc analysis is democratised. Until now Adam had two options for a numbers question: wait for the weekly meeting (lesson 47), or ask Daniel. Now there is a third: he asks it himself. At first this looks like a change that weakens the RM’s position — in reality it strengthens it. The worst kind of argument with a GM is the one fought over facts (“I think September is weak” — “I think it isn’t”); the chat removes that layer, because the fact is three seconds away for both of you. What remains is the debate over interpretation and decision — and there the RM’s methodological craft (the diagnosis tree, the baseline discipline, scenario thinking) is the real added value. Lesson 51’s division of labour returns: the machine supplies the number; the human is paid for the judgement about the number.

What happens in the background — and what trust is built from

Conceptually the process looks like this: from your question, the system decides which query answers it (monthly summary, daily breakdown with pickup, booking curve, segment breakdown, plan tracking, weak-day search), runs it on the hotel’s real, most recently uploaded data, and writes the answer from the result — with a table, a chart where needed, and suggested follow-up questions. The sentence worth framing: the number comes from the system, not from the language model’s “memories”. The LLM here is not a source of knowledge but a translator and a writer — it translates your question into a query, and the query’s result into sentences. It is the same setup we saw with the AI Report Narrative in lesson 53, with one important difference: there the system decided what to talk about; here you do.

From this setup follows the trust model — when you can rely on an answer, and when to verify:

• The number layer is as reliable as the data layer. If the uploaded data is fresh and accurate, so is the returned number. If a data refresh was missed or the segment coding is wrong, the chat states a stale or distorted number in a confident voice — the GIGO principle (garbage in, garbage out) applies with full force on a conversational interface, and is in fact more dangerous there, because a fluent sentence hides a bad input better than a raw table does (more on this in lesson 57). A useful defence line is that a conversation is bound to a specific data state: when a new data upload arrives, the running conversation closes, and the continuation starts on a fresh thread, on the fresh data — so two data eras never mix inside a single conversation.
• The interpretation layer asks to be checked. The same look-behind-the-number discipline applies as with the narrative in lesson 53: the factual number and the qualifier attached to it (“weak”, “strong”, “worrying”) are two separate qualities. The report link next to the answer exists precisely for this — one click and you are in the underlying report, where the number can be checked in its full context. The first reflex at a surprising answer should not be forwarding it, but jumping in.
• The context layer is configurable — and needs maintaining. In its answers the system takes into account the hotel’s recorded context (sales strategy, market environment, special circumstances) and the editable memories accumulated from conversations — recurring facts about the hotel that you should not have to restate in every conversation. It also measures what counts as “high” or “low” for you against reference bases computed from your own hotel’s data — an 80-room city property’s “good pickup” is not the same as a 300-room resort’s. This layer is only as good as its upkeep: one stale memory (“the hotel’s main market is German leisure” — it has not been for two years) skews the interpretations systematically.

The craft of asking well

And here we reach the core of the lesson. The most common disappointment with conversational tools is not about the technology but about the question: a vague question breeds a vague answer — not because the system is bad, but because to a vague question even the accurate answer can only be a generality. Look at these pairings:

The pattern may look familiar: the structure of a good question is the mirror image of the four elements of a good insight from lesson 52. There we expected the system to put what + where + since when + compared to what into its statement — here you must put the same four elements into the question: a measure (what to measure), a scope (which segment, date range, arrival period), a time window (the state as of when, or how far to look back) and a comparison (last year’s same point? the previous period? the plan?). Whatever is missing of the four, the system either asks back — or, in the worse case, assumes.

One distinction deserves special attention, because it is the most common conceptual trap in RM data: flow versus state. “How many bookings came in for September in the past week?” — that is a pickup question; it measures flow. “Where did the September book stand 30, 20, 10 days ago?” — that is a booking curve question (lesson 37); it asks for a series of snapshots. Blending the two produces meaningless numbers: an old snapshot is not “growth”, it is the position at that time. The good news: if the verb in your question is precise (“how much came in” vs “where did it stand”), the system chooses well. Here the imprecise question does not get an error message but the correct answer to a different question — the most insidious kind of error.

The advanced questioning strategy is iterative narrowing: you do not try to phrase one perfect question; you build a funnel. A broad question (where is the anomaly?) → a striking element in the answer → a narrowing (what is it made of?) → a comparison (what was there last year, before?) → a cause candidate. Every step is cheap, so you can afford to make the first question deliberately wide — in the report world, the same funnel would have been five report setups. Conditional questions belong here too: “is there a day in the next 60 where occupancy falls below 40%?” — and if a question keeps proving important, one click turns it into a scheduled routine (we return to this in a moment).

The worked example — an analysis funnel in the chat

A late-August Thursday; the bank’s answer has gone out, and Daniel continues with his own routine question. Follow the sequence — every step of the funnel method is in it.

Question 1 — broad: “Show me the weakest days in the next 30 days — where is occupancy low and pickup slow?”

The answer adds: the period’s house average is 58% — the three days lag it meaningfully. The Tuesday, by itself, is no surprise; the Sep 25–26 weekend is — at weekends the house is leisure-dominated, and 40% a month before arrival is unusually little.

Question 2 — narrowing: “Why is the Sep 25–26 weekend weak? Break the Saturday down by segment.”

Question 3 — comparison: “What did the comparable Saturday look like at this same point last year, by segment?”

A quick check: 23 + 5 + 4 = 32; 30 + 6 + 6 = 42; the gap column sums to 7 + 1 + 2 = 10 — and 10 rooms in an 80-room house is a 12.5 pp shortfall. At the end of the answer, a note from the hotel memory: late last September an international trade fair ran in the city — this year the calendar shows it moved to early October. Baseline suspicion (lesson 52): last year’s 42 rooms may be an inflated reference point.

Question 4 — check: “How does the average rate of the last 7 days’ new bookings for September arrivals compare with the average rate of the September book?” The answer: the fresh pickup’s average rate is 96 EUR, the existing book’s is 92 EUR — incoming demand is not cheaper than what is already on the books; no price-sensitivity problem is visible.

The synthesis — and this is no longer the chat’s work but Daniel’s. The fair effect last year at this point was roughly 6 rooms (4 leisure + 2 group — the small block tied to the fair). So the realistic base is not 42 but ~36 rooms — and the corrected gap is not 10 but ~4 rooms (5 pp): real, but moderate. The decision follows lesson 50’s logic: no pricing move — the date goes on the watchlist with a trigger point at T-21: if the corrected gap grows past 6 rooms, the closed-group, rate-image-protecting promo package launches; until then, a compset check (lesson 44) on whether the market shows the same moderate slowdown. Four questions, six minutes — and what used to be half a morning of report hunting now ends exactly where the RM’s real work begins: at the diagnosis and the decision.

Limits and traps — when chat, when report

The chat is not a decision-maker. At the end of the sequence above, the system did not tell Daniel what to do — and that is as it should be. Lesson 51’s division of labour holds on the conversational interface too: the machine delivers the what happened faster than ever; the why and the what do we do remain the business of the diagnosis tree and the scenario table. The temptation is stronger here than with a report — from a fluently writing system, it is a natural reflex to ask for advice too. You may ask; but treat its answer as an input, not as a decision.

A conversation is not an auditable report. The ad-hoc question chain is excellent for discovery, but it does not belong under a documented decision: a chat answer was born on the data state of one moment, with one particular phrasing of the question — hard to retrieve, reproduce or hand to a third party. Even towards the bank, Daniel does not send the chat screenshot but an export prepared from the linked report. The rule is simple: chat for discovery, reports for evidence. Likewise, the weekly meeting (lesson 47) and every recurring, comparable, shared view is the territory of the structured report — a recurring question’s whole value is that it is asked the same way every week.

The bridge between the two extremes is the routine. If you have a proven question you keep asking — say, the Monday-morning weak-days list —, Pulse Routines turns it into a scheduled routine: any chat answer becomes a routine with one click, the system runs the question by itself on the cycle you set (daily, weekly or monthly), and the result arrives as a notification and by email — the answer with its table, the full view one click away. And by default it only runs when new data has actually arrived — a quiet weekend does not fill your inbox with yesterday’s numbers. The ad-hoc question thus becomes a repeatable signal that needs no asking — one step closer to the system-supported operation the expert level is heading towards (and whose endpoint, agent-like AI, is the subject of lesson 66).

And the closing trap: fluency is not accuracy. The chat’s greatest strength — that every answer is well written — is also its greatest risk: the answer to a bad question sounds convincing too. The defence is not distrust but discipline: a precise question (four elements), a report check at any surprising answer, and data-quality upkeep in the background (lesson 57).

The next morning over coffee, Adam says just this: “The bank got it. And last night I tried that chat — I asked how we stand for October.” Daniel nods, and feels no threat: for the first time, his GM looked at data on his own instead of worrying into the evening. From now on, two people ask the questions — the decisions are still made by the method.

Key takeaways

• The conversational interface changes three things: it removes the query’s translation step (you ask; you do not hunt for a report), it allows context-holding question chains (“and the same for last year?”), and it puts data access in the GM’s hands too — the debate shifts from facts to interpretation, where the RM’s method is the added value.
• The number comes from the system, not from the LLM’s memories: your question runs as a real query on the hotel’s freshest data; the language model translates and writes. Trust is therefore layered: the number depends on data quality (GIGO), the interpretation asks to be checked (report link), and the context layer (memories, hotel settings) needs maintenance.
• The four elements of a good question: measure + scope + time window + comparison — the mirror image of lesson 52’s insight test, from the asker’s side. Watch the flow/state distinction: “how much came in” (pickup) and “where did it stand” (curve) are two different questions — the imprecise phrasing gets not an error but the correct answer to a different question.
• Iterative narrowing is the analysis strategy: broad question → anomaly → narrowing → comparison → cause candidate. In the example, four questions split the 10-room weekend gap into ~6 rooms of base distortion and ~4 rooms of genuine, watchlist-sized weakness — with no pricing move.
• Chat for discovery, reports for evidence: the ad-hoc question chain is neither auditable nor repeatable — a documented decision or a shared view needs a structured report; and a proven recurring question can become a scheduled routine (Pulse Routines).