Smart Forecast Enhanced — the longer-horizon hybrid model

September 1, a Tuesday morning, Hotel Peaqplus City. Adam walks into Daniel’s office with a bank email in his hand: the annual review of the hotel’s credit line is coming up, and the bank — in agreement with the owner — is asking for a 90-day revenue outlook for Q4 cash-flow planning. Not a mood report: a number, with reasoning.

Daniel looks at the calendar and knows exactly why the request is uncomfortable. September–November is the house’s conference season — the best, and at the same time the hardest-to-predict, stretch of the year. MICE demand (meetings, incentives, conferences, exhibitions — event-driven business demand) is lumpy: the week of a major event spikes, the weeks between sag. Corporate wobbles: company projects slip, cluster, get rescheduled. And most of the bookings that Q4 will be made of do not exist yet on September 1.

The hybrid forecast built in lesson 38 — comparable-date base, pace extrapolation, event corrections, context-weighted average — works excellently for the next 2-4 weeks. But on the 60-90 day horizon, with few booking signals, a different tool is needed. This lesson is about how Smart Forecast Enhanced — the longer-horizon, AI-strengthened hybrid — is built in three layers, and, at least as importantly, how to consume its output so that a good decision comes out of it.

Why the 60-90 day horizon is different

The strength of lesson 38’s short-horizon model is the pace signal: at T-7 the OTB (on the books — the occupancy already booked) is typically 75-85% of the final result, we are on the steep section of the booking curve (lesson 37), and the pace deviation is a strong predictor. On the 60-90 day horizon, all three conditions drop out at once:

1. There is little OTB signal. At T-60, a city hotel’s OTB is typically 20-35% of the final. The signal the short model lives on barely exists yet — most of the forecast is not a measurement but an estimate of something that has not happened.
2. The early section of the booking curve is noisy. The start of the curve is flat and scattered: between T-60 and T-50, a handful of bookings tips the pace picture back and forth. A good week of +4 rooms on this stretch can be genuine strength — or one family’s accidental timing. Pace extrapolation, a sharp instrument at T-7, is mostly a noise generator at T-60.
3. Events and groups have binary outcomes. A 30-room group either comes or it doesn’t — there is no “comes a little”. A conference is either held again this year or it moves elsewhere. The biggest item in long-horizon forecast error is not the inaccuracy of the transient estimate but the uncertainty of these large, discrete outcomes. In lesson 39’s language: estimating unconstrained demand is hard enough on the long horizon — but most of the variance comes from the binary items.

Add to this the peculiarity of conference season: the historical pattern shifts from year to year. Trade fair dates wander, an event gets longer or shorter, a new one is born, an old one dies. “This time last year” is a less reliable base here than in a stable leisure season — calendar alignment is not a convenience extra but a precondition of accuracy.

The serial hybrid — three layers, built on each other

First, a conceptual bridge to lesson 38. There, the word “layer” meant parallel estimates: three models ran side by side, and the final result was their context-weighted average. In the Enhanced approach the layers build on each other serially: Layer 1 provides a statistical base, Layer 2 corrects that base using context, and Layer 3 — the human — adjusts the corrected number with what only they know. Not averaging but a refinement chain: each layer improves where the previous one is blind.

This is how the division of labour introduced in lesson 51 — the machine is strong in the data, the human in the market — becomes concrete architecture: Layer 1 belongs to historical data, Layer 2 to public context, Layer 3 to private knowledge.

Layer 1 — the statistical base model

The base is the same idea as in lessons 37-38: learn from historical pickup patterns how much booking still tends to arrive for this type of day, this many days before arrival — and add it to the current OTB. The Enhanced base model, however, is finer than the classic in several respects:

• Finer seasonality. The patterns are built at monthly granularity, not quarterly — September and November do not blur into a “Q4 average”, even though their demand profiles differ radically. Day of week remains a separate dimension: an October Wednesday and an October Sunday are two distinct patterns.
• Lead-time bands. The “days before arrival” dimension does not live in day-precise buckets but in bands: narrow near arrival (where the curve is steep), wide further out (where it is flat). That way every pattern gets enough historical observations for the average to be statistically meaningful — with day-precise buckets, most buckets would sit nearly empty, and the “average” would be a single random booking.
• Recency weighting. The last months’ data gets more weight than older data — the hotel’s demand profile lives and changes, and the model should estimate the current house, not the one from two years ago.
• Outlier filtering. The average is computed without the occasional extreme item — say, an exceptionally large, long group booking. Without this, a single anomalous event would distort the “normal” pickup picture for months.
• Year-over-year trend factor. If the house has systematically outperformed the previous 12 months over the last 12, the model builds this in as a cautious multiplier — but only when there is enough comparable history. With too little data, the trend calculation would measure not a trend but a data gap, so the model stays neutral. (This is the practical face of the GIGO principle — garbage in, garbage out; lesson 57 goes deeper.)
• Sanity bounds. The forecast can never fall below the OTB already on the books (what has already happened cannot be “forecast away”), and it can never exceed the house’s capacity.

This layer — like the classic Smart Forecast — recomputes daily for every date, so each morning it starts from the freshest booking state.

What does this layer know? Normality: what an average October Wednesday does when nothing unusual happens. And what does it not know? Exactly what makes conference season hard: it cannot see the calendar. It does not know that this year’s trade fair is longer, that a new event has come to town, that a holiday has slid to another week. In the historical average these effects are smeared out — projecting them onto this year’s specific calendar is not the average’s job.

Layer 2 — LLM-based context correction

This is where the large language model (LLM) comes in. Every morning, Layer 2 walks through the days of the next 60 days, and for each one it receives: the base model’s estimate, the current OTB, last year’s actual, the same-point comparison (lessons 18 and 50), the budget target, the last days’ pickup trend — and, crucially, the event calendar. From this picture it estimates how much this year’s specific context deflects the day from the historical norm.

Why an LLM, of all things? Because the task is not calculation but interpretation. That “the average October Wednesday does 68%” is something statistics knows better. That “this year’s trade fair is two days longer, so Thursday-Friday become fair days too”, or that “the public holiday forms a long weekend this year, which pushes business demand down and leisure up” — coding that into a rule set is hopeless, while a language model has a good chance of reading it out of the calendar signals. It is the same capability you saw with the Insight Engine in lesson 52 and Pulse Chat in lesson 54: the machine helps with pattern interpretation, not arithmetic.

And here comes what is perhaps the system’s most important design principle, one you need to know as a forecast consumer: the correction is bounded. The LLM can move the base model’s number only within a pre-set band, and even the corrected number can never exceed the house’s capacity — the bounds are not kept by the model’s “good will” but enforced by the system. Layer 2 therefore shades, it does not rewrite: even if the context suggested a dramatically different picture, it can only apply a moderate deflection. This is deliberate — a language model is sometimes wrong, and a bounded error is manageable while an unbounded one is not. And every correction comes with a written reason, stored by the system day by day — so the correction is not a black box but a retrievable statement.

What does this layer know? The public context: everything that can be read from the calendar, the data and the comparisons. What does it not know? The private knowledge. It does not know what offer went out to an organiser yesterday, what probability sales puts on a pending group, or that a key account’s company is in the middle of an acquisition. That is Layer 3’s territory.

Layer 3 — the human correction loop

Layer 3 is you — not in the “I’ll glance at it” sense, but as a structured loop. It has two halves: the correction and the measurement.

The correction. In the Forecast module the machine estimate appears as the starting value, and you can override it day by day. This is where what only the RM knows goes in: the 30-room tentative offer that went out yesterday and its estimated chance of materialising, a known cancellation risk (the wash phenomenon from lesson 29 — a group’s contracted room count typically erodes before arrival), a market rumour, a new corporate contract that is not producing bookings yet. The expert-level discipline: your correction should think in expected value (probability × impact), not in binary hope — and always ask yourself whether the machine base does not already partly contain what you are about to add. We return to this in the worked example, because it is the most common mistake.

The measurement. The system stores the forecast’s daily state as a snapshot, and each month it measures the error by horizon: how much the estimate missed 7, 14 and 30 days before arrival — separately for the raw statistical base and for the AI-corrected version, side by side. So the question “how much should I trust the machine?” gets a measured answer, not a gut one: you see the typical error of your house, your season, your horizon. And the same mirror can be held up to your own corrections: if your overrides systematically make the machine number worse, you need to notice — we come back to this.

The worked example — the October conference week, on September 1

Hotel Peaqplus City, 80 rooms. The chosen date: October 7, a Wednesday — the peak day of the city’s autumn economic-conference week. Today is September 1, so we stand at T-36. Follow it layer by layer — every number checks out.

Layer 1. The current OTB: 20 rooms = 25%. From the historical patterns of October Wednesdays (for the matching lead-time band, recency-weighted, outliers filtered), the base model says: for a day like this, this far before arrival, another +43 percentage points (pp) of bookings typically still arrive. The base estimate is therefore 25% + 43 pp = 68%, i.e. 54.4 rooms. This is the picture of the “normal October Wednesday”.

Layer 2. The LLM sees two relevant signals in the calendar: this year’s economic conference is two days longer than last year’s (so the Wednesday is no longer a lead-in but a full conference day), and a new healthcare industry event has been announced for the same week at the neighbouring congress centre. The correction: +6 pp, with a written reason. New estimate: 68% + 6 pp = 74% (59.2 rooms). Note the proportion: the correction is meaningful but not dramatic — the bounded band enforces exactly this behaviour.

Layer 3. Daniel knows something neither machine layer does: last week an offer went out for a 30-room tentative group for precisely this week, and based on his conversation with the organiser he puts the chance of it materialising at 60%. The expected value: 30 × 0.6 = 18 rooms, which is 22.5 pp on 80 rooms.

And here is the step where most manual corrections go wrong: you must not add this one-for-one. Layer 1’s historical average already contains the average group pickup of similar October weeks — groups came in past conference weeks too, and their bookings are in the sample. Daniel checks the historical breakdown: on similar days, about ~10 rooms (12.5 pp) of group pickup still tends to arrive at this lead time — that much the machine base has already “priced in”. So the correction is only the excess: 18 − 10 = 8 rooms = +10 pp.

Final forecast: 74% + 10 pp = 84% (67.2 rooms). The confidence band is wide at this horizon — because of the tentative group’s binary outcome and the noise of the early curve section, Daniel works with ±7 pp: 77–91%.

Two weeks later — the loop at work

September 15, T-22. The group signed — the 60% resolved, and upward: the 30 rooms went into the OTB. Alongside it, transient brought 8 rooms over the two weeks. The new OTB: 20 + 30 + 8 = 58 rooms = 72.5%.

The system does not wait for you: Layer 1 computes from the new OTB the very next morning. For the T-22 lead-time band the base model estimates +13.5 pp of remaining pickup: 72.5% + 13.5 pp = 86%. Layer 2 now puts only +3 pp on the unchanged calendar picture — part of the conference effect has meanwhile become fact, sitting in the OTB as arrived bookings, so it must not be estimated on top again: 89%.

And Layer 3? Daniel zeroes out his group correction. This is the critical moment of loop discipline: the manual correction’s reason has ceased to exist — the group is on the books, Layer 1 sees it. If the correction stayed in, the forecast would count the same group twice. Always keep a manual correction on record together with its reason, and the moment the reason becomes fact or collapses, the correction goes out. He notes one thing in its place: the wash risk (lesson 29) — the 30-room rooming list can still erode by a few rooms before arrival, but that fits inside the band.

The new final forecast: 89% ± 5 pp (84–94%). The band has narrowed — more fact, less estimate. This is what the healthy life of a long-horizon forecast looks like: not a number pronounced once, but an estimate refreshed in a daily rhythm, whose uncertainty melts systematically as arrival approaches. (For thinking through tentative groups’ outcomes methodically — “what would the picture be if this group dropped out?” — lesson 63 gives you a dedicated framework.)

The discipline of consuming a forecast

You understand how the model is built. The second half of the expert level: how to use it so that better decisions come out of it.

A band, not a point

The 84% by itself is a half-truth — the full statement reads: “between 77 and 91, most likely 84.” Plan your decisions on the band, not on the point. For capacity and staffing decisions, the bottom of the band is the safe base; for pricing and displacement decisions (lessons 40-41: is a group worth taking if it may crowd out transient demand?) the top of the band matters too — with a 91% upper edge, the price of the remaining free capacity is entirely different than at 77%. And if a decision would tip in opposite directions at the two edges of the band, that is the signal that the decision must not be made yet — first narrow the uncertainty (wait a few days of pickup, clarify the group status), as lesson 50’s trigger logic taught.

Measuring the error — and why by horizon

The monthly review shows the typical error by horizon — with a MAPE-style measure (mean absolute percentage error: how much we missed on average, in per cent, regardless of sign). A healthy picture, for example: 9% at T-30, 6% at T-14, 4% at T-7. Two things follow. First, trust is horizon-dependent: you can build on the same system’s T-7 number, while its T-60 number you should treat as a scenario. Second, the measurement compares: the raw statistical and the AI-corrected estimates’ errors stand side by side — if the AI-corrected one is more accurate month after month, that is evidence of Layer 2’s value; if not, that is a signal that on your house the context signals are weak and the base deserves the trust. Not a matter of faith: a measured fact.

When to override the machine — and when not to

Layer 3 is the system’s strength and its weakest point at once — which one it becomes is up to you. Two extremes ruin it:

• The “I always override” RM. If you touch every machine number, the forecast is really your gut feeling in machine decoration — and the measurement can no longer show what the model could do left alone. The correction loop loses its meaning, because there is nothing to learn against.
• The “I never override” RM. Then Layer 3 is empty, and exactly the information the machine cannot even in principle see is left out: yesterday’s offer, the private group odds, the partner news. The system’s best property — that private knowledge has a structured place — goes unused.

The healthy rule: correct only when you have concrete information that is demonstrably not in the machine layers’ input — and then always: with expected value, net of the base content, with the reason written down. “My feeling says otherwise” is not a correction reason; “a 30-room offer went out yesterday with a 60% chance” is. And every six months, look in the mirror of the measurement: did your corrections, in aggregate, improve or worsen accuracy? The question is uncomfortable — and that is exactly why it improves the RM who is willing to ask it.

The 90-day outlook in Adam’s hands

On September 15 Daniel sits down with Adam — and the material going to the bank will not be one number but a scenario: the scenario thinking you met in lesson 50, lifted to the long horizon. October looks like this:

And under the table — this is the professionally mature part — the list of assumptions: the band assumes the conference calendar does not change, the signed groups’ wash stays at the usual level, and the corporate reschedulings cancel each other out. So the bank gets no false precision but an honest picture: what we know, how confidently, and what it depends on. The further half of November still falls outside even the AI correction’s 60-day window in mid-September — there, the statistical base and the assumption list carry the picture, and the days slide into the window week by week as arrival approaches. Adam has the outlook refreshed at the weekly revenue meeting (lesson 47) — November’s band is still wide in September, but it narrows week by week as the estimate ripens into fact. The owner’s feedback a month later: for the first time in years, this was an outlook where he also understood why the number was what it was — because next to the number he got the uncertainty and the reasons too.

Key takeaways

• The 60-90 day horizon is a different problem from the short one: there is little OTB signal, the early curve section is noisy, and most of the error comes from binary-outcome events and groups — the short-horizon pace logic (lesson 38) is not enough here on its own.
• Smart Forecast Enhanced is a serial refinement chain, not a parallel average: Layer 1 (statistical base) delivers historical normality, Layer 2 (LLM) corrects it with calendar context — inside a bounded band, with a written reason, daily for 60 days ahead — and Layer 3 (the RM) adds private knowledge. Each layer improves where the previous one is blind.
• Manual correction discipline is three rules: compute expected value (probability × impact), subtract what the machine base already contains (double counting is the most common error), and keep the correction on record with its reason — the moment the reason becomes fact, the correction goes out.
• A forecast is a band, not a point — plan decisions on the band, and calibrate your trust per horizon from the measured error (MAPE), not from intuition.
• Both override extremes are mistakes: with the always-overrider, the model never gets to learn and prove itself; with the never-overrider, the system’s most valuable layer stays empty. Correct only on concrete information invisible to the machine — and measure your own hit rate back too.