Haladó

Unconstrained vs. constrained demand

15 perc

Július 22., szombat este, Hotel Peaqplus City. A hotel telt házzal zár: 80 szoba, 80 kiadott, a rendszer 100% foglaltságot, 112 EUR ADR-t és 112 EUR RevPAR-t regisztrál — 8 960 EUR szoba-bevétel. Az RM-riportban ez egy tökéletes nap.

De van egy kérdés, amit a klasszikus riport soha nem tesz fel: hányan akartak még foglalni erre a napra — és nem tudtak?

Ha 3 vendég nézett szobát a Booking.com-on és üres kézzel lépett ki, mert a hotel tele volt, a valódi kereslet nem 80 volt, hanem 83. Ha 12, akkor 92. És ha az RM ezt tudná, másképp árazná a következő hasonló szombatokat — mert 92 szobányi kereslet 80 szobára azt jelenti: a 112 EUR-os ár alacsony volt.

Ez a különbség a constrained demand (a kiszolgált kereslet) és az unconstrained demand (a valódi piaci kereslet) között — az érett RM egyik legmélyebb alapfogalma. Ebben a leckében megtanuljuk: mi a különbség, hogyan mérjük a ki nem szolgált keresletet, és miért kritikus ez a forecast- és árazási döntésekhez.

A constrained demand — amit kiszolgálunk

A constrained demand a hotel által ténylegesen kiszolgált kereslet — az, amit a rendszereink regisztrálnak: kiadott szobák, realizált ADR, tényleges bevétel.

A 12. leckében felfedezett Coldplay-koncert szombatján (november 18.) Hotel Peaqplus City telt házzal zárt: 80 szoba, 145 EUR realizált ADR (a BAR 148 EUR-on állt), 11 600 EUR szoba-bevétel. Ez a constrained demand.

A hagyományos RM-eszköztár — a pace-elemzés, a forecast, a day-class alapú és a dinamikus árazás — mind erre az adatra épül. Ami érthető: ez az, ami a PMS-ben van.

Az unconstrained demand — amit a piac kért volna

Az unconstrained demand a valódi piaci kereslet: hány szobát kértek volna az adott áron, ha a kapacitás és a restrikciók nem korlátoznának.

A Coldplay-szombaton ez lehetett mondjuk 80 kiadott szoba + 15 vendég, aki szerette volna, de már nem fért be: unconstrained demand = 95.

A kettő különbsége a ki nem szolgált kereslet — vendégek, akik a hotelt választották volna, de nemet kaptak, vagy maguk léptek tovább. Definíció szerint az unconstrained demand soha nem kisebb a constrained-nél.

Egy fontos pontosítás, mielőtt továbbmegyünk: az unconstrained demand ár-függő. Mindig egy adott ár melletti keresletről beszélünk — a 36. lecke árrugalmasság-logikája mögötti kereslet-görbe egy pontjáról. 145 EUR-on 95 szobányi kereslet volt; 90 EUR-on nyilván több lett volna. Erre a paradoxon-szekcióban visszatérünk.

Miért számít?

A naiv modell úgy dolgozik: amit eladtunk = a kereslet. Telt háznál ez nyilvánvalóan alulmér — de alacsony foglaltságnál is félrevezethet.

Képzelj el egy hotelt, ami tartósan 60%-on áll. A constrained adatból a következtetés: „a piac ennyit ad, ez a realitás.” De ha a valódi kereslet egy alacsonyabb árponton 80% körül lenne — vagyis a hotel ár-pozíciója szisztematikusan a piac fölött van, és a vendégek már a keresés fázisában elpattannak —, akkor a 60% nem piaci plafon, hanem árazási döntés következménye. A helyes akció ilyenkor nem a „több marketing”, hanem az ár-pozíció újragondolása.

És fordítva: aki rendszeresen telt házzal és magas ki nem szolgált kereslettel zár, az alulárazza magát.

Az árazási döntéseknek, a forecast-építésnek és a csoport-elfogadásnak (40. lecke) az unconstrained keresletre kell épülnie — a constrained csak azt mondja meg, mennyi fért át a szűk keresztmetszeten.

A négy veszteség-komponens

Az unconstrained demand = constrained + a ki nem szolgált kereslet. Utóbbi négy, jól elkülöníthető komponensből áll:

1. Denial — a hotel mond nemet

Denial minden olyan foglalási kísérlet, amit a hotel oldala utasít el: nincs elérhető szoba, vagy egy aktív restrikció (MLOS, CTA — 24. lecke) blokkolja a kért tartózkodást. Fontos: a restrikció miatti denial akkor is denial, ha fizikailag lenne üres szoba.

A Coldplay-szombatra a Booking.com-on a nap folyamán mondjuk 20 foglalási kísérlet fut be: az első 12 még kap szobát, az utolsó 8 már üres kézzel távozik — 8 denial.

2. Turn-away — a pult előtt

A turn-away a denial offline változata: a walk-in vagy telefonáló vendég, akinek a recepció mond nemet, mert nincs szoba. Ez sehol nem keletkezik automatikusan — kézzel kell logolni. Egy belvárosi hotel egy telt estén jellemzően 2-4 turn-away-t generál.

3. Regret és a recapture-loss — az ár miatt elpattanó vendég

A regret a denial tükörképe: a hotel tudott volna szobát adni, de a vendég mond nemet — jellemzően az ár miatt. Megnézte, drágállta, továbblépett.

A regret-vendégek egy része később mégis nálunk köt ki — másik dátumra, másik szobatípusra vagy akciós rate-en foglal. Ez a recapture. Ami ezután is elvész, az a recapture-loss — a valódi, ár-vezérelt veszteség. Ez a legnehezebben mérhető komponens: a vendég soha nem jelenik meg a hotel rendszereiben. Iparági tapasztalat szerint event-csúcs napokon ez a veszteség tipikusan a constrained kereslet 15-25%-a — a magas ár sok vendéget pattint el.

4. Search-loss — a keresési tölcsér vesztesége

A search-loss a leglazább jel: a vendég a metasearch-en vagy az OTA-listában megnézi a hotelt az adott dátumra, majd kilép — se nálunk, se máshol nem foglal, vagy elhalasztja az utat. A metasearch- és OTA-analitika (megtekintés vs. konverzió) jelzi.

Vigyázat: a search-loss átfed az előző komponensekkel (a regret-vendég is „megnézte és kilépett”), és tele van nézelődővel. Kereszt-ellenőrző jel, nem összeadandó tétel.

Hogyan becsüljük? — négy módszer, egymásra építve

Nézzük a Coldplay-szombatot végig, ahogy a becslés rétegről rétegre épül:

1. módszer — OTA denial-analitika. A Booking.com extranet-analitikája megmutatja, hány keresés futott olyan napra, amelyre nem volt elérhető szobád; az Expedia hasonló adatot ad. A Coldplay-szombatra: Booking.com 8, Expedia 3 — együtt 11 mért denial.

Becslés: 80 + 11 = 91.

2. módszer — turn-away log. A recepció aznap este 4 walk-in vendéget küldött el — kézzel vezetett lista.

Becslés: 91 + 4 = 95.

3. módszer — regret-becslés (statisztikai). A recapture-loss közvetlenül nem mérhető — modellezni kell, a pace-pálya, az ár-pozíció és a compset-mozgás alapján. Event-csúcsra a hüvelykujj-szabály ~15%: 0,15 × 80 = 12 vendég.

Becslés: 95 + 12 = 107.

A hotel 80 szobája tehát 80 vendéget szolgált ki — de a valódi kereslet a becslés szerint ~107 szobányi volt. 27 szobányi kereslet maradt kiszolgálatlanul.

4. módszer — search-loss jel (kereszt-ellenőrzés). A metasearch- és OTA-analitika szerint a dátumra 850 oldalmegtekintés futott, és 82 foglalás született (ebből 2 később lemondva — 80 realizált). Konverzió: 82 / 850 = 9,6%, miközben a hotel szokásos szombati baseline-ja 15% körüli. A −5,4 pp esés nagyságrendileg 850 × 0,054 ≈ 46 „elveszett foglalásnyi” jelet ad.

Ez a 46 nem adódik hozzá a 107-hez: átfed a denial- és regret-számokkal, és nézelődőket is tartalmaz. (A konkrét konverzió-szint hotelenként nagyon eltér — a jel a saját baseline-hoz mért esés.) Arra jó, hogy megerősítse: a veszteség valós és nagy.

A Peaqplus Smart Forecast ezekből a jelekből súlyozott becslést épít — a mért komponensek (denial, turn-away) keményebb, a modellezett és tölcsér-jelek puhább súllyal.

A pontossági paradoxon — a kereslet drágán mérve láthatatlan

A denial-alapú mérésnek van egy csapdája: denial csak akkor keletkezik, ha a korlát ténylegesen megköt.

Tegyük fel, hogy a hotel a Coldplay-szombatra 165 EUR-t kér, és 60%-on zár (48 szoba). A denialok száma ~0 — hiszen végig volt szabad szoba. A riport azt sugallja: „nincs ki nem szolgált kereslet.” Közben a vendégek sora nézte meg az árat és lépett tovább — csupa regret, ami láthatatlan.

Fordítva: ha ugyanarra a szombatra 90 EUR-t kérne, 100%-ra töltene, és mondjuk 30 denial futna be. Most hirtelen „látszik” a magas kereslet — 110 szobányi, 90 EUR-on.

Ez a pontossági paradoxon: az unconstrained demand alacsony áron jól mérhető (a kapacitás-korlát megköt, és a kereslet-görbe nagyobb részét látod), magas áron láthatatlan (a korlát nem köt meg, a denial nulla — de ettől a kereslet még nem ismert). És mivel a kereslet ár-függő, a két mérés a görbe két különböző pontját mutatja — nem ugyanazt a számot.

Az érett RM ezt tudatos teszteléssel kezeli: összehasonlítható napokon eltérő ár-pozíciókat futtat, és a pace-, denial- és konverzió-jelekből rajzolja fel a saját kereslet-görbéjét — a 36. lecke elastic demand modelljének gyakorlati megfelelője.

Az unconstrained demand a forecastban

A 38. leckében láttuk: a klasszikus forecast constrained adatokból tanul. Telt házas napoknál ez szisztematikus alulbecslést épít a modellbe — a 100%-nál levágott adat (a statisztikában: cenzorált adat) eltünteti a kereslet tetejét. Emlékszel: a 38. lecke event-szombatján a plafon nélküli, elméleti szám közel 110%-ra futott — az pontosan ez az unconstrained-jelzés volt.

Egy érett Smart Forecast ezért a denial-jeleket is beépíti:

  • Ha a hotel 3 egymás utáni szombaton telt házzal zár, és a napi denial-szám 10 felett jár, a modell jelez: az unconstrained kereslet ezekre a napokra becslés szerint 10-15%-kal magasabb, mint amit kiszolgálunk.
  • A stratégiai következtetés: emelni az árat ezekre a mintázat-napokra — vagy hosszú távon feltenni a kapacitás-kérdést.

A Coldplay-típusú event-szombatra lefordítva: constrained forecast 80 szoba (100%), unconstrained becslés 95-107. A következő hasonló event-szombatra a javaslat: BAR 148 helyett 175 EUR — a becsült kereslet-többlet mellett a ház valószínűleg így is telt ház közelében zár, érdemben magasabb ADR-en. Ez az unconstrained-alapú árazás: nem azt kérdezed, „betelik-e a nap”, hanem azt, „mennyi kereslet szorulna ki még így is”.

Unconstrained demand és a kapacitás-kérdés

Van ennek egy hosszabb távú olvasata is. Ha az unconstrained becslés strukturálisan, ismétlődően a kapacitás felett jár — Hotel Peaqplus City-nél az event-csúcs napokon rendre 20-30 szobával —, az már nem árazási, hanem kapacitás-kérdés.

Egy durva, nagyságrendi számítás: egy 10 szobás bővítés (80 → 90) az évi ~50 telt éjszakán, ~170 EUR-os csúcs-ADR-rel 10 × 50 × 170 ≈ 85 ezer EUR extra éves szoba-bevételt hozna pusztán a ma elutasított csúcs-keresletből — a váll-napok részleges töltésével együtt nagyságrendileg 85-120 ezer EUR. (Ez a bevétel-oldal; beruházási és üzemeltetési költségek nélkül még nem business case.)

A döntés a tulajdonosé — de az adat az RM-től jön. Az unconstrained-becslés a hosszú távú stratégiai tervezés egyik bemenete.

A Peaqplus Smart Forecast és az unconstrained demand

A Smart Forecast modul három ponton dolgozik a ki nem szolgált kereslettel:

  1. Denial-tracking. Napi szinten követi az OTA-analitikából érkező denial-jeleket; ha egy nap száma kiugró, anomáliaként jelzi.
  2. Regret-/recapture-becslés. A közvetlenül nem mérhető, ár-vezérelt veszteséget statisztikai modellel becsli — a pace-pálya, az ár-pozíció és a compset-mozgás alapján, naponta kalibrálva.
  3. Kettős forecast. Minden napra két szám: a constrained forecast (várt kiszolgált foglaltság — a klasszikus) és az unconstrained becslés (várt valódi kereslet). A kettő különbsége a kiszoruló potenciál.

Egy reggeli szituáció: Dániel megnyitja az anomália-listát, és az élén ez áll: „December 31., szilveszter. Constrained forecast: 100%. Unconstrained becslés: ~125% — kb. 20 szobányi kereslet szorulna ki. Javaslat: BAR +30 EUR (280 → 310). Várt hatás: a telt ház marad, az ADR és a RevPAR ~+10,7%.”

Az expert szinten (55. lecke: Smart Forecast Enhanced) látjuk majd, hogyan lesz ez a becslés hosszabb távon és AI-komponensekkel még pontosabb.

Kulcsüzenetek

  • Constrained demand = amit ténylegesen kiszolgálsz; unconstrained demand = amit a piac az adott áron kért volna, kapacitás- és restrikció-korlát nélkül. Az unconstrained definíció szerint soha nem kisebb a constrained-nél.
  • A ki nem szolgált kereslet négy komponense: denial (a hotel mond nemet), turn-away (a pult előtt), regret/recapture-loss (a vendég mond nemet — jellemzően az ár miatt), search-loss (a tölcsérből kilépők — átfedő kereszt-jel, nem összeadandó).
  • A pontossági paradoxon: alacsony áron a kereslet mérhető (a korlát megköt), magas áron láthatatlan — a 0 denial nem jelenti azt, hogy nincs elveszett kereslet.
  • A telt házas napok cenzorált adatot hagynak a forecastban — az érett modell denial-jelekkel korrigál, és kettős forecastot ad: constrained + unconstrained.
  • Az unconstrained-alapú árazás: rendszeres telt ház + magas denial-szám = alulárazás. A jó kérdés nem az, hogy „betelik-e”, hanem az, hogy „mennyi kereslet szorul ki”.
Ellenőrző kérdés

Kattints a válaszra — azonnal látod, helyes-e.

Ha mindegyikre válaszolsz, a lecke teljesítettnek számít — és beszámít a haladásodba.

Egy telt szombaton: 80 kiadott szoba, az OTA-analitika 9 denial-t jelez, a recepció 3 turn-away-t logolt, a regret-veszteséget a modell a constrained kereslet 10%-ára becsüli. Mennyi az unconstrained demand becslése?
Mi a különbség a denial és a regret között?
Egy hotel átlagosan 65%-on áll, a denialok száma 0-2/nap. Az RM következtetése: „nincs elveszett kereslet." Miért elhamarkodott ez?
Menj mélyebbre
Kapcsolódó fogalmak

Nézd meg a részletes definíciókat a szótárban.

Alkalmazd a saját szállodádra

Egy hotel az utolsó 5 szombaton 100%-on zárt, a Booking.com-analitika átlag 12 denial-t mutat szombatonként, a BAR 135 EUR. Milyen ár-stratégiát javasolnál a következő 5 szombatra? Vezesd végig az elastic demand logikával (36. lecke): mekkora unconstrained keresletet becsülsz, és milyen lépcsőkben emelnél. És: egy másik hotel 30 napos átlaga 65% foglaltság, a denialok száma 0-2/nap, az RM következtetése: „nincs elveszett kereslet." Milyen kérdéseket tennél fel, mielőtt ezt elfogadod — és adj három alternatív magyarázatot, amit a denial-szám nem zár ki.

Hogyan segít ebben a Peaqplus
További olvasás
  • Kalyan T. Talluri és Garrett J. van Ryzin: The Theory and Practice of Revenue Management (2004) — a revenue management elméleti alapkönyve; az unconstraining (a plafonnál levágott, cenzorált kereslet-adat visszabecslése) matematikáját ez tárgyalja a legmélyebben.
  • A nagy szállodaláncok CRS-rendszerei évtizedek óta rögzítenek denial- és regret-statisztikát a foglalási hívásokból — az unconstrained demand mérése ott napi gyakorlat. A modern eszközök ugyanezt az OTA- és metasearch-analitikából rakják össze.
Signal → Decision → Action → Outcome

Lásd a Peaqplus-t a saját adataidon.

A 45–60 perces bemutatón az élő demo környezetünkön futtatjuk a Peaqplus-t — szimulált szállodán, ahol az adatok napról napra változnak.

Nincs setup díj. Nem kell PMS-hozzáférés.