Mi az a szállodai BI? Gyakorlati útmutató

Egy szállodában általában bőven van adat, csak szét van szórva a különböző rendszerekben. Ugyanarra a jövő szombatra mást mutat a PMS-riport, mást a channel manager exportja, és megint mást az az Excel-tábla, amelyet valaki hétfőn frissített. A heti megbeszélés így azzal megy el, hogy a csapat azon vitatkozik, melyik szám a helyes, a döntés pedig a következő hétre marad.

A szállodai BI ezt a problémát oldja meg: a rendszerek adatait egy helyre gyűjti, és minden mutatót mindenki ugyanúgy számol. Így a megbeszélésen rögtön arról lehet beszélni, mi változott, és mit kell tenni. Ebben az útmutatóban megmutatjuk, hogyan jut el az adat a PMS-ből a vezetői kimutatásig, és miben más a BI, mint a PMS-riport vagy egy revenue management rendszer. Végül azt is, hogyan kezdheted el kicsiben, egy felelőssel és néhány kérdéssel.

Mi az a szállodai BI?

A BI a business intelligence rövidítése, magyarul üzleti intelligenciát jelent. A szállodai BI összegyűjti a szálloda rendszereiben lévő adatokat, egységes szabályok szerint rendezi őket, és olyan kimutatásokban mutatja meg, amelyek alapján a vezetők összevethetik a számokat, és dönthetnek. Ilyen lehet például egy napi teljesítményösszesítő, vagy egy kimutatás szegmens, csatorna, szobatípus vagy tartózkodási nap szerinti bontásban. Egy másik gyakori kimutatás azt mutatja, mennyivel tér el a havi bevétel attól, amit az év elején a szálloda tervezett, vagyis a budgettől.

Az adat és a használható tudás közti különbséget egy példa mutatja meg a legjobban:

• Adat: a jövő szombatra szóló foglalások listája.
• Információ: egy riport, amely szerint arra az éjszakára 26 szoba kelt el.
• Használható tudás: egy kimutatás, amelyből kiderül, hogy arra a szombatra kevesebb a közvetlen foglalás, mint tavaly ilyenkor, az OTA-kon keresztül viszont több foglalás érkezett. Ebből már konkrét kérdés lesz: miért jött kevesebb közvetlen foglalás, és miért több az OTA-kon?

Adatelemzést Excelben is végezhetsz: kigyűjtöd a számokat, és mintákat keresel bennük. A BI-szoftver abban más, hogy ezt a munkát nem kell minden héten elölről kezdeni. Ugyanazokból a forrásokból, ugyanazokkal a definíciókkal mindig ugyanazok a kimutatások készülnek el, és ezekhez mindenki hozzáfér, akinek szüksége van rájuk.

Az igazi munka a grafikon előtt van: gyűjtés, egységesítés, ellenőrzés

A legfontosabb adatforrás általában a PMS, vagyis a szállodairányítási rendszer. Ebben vannak a foglalások, a szobakészlet, a tartózkodási napok, az árak, valamint a vendég- és cégprofilok. A kérdéstől függően szükség lehet a foglalómotor, a channel manager, a kasszarendszer vagy a könyvelés adataira, és a budgetre is.

A BI hasznának nagy része az egységesítésből jön: abból, hogy az eltérően kódolt foglalásokat közös kategóriákba sorolod. Ha az egyik foglalás WEB, a másik INTERNET kódot kapott, pedig mindkettő a saját weboldalról jött, a grafikon ugyanazt a csatornát két külön, kisebb szegmensként mutatja. Az ellenőrzés ugyanilyen fontos: ha valaki a tegnapi adatlekérés után rögzít egy lemondást, megváltozhat egy szám, amelyet a csapat már megbeszélt.

Mindig látni kell azt is, melyik szám mire vonatkozik. Egy havi pénzügyi összesítést és a mai foglalási számot csak akkor lehet összevetni, ha tudod, melyik milyen időszakot fed le. Ezért egy jó BI-kimutatás minden szám mellett feltünteti az időszakot, a foglalások státuszát és azt, hogy az adat mikor frissült utoljára.

