Dinamikus árazás — szabály-alapú megközelítés

A 33-34. leckében felépítettük a DCAL-rácsot — az ár-mátrixot, amely az érkezési nap (és annak day-class-e), a szobakategória és a tartózkodási hossz (LOS) szerint áraz; a Peaqplusban ezt a réteget a Pricing Map modul kezeli. Csakhogy a rács értékei nem maradhatnak mozdulatlanok: a pace, a pickup-trend és a compset minden nap mozog — és az ár-celláknak ezekkel együtt kell mozogniuk.

A 35-36. leckében a dinamikus árazás két megközelítését vesszük át:

• 35. (ez a lecke): szabály-alapú megközelítés — IF-THEN logika; ember-érthető, könnyen bevezethető.
• 36. (a következő): elastic demand modell — közgazdasági alapú, ár-rugalmasság-számítással.

A kettő különböző érettségi szintet képvisel. Egy hotel jellemzően a szabály-alapúval kezd, és az érettséggel lép tovább a modell-alapú árazás felé — az ML-alapú árajánlást az expert szint 56. leckéjében (Pricing Engine — ML-alapú árajánlás) vesszük majd át.

Mit jelent a szabály-alapú dinamikus árazás

A szabály-alapú árazás egyszerű IF-THEN feltételek halmaza, amelyek napi szinten módosítják a BAR-t és a hozzá kötött ár-cellákat. Egy klasszikus szabály:

IF a foglaltság egy 14 napon belüli dátumra > 70%, THEN BAR +8%.

Egyetlen logikai feltétel — mögötte egy közgazdasági alapérzés: ha a pace gyors, emelj; ha lassú, csökkents.

Ez gyökeresen más, mint a statikus, kézzel karbantartott ár (a „single rate” világ): ott az ár csak akkor változik, amikor az RM hozzányúl. A szabály-alapú rendszerben az ár magától mozog, amint a feltételek teljesülnek. Ez az átmenet a kézi árazás és a modell-alapú árazás között.

Egy klasszikus szabálykészlet

Hotel Peaqplus City reális, 10 szabályos készlete:

Tíz szabály. Egyenként mind egyszerű — együtt egy teljes árazási stratégiát adnak ki: pace-triggerek (#1-4), event-kezelés (#5), compset-követés (#6-7), strukturális day-of-week logika (#8), szezon-csúcs (#9) és védőkorlát (#10).

Két működési részlet:

• A szabályok között hierarchia van. Az 5. szabály (event) felülbírálja a 8.-at (vasárnap-gyengeség): ha vasárnapra esik egy koncert, az event-szabály fut, nem a discount. A #10 (floor/ceiling) pedig mindent felülbírál.
• A százalékok nem adódnak össze. A #1 és a #2 közül mindig a szigorúbb küszöbű érvényesül: 87%-os foglaltságnál +15% fut, nem +23%.

A szabály-alapú megközelítés előnyei

1. Átláthatóság

Az ember érti, miért változott az ár. Ha Ádám megkérdezi: „Miért ugrott a jövő pénteki BAR 132-ről 152-re?”, Dániel egy sorban válaszol: „Az #1 szabály aktiválódott — a péntek 14 napon belül van, és 85% felett áll.” (132 × 1,15 ≈ 152.)

2. Kontroll

Egy szabály be- és kikapcsolható. Ha a hotel nem akar last-minute-promót futtatni gyenge pace-nél — mert félti tőle az ár-pozícióját —, egyszerűen lekapcsolja a #4 szabályt.

3. Pedagógiai érték

A szabály-építés megtanítja a csapatot a saját hotel kereslet-viselkedésére. Minden szabály megfogalmazása és megindoklása egy-egy üzleti döntés: hol vannak a küszöbeink, mennyit ér egy event, mit kezdünk a vasárnappal.

4. Olcsó belépő

A szabály-alapú megközelítés akár kézzel is implementálható (Excel + napi PMS-export). Nem kell hozzá ML-modell — kell viszont fegyelmezett napi rutin.

A szabály-alapú megközelítés veszélyei

Veszély 1: túl sok szabály

Egy 30-50 szabályos rendszer átláthatatlan. Az RM már nem találja meg egy ár-mozgás okát, mert több szabály konfliktál — és a hierarchia karbantarthatatlanná válik.

Veszély 2: a kemény küszöbök

A „foglaltság > 70%” feltétel bináris. 69%-nál semmi nem történik; 71%-nál jön a teljes +8% BAR-emelés. Egy 2 pp-s foglaltság-mozgás drasztikus ár-ugrást okoz — a kereslet viszont nem lépcsőben mozog, hanem folyamatosan. Az ML-alapú árazás (expert szint, 56. lecke) ezt simítja ki: folyamatos, nem lépcsős ár-pályát ad.

Veszély 3: adat-elavulás

A szabályok az adott piaci helyzetre épülnek. Ha az RM két éve nem nyúlt hozzájuk, a piac közben elmozdult — és a rendszer csendben gyártja a rossz döntéseket, anélkül, hogy bárki észrevenné. Ezért kötelező elem a rendszeres felülvizsgálat (lásd lentebb).

Veszély 4: szegmens-vakság

A szabálykészlet a teljes foglaltságra dolgozik, nem szegmens-szinten. Ha a corporate-szegmens lassul, de a leisure pickup épp kompenzálja, a teljes foglaltság normálisan épül — mintha minden rendben lenne —, és egyetlen szabály sem reagál. A corporate-lassulást csak szegmens-szintű szabály vagy elemzés fogná meg. Az ML-modell (expert szint, 56. lecke) szegmens-szinten dolgozik — ez az egyik fő különbség.

A szabály-építés alapelvei

Egy érett szabály-alapú rendszer öt alapelven áll:

1. Egyszerűség

Maximum 10-15 szabály. Ha ennél több kell, az már jelzés: vagy a hierarchiát kell újragondolni, vagy tovább kell lépni modell-alapú árazásra.

2. Hierarchia

Minden szabálynak prioritása van. Az event-szabály a sztenderd pace-szabályok felett áll; a floor/ceiling mindenek felett.

3. Tesztelés

Egy új szabály hatása mérhető: futtasd pár hétig, és vesd össze a pickup-eredményt a várttal (forecast vs. actual — 26. lecke).

4. Felülvizsgálat

Negyedévente átnézendő a teljes készlet: mi aktiválódott, milyen eredménnyel — és mi nem aktiválódott soha? Egy szabály nem örök.

5. Floor és ceiling

Mindig legyen alsó és felső határ. Hotel Peaqplus City-nél: BAR-floor 85 EUR (brand-védelem — ez alatt az ár már a pozicionálást rontja), BAR-ceiling 350 EUR (e felett a vendég-bizalom és az ár-elfogadás sérül).

A szabály-alapú megközelítés egy napban

Hogyan dolgozik ez a rendszer nap mint nap Hotel Peaqplus City-ben?

Éjszaka — automatikus szabály-futtatás

A Peaqplus Pricing Engine modulja éjszaka újrafuttatja a 10 szabályt a következő 90 napra. Minden dátumra: (1) megnézi a 14 és 30 napos foglaltság- és pace-szintet, (2) ellenőrzi az event-naptárt, (3) összeveti a compset-átlag mozgását, (4) alkalmazza a day-of-week és szezon-szabályokat. Az eredmény: 90 napra egy-egy javasolt BAR-állapot.

Reggel 8:30 — Dániel átnézi a javaslatokat

A reggeli rutin részeként Dániel 5-10 percet szán az ár-revíziókra:

• A napok ~80%-a változatlan — a szabályok szerint nincs teendő.
• 5-10 napra emelés javasolt.
• 3-5 napra csökkentés javasolt.

Ha egyetért, egy kattintással elfogad. Ha nem, kontextusban dönt. Például: november 18-ra (a Coldplay-szombat, amit a 12. leckében compset-jelből fedeztünk fel) a #5 szabály a 125 EUR-os day-class alapról +25%-ot, azaz 156 EUR-t javasol, MLOS 2-vel. Dániel viszont emlékszik a korábbi aréna-koncertek pickup-jára: +25% körül a pickup megtorpant, +18% környékén viszont betelt a ház. 148 EUR-ra állítja az árat — az MLOS 2 marad, mert a koncert-vendégek zöme péntek-szombatot foglal. És lát valamit, amit a szabály nem: a koncert előtti naphoz, november 17-hez a szabály hozzá sem nyúlt — ő kézzel emeli 125-ről 138-ra.

A szabály javaslat, nem döntés. Az RM Dániel, nem a rendszer.

8:50 — küldés a channel managerre

A jóváhagyott árak a channel manageren (D-Edge — 15. lecke) keresztül 15 percen belül minden csatornán élesednek.

A teljes napi folyamat: kb. 20 perc. Kézzel — Excelben, csatornánként átárazva — ugyanez a 90 napos átnézés jellemzően 2-3 órás napi munka lenne.

A Peaqplus Pricing Engine — szabály-alapú modul

A Peaqplus Pricing Engine a szabály-alapú megközelítést teljes körűen támogatja:

• Vizuális szabály-szerkesztő — az IF-THEN szabályok grafikus felületen épülnek, nem kód-szinten.
• Hierarchia-kezelés — prioritás-szintek és konfliktus-figyelés: ha két szabály ugyanarra a napra ütközik, látod, melyik nyert és miért.
• Mérhető bevezetés — egy új szabály először kijelölt dátum-tartományon futtatható, és a hatása (pickup, ADR) összevethető a szabály nélküli várakozással.
• Tanulási réteg — a szabály-aktivációk és az utánuk mért pace-eredmények rögzülnek, és a rendszer idővel finomítási javaslatokat ad (pl. „a 70%-os küszöb ennél a hotelnél 75%-on működne jobban”).
• Floor/ceiling védelem — ha bármelyik szabály a kijelölt határokon kívülre vinné az árat, automatikus felülbírálás lép be.

A szabály-alapú árazás a Pricing Engine első szintje. A 36. leckében jön a következő réteg — az elastic demand modell —, az expert szint 56. leckéjében pedig az ML-alapú árajánlás.

Mikor érdemes továbblépni?

Egy jól vezetett szabály-alapú rendszer évekig működhet. De vannak jelek, amikor érdemes tovább lépni:

• Túl sok szabály: 15+ szabálynál a konfliktus-kezelés idő-intenzívvé válik — a modell egyetlen logikába csomagolja, amit a szabályok darabokban írnak le.
• Szegmens-szintű igény: ha a foglaltság átlag-szinten stabil, de szegmens-szinten drámaian mozog, a szabály-alapú rendszer vak marad.
• Event-kalibrálás: az #5 szabály egységes +25%-a durva közelítés — egy igazi event-csúcs dátum-specifikus, dinamikus ár-pályát érdemel.
• Compset-komplexitás: a #6-7 szabály lineáris követése egyszerű, de a valós compset-dinamika nem lineáris.

A továbblépés első lépése nem technológia, hanem közgazdaságtan: érteni kell, hogyan reagál a kereslet az árra. Pontosan ez a 36. lecke témája.

Kulcsüzenetek

• A szabály-alapú dinamikus árazás IF-THEN logikával, napi szinten mozgatja a BAR-t — egyszerű, átlátható, kontrollálható.
• Egy érett szabálykészlet 10-15 szabály, hierarchikus prioritással és floor/ceiling védelemmel (Hotel Peaqplus City: 85 / 350 EUR).
• A négy fő veszély: túl sok szabály, kemény küszöbök, adat-elavulás, szegmens-vakság — az utolsó kettő csendben rontja az eredményt.
• A napi rutin ~20 perc: éjszakai automatikus futtatás + reggeli RM-felülvizsgálat + küldés a channel managerre. A szabály javaslat, nem döntés — a kontextus-ismeret az RM-é.
• A Peaqplus Pricing Engine vizuális szabály-szerkesztőt, hierarchia-kezelést, mérhető bevezetést és tanulási réteget ad a szabály-alapú árazáshoz.