A RoomRaiser BI a szálloda saját PMS-adataiból dolgozik, ezeket a SabeeApp-, Mews-, HostWare-, Previo- és D-EDGE-integrációkon keresztül kapja. Szállodánként beállítjuk, mely adatokat vesszük át, így a kódok egységesítését egyszer kell elvégezni, nem minden héten újra egy Excel-táblában.

A PMS-riport, a BI és az RMS más-más kérdésre válaszol

A három rendszer részben átfedi egymást, de mindegyiket más feladatra tervezték.

Rendszer	Mire való?	Tipikus kérdés	Hol a határa?
PMS-riport	A PMS-ben tárolt adatok kimutatása	Ki érkezik ma, és mit terheltek ezekre a foglalásokra?	Általában csak egy forrásból, a PMS saját adatszerkezetéből dolgozik
Szállodai BI	Adatok összekapcsolása, egységesítése és elemzése vezetői döntésekhez	Melyik szegmens miatt jönnek lassabban vagy gyorsabban a foglalások a jövő hónapra?	Megmutatja, hol és mekkora az eltérés; az okot ember keresi meg, és ember dönt
Revenue management rendszer (RMS)	Árak és foglalási korlátozások javaslása vagy automatikus beállítása a kereslet alapján	Emelni vagy csökkenteni érdemes az árat egy jövőbeli napra?	Árazó rendszer; sok RMS-ben van riportfunkció is, de nem ez a szálloda általános elemzőeszköze

A recepció és a foglaláskezelés napi munkájához a PMS-riport pont elég. A BI akkor éri meg, ha egy kérdés megválaszolásához több rendszer adata kell. Akkor is megéri, ha a mostani számokat megbízhatóan össze akarod vetni a korábbi időszakok számaival, vagy ugyanazt a számot több szempontból is meg akarod nézni. Az RMS feladata szűkebb: az árat határozza meg. Erről a revenue management szoftverekről szóló útmutatónkban írtunk bővebben.

Minden munkakör más kérdésre keres választ

Egy BI-eszköz akkor hasznos, ha mindenki gyorsan választ kap benne azokra a kérdésekre, amelyek a munkájához kellenek:

• Tulajdonos vagy szállodaigazgató: Ebben a hónapban több vagy kevesebb a bevétel, mint amennyit a budgetben terveztünk? Mi okozza az eltérést?
• Revenue manager: Gyorsabban vagy lassabban érkeznek a foglalások a következő nyolc hétre, mint általában? Melyik szegmens vagy csatorna okozza a változást?
• Értékesítés és marketing: Melyik céges partner vagy kampány hozott foglalást, és melyik napokra?
• Pénzügy: Hogyan áll a hónap eddigi bevétele a budgethez és a korábbi hónapokhoz képest?

Egy kis független szállodában ezeket a szerepeket gyakran ugyanaz a két-három ember tölti be, ezért itt még fontosabbak a közös definíciók. Különben könnyen előfordul, hogy ugyanaz az ember a havi terv követésénél más tételeket számol bele a bevételbe, mint a heti árazásnál.

Minden KPI-nak legyen írásos definíciója

Előbb azt tisztázd, milyen döntést akarsz meghozni, és csak utána válassz hozzá mutatót. Gyakori mutató a foglaltság, az ADR, a RevPAR, a szobabevétel, a tartózkodási idő, a lemondások száma és a foglalások megoszlása csatornák és szegmensek szerint. Sokan figyelik a foglalási előidőt is, vagyis azt, hogy a vendégek hány nappal érkezés előtt foglalnak. Az ADR az átlagos napi szobaár, a RevPAR pedig az egy kiadható szobára jutó szobabevétel. A képletüket az ADR jelentéséről és a RevPAR számításáról szóló cikkeinkben találod. Szinte minden BI-kimutatásban előkerül még három fogalom a szállodai revenue managementből:

• On the books (OTB): a jövőbeli dátumokra eddig lefoglalt szobák és a hozzájuk tartozó bevétel.
• Pickup: mennyivel változott a foglalások száma egy adott időszak alatt, a lemondásokat levonva.
• Booking pace: egy adott érkezési napra gyorsabban vagy lassabban gyűlnek-e a foglalások, mint tavaly ugyanennyi nappal érkezés előtt, vagy mint az előrejelzésben.

Sok szálloda ugyanarra a hónapra három számot is összevet: az év elején elfogadott budgetet, az aktuális előrejelzést és a tényleges eredményt. Ha a hármat egymás mellett látod, kiderül, hogy az eltérést a pontatlan terv vagy a várttól eltérő értékesítés okozta.

Ugyanarra a mutatóra két ésszerű definíció is létezhet, és a kettő két különböző számot ad. Benne van-e a szobabevételben a reggeli, az idegenforgalmi adó, a lemondási és a no-show díj? A foglaltságot az összes szobához viszonyítod, vagy csak a kiadhatókhoz? Csatornának az eredeti foglalási forrást tekinted, vagy az egységesített kategóriát? Ezekről elég egyszer dönteni, de a döntést írd le, és mindenhol ugyanazt használd.

Annyira bontsd le a számokat, amennyire a döntéshez kell. A havi összesítésből látszik, hogy eltér-e a bevétel a tervtől vagy a tavalyitól, a napi vagy szegmens szerinti bontásból pedig az, hogy mely napok vagy vendégcsoportok miatt. Kis szállodában viszont kevés foglalás is nagy kilengést okoz: egy 40 szobás hotelben egyetlen nyolcszobás csoport 20 százalékponttal emeli az adott éjszaka foglaltságát.

Egy foglalás útja a döntésig: szemléltető példa

A példa egy kitalált, 40 szobás szállodáról szól, a számok nem piaci átlagok.

A PMS-ben van egy foglalás ezekkel az adatokkal: tartózkodási nap 2027. március 13. (szombat); két szoba; egy éjszaka; szobabevétel 96 000 Ft adók nélkül; státusz megerősített; szegmenskód WEB; forráskód DIR; a foglalás napja 2027. január 27. A BI-ban beállított kódtábla szerint a WEB egyéni szabadidős vendéget, a DIR a saját weboldalon érkezett foglalást jelenti.

A BI a 96 000 Ft-ot a tartózkodási naphoz, március 13-hoz rendeli, nem a foglalás napjához. Két eladott szobaéjszakát számol, és ebből kiszámolja a foglalás ADR-jét:

96 000 Ft ÷ 2 szobaéjszaka = 48 000 Ft ADR

A tavalyi megfelelő szombat 2026. március 14. volt. Negyvenöt nappal érkezés előtt a vezető megnézi, hány foglalás volt erre a tavalyi napra szintén 45 nappal előtte, és ezzel veti össze az idei számokat. A tavalyi végeredménnyel nem érdemes összevetni, mert sok foglalás csak az utolsó hetekben jön be.

45 nappal érkezés előtt	Tavaly	Idén
Eddig lefoglalt szobák (OTB)	25	26
Közvetlen szabadidős foglalás	12	7
OTA	9	15
Egyéb	4	4

Első ránézésre az összesített szám rendben van, a bontás viszont nem: öt közvetlen foglalással kevesebb és hattal több OTA-foglalás jött. Az OTA-foglalások után jutalékot fizetsz, így közel ugyanannyi eladott szoba most kevesebb nettó bevételt hoz.

Ezért a vezető egyelőre nem nyúl az árhoz, hanem előbb négy dolgot ellenőriztet a csapattal. Foglalható-e a szoba közvetlenül a weboldalon? Látszik-e a foglalómotorban minden ártípus, például a rugalmas és a vissza nem téríthető ár is? Ugyanannyiba kerül-e a szoba az OTA-kon, mint a saját oldalon? Nem állt-e le egy nemrég indított kampány? A csapat feljegyzi, mit talált, és a következő heti megbeszélésen újra megnézi ezt a napot. A döntést nem a BI hozta meg, de a vezető a BI-nak köszönhetően perceken belül látta, mit kell megvizsgálni, és nem egy egész délutánt töltött Excel-táblákkal.

A BI megmutatja, mit kell megvizsgálni, a döntés a tiéd

Ha jól működik a szállodai BI, kevesebb riportot kell kézzel egyeztetni, és minden megbeszélés ugyanazokból a számokból indul. Könnyebb észrevenni, ha valami eltér a megszokottól, és külön látod egy adott éjszaka foglaltságát és bevételét, és azt is, mikor foglalták le a szobákat arra az éjszakára.

De vannak korlátai is. Ha a PMS-ben hibás az adat, a BI-ban is hibás lesz, és egy szép grafikon könnyen elfedi, ha egy kód rossz kategóriába került. A tavalyi számok sem mindig mérvadók, ha azóta megváltozott a piac. És ha egy változás egy kampánnyal egy időben jelenik meg, attól még nem biztos, hogy a kampány okozta.

Az adatvédelmi szabályok itt is érvényesek: a személyes adatokból csak annyit használj fel, amennyire az elemzéshez valóban szükség van, és szabályozd, ki mit láthat.

A BI-eszközt a saját kérdéseiddel teszteld

Ne a funkciólistából indulj ki, hanem a saját döntéseidből. Írj le három-öt kérdést, amelyet a csapatod minden héten feltesz, és mindegyik mellé azt is, ki kérdezi, és mit kezd a csapat a válasszal. A BI-eszközöket ezekkel a kérdésekkel, a saját adataiddal és a saját definícióiddal érdemes kipróbálni.

Minden szolgáltatótól érdemes megkérdezni:

• Mely rendszereidhez tud kapcsolódni, és hogyan egységesíti a különböző kódokat?
• Milyen gyakran frissülnek az adatok, és látszik-e, mikor frissültek utoljára?
• Meg lehet-e nézni, mely foglalásokból áll össze egy összeg?
• Mit csinál az eszköz, ha egy forrás nem elérhető, vagy egy foglalást utólag módosítanak?
• Ki tartja karban a kódtáblát és a definíciókat az indulás után?

A tesztet azok végezzék, akik naponta használni fogják az eszközt. Meg tudják-e különböztetni a foglalás napját a tartózkodási naptól? Látják-e, milyen szűrők vannak bekapcsolva? Megtalálják-e a választ úgy, hogy nem kell saját táblázatot készíteniük a riportból?

Ha már RoomRaiser-felhasználó vagy, a RoomRaiser BI-ban a saját foglaltsági, ADR-, RevPAR-, bevételi, pickup- és booking pace-adataidat látod, csatorna, szobatípus, időszak és szálloda szerinti bontásban. Azt is látod, hogyan áll a tényleges eredmény a budgethez és az aktuális előrejelzéshez képest. Ütemezett riportokat, exportot és riasztásokat állíthatsz be, a jogosultságokat szerepkörök szerint adhatod ki, és több pénznemben is dolgozhatsz.

A szolgáltatók árait csak akkor érdemes összehasonlítani, ha már látod, hogy az eszköz beleillik a csapatod napi munkájába. Az árat pedig ahhoz mérd, mennyi kézi munkát takarít meg.

Kezdd egy felelőssel és három kérdéssel

Jelölj ki egy kollégát, aki a BI-kimutatásokért felel, és válassz ki három kérdést, amelyre minden héten választ keresel. Írd le, melyik szám melyik rendszer melyik mezőjéből jön, hogyan számolod a mutatókat, mit hagysz ki a számításból, és melyik kódot melyik kategóriába sorolod. Mielőtt több kollégának hozzáférést adsz, vesd össze egy lezárt hónap számait a PMS ugyanerre az időszakra vonatkozó adataival, és minden nagyobb eltérésnek járj utána.

Ezután alakíts ki egy egyszerű rutint: ki nézi rendszeresen a kimutatást, mekkora eltérésnek kell utánajárni, hol jegyzi fel a csapat a teendőket, és mikor ellenőrzi, hogy azok meghozták-e a várt eredményt. Tanítsd meg a kollégákat a számok értelmezésére, ne csak arra, hol kell kattintani.

Az indulás után figyeld, hogy frissek-e az adatok, maradt-e kategória nélküli kód, és változott-e valamelyik definíció. Új mutatót csak akkor vegyél fel, ha van felelőse, aki használja is. Így előbb meggyőződhetsz róla, hogy a számok helyesek, és csak utána érdemes több kollégát bevonni vagy újabb kimutatásokat készíteni.

Gyakori kérdések