Channel manager alapok: túlfoglalás nélkül

Ugyanazokat a szobákat értékesíteni Booking.com-on, Airbnb-n, Expedián és a saját weboldalán a legegyszerűbb módja annak, hogy egy kisebb szálloda megteljen. Ugyanakkor ez a legegyszerűbb módja annak is, hogy ugyanazt a szobát kétszer adja el.

A túlfoglalás költséges. Ön fizeti a vendég alternatív szállását, elveszíthet egy értékelést, az OTA-k pedig hátrébb sorolhatják vagy büntethetik a hirdetését. A jó hír: szinte minden túlfoglalásnak egyértelmű technikai oka van, és a legtöbb helyes beállítással megelőzhető.

Hogyan történnek valójában a túlfoglalások

Kézi extranet-frissítések

Ha az elérhetőséget úgy frissíti, hogy minden extranetre külön belép és kézzel módosít, mindig lesz egy rés aközött, hogy az egyik csatornán beérkezik egy foglalás, és Ön lezárja a szobát a többi csatornán. Egy forgalmas estén két foglalás is beeshet ebbe az időablakba.

iCal-késések

Sok kisebb szálláshely iCal-naptárhivatkozásokkal köti össze az Airbnb-t, a Vrbo-t és más platformokat. Az iCal egyszerű és ingyenes, de nem valós idejű. Minden platform a saját ütemezése szerint olvassa be a naptárat, jellemzően 30 percenként vagy néhány óránként. Ebben az időablakban egy máshol éppen eladott szoba még szabadnak látszik.

Az iCal ráadásul csak a lezárt dátumokat osztja meg. Nem küld árakat, korlátozásokat vagy fennmaradó szobaszámot, ezért egyetlen egységen kívül szinte minden másra gyengén működik.

Kétirányú API vs iCal

A kétirányú API-kapcsolat másképp működik. Az elérhetőség, az árak és a korlátozások azonnal átkerülnek a csatornára, amint változnak, az új foglalások, módosítások és lemondások pedig automatikusan visszaérkeznek az Ön rendszerébe. Az az időablak, amelyben dupla foglalás történhet, órákról másodpercekre csökken.

Szobatípus-mapping hibák

Minden csatornának saját szobatípus-listája van, és a channel managernek ezeket helyesen kell összerendelnie. Ha az Ön „Erkélyes kétágyas” szobája rossz szobához van rendelve Booking.com-on, vagy két csatornabeli szobatípus ugyanarra a fizikai készletre mutat anélkül, hogy együtt számolná őket a rendszer, az elérhetőség eltérhet a valóságtól.

Árterv-mapping

Az olyan árterveket is össze kell rendelni, mint a nem lemondható, a reggelivel vagy a hosszú tartózkodásra szóló ár. Egy nem összerendelt, vagy rossz szobához rendelt árterv nyitva maradhat egy csatornán akkor is, amikor Ön azt gondolta, hogy lezárta.

Nem kiküldött lezárt dátumok

Ön lezár egy dátumot karbantartás vagy privát esemény miatt a saját rendszerében, de a lezárás nem jut el az egyik csatornára – például mert iCal-kapcsolaton fut, vagy mert az adott szobatípus nincs összerendelve. A csatorna pedig tovább értékesít.

Vissza nem érkező lemondások

Ha egy OTA-n történt lemondás vagy módosítás nem érkezik meg az Ön rendszerébe, a szoba továbbra is blokkolva marad, vagy ami még rosszabb: a módosított dátumtartomány nem frissül. Néha ennek a fordítottja történik: Ön lemondja a foglalást a saját rendszerében, de a csatorna továbbra is aktívként kezeli.

Beállítási ellenőrzőlista

A túlfoglalások megelőzésének legnagyobb része egyszeri munka, amikor csatlakoztatja a csatornáit. Menjen végig figyelmesen ezen a listán.

Válasszon egyetlen igazságforrást. Minden elérhetőség egy helyről érkezzen: a PMS-ből és a channel managerből. Ne szerkessze közvetlenül az elérhetőséget az extranetekben, kivéve vészhelyzetben.
Rendeljen össze minden szobatípust. Ellenőrizze, hogy minden csatornán minden szobatípus a megfelelő szobához van-e rendelve az Ön rendszerében, és semmi sem maradt összerendeletlenül.
Rendeljen össze minden ártervet. Ugyanezt végezze el az árterveknél is. Zárjon le vagy töröljön minden olyan ártervet a csatornán, amelyet nem kíván értékesíteni.
Állítson be csatornánkénti maximumot, ha szükséges. Az allotmentek vagy a „max to sell” értékek segítségével korlátozhatja, hogy egy-egy csatorna hány szobát értékesíthet – például főszezonban két szobát megtarthat közvetlen foglalásokra.
Fontolja meg egy kis puffer használatát. Nagy keresletű dátumokon, ha egy szobát visszatart az OTA-któl, lesz hova elhelyeznie a vendéget, ha valami hiba történik.
Központilag állítsa be a minimális tartózkodást és más korlátozásokat. A minimális tartózkodást, az érkezésre lezárt és a távozásra lezárt napokat egyszer kell beállítani és minden csatornára kiküldeni, nem külön-külön karbantartani.
Ahol lehet, váltsa le az iCalt. Használjon kétirányú kapcsolatot minden olyan csatornánál, amely ezt kínálja, és az iCalt csak azoknál a platformoknál tartsa meg, ahol nincs elérhető API.
Teszteljen élesítés előtt. Készítsen tesztfoglalást és lemondást minden csatornán, majd ellenőrizze, hogy helyesen jelennek-e meg a naptárában.
Rendszeresen ellenőrizze a kapcsolati naplót. Egy jó channel manager megmutatja a sikertelen frissítéseket. Az első hetekben nézze meg minden nap.

Mit tegyen, ha mégis túlfoglalás történik

Gondos beállítás mellett is előfordulhat túlfoglalás, például egy csatornahiba idején. Legyen kész terve, hogy ne a recepción, a vendég előtt kelljen rögtönöznie.

Cselekedjen a lehető legkorábban. Amint észreveszi a dupla foglalást, döntse el, melyik foglalást helyezi át. Sokkal jobb napokkal előre kapcsolatba lépni a vendéggel, mint érkezéskor közölni vele a problémát.

Legyen walk policy-je. A walk policy rögzíti, hogyan helyez át vendéget, ha nem tudja elszállásolni. Általában tartalmazza, mely közeli szálláshelyeket használja, ki fizeti az alternatív szobát és a transzfert, valamint ki hozza meg a döntést.

Azonos vagy jobb színvonalú szálláshelyre helyezze át a vendéget. Tartson rövid listát hasonló vagy magasabb kategóriájú közeli hotelekről, és előre állapodjon meg a tulajdonosaikkal, hogy szükség esetén segítik egymást.

Ajánljon méltányos kompenzációt. Fizesse ki az árkülönbözetet és a taxit, és fontoljon meg egy gesztust, például kedvezményt egy későbbi tartózkodásra. Egy jól kezelt áthelyezés gyakran így is pozitív értékeléssel zárul.

Vegye fel a kapcsolatot az OTA partner supportjával. Ha a foglalás Booking.com-on, Airbnb-n vagy más csatornán keresztül érkezett, jelezze a partner support csapatnak, mi történt. Segíthetnek a vendég kezelésében, az ok dokumentálása pedig védi a hirdetését, ha technikai hiba történt.

Keresse meg az okot. Miután a vendégről gondoskodtak, pontosan derítse ki, miért történt: mapping hiba, iCal-késés, kézi módosítás vagy sikertelen frissítés. Javítsa ki, hogy ne forduljon elő újra.

Hogyan kezeli ezt az Ospitessa channel managere

Az Ospitessa channel manager beépül a PMS-be, így a mindennap használt naptár az elérhetőség egyetlen forrása.

A kétirányú kapcsolattal rendelkező csatornákon az elérhetőség, az árak és a korlátozások bármilyen változás után másodperceken belül kiküldésre kerülnek, a foglalások, módosítások és lemondások pedig automatikusan visszaérkeznek.
A kapcsolatok lefedik a Booking.com, Expedia, Airbnb, Agoda, Trip.com, Google Hotels, Vrbo, Hotelbeds, Hostelworld, HRS rendszereket és több mint 70 további partnert. A teljes listát az integrációk oldalán találja.
Az iCal csak tartalék megoldásként érhető el azoknál a platformoknál, ahol nincs API-kapcsolat.
A szobatípusokat és árterveket egyszer kell összerendelni, az allotmenteket, a minimális tartózkodást és más korlátozásokat pedig egy helyen állíthatja be az árak és elérhetőség felületen.
A saját online foglalási rendszerből (booking engine) érkező foglalások ugyanazt a naptárat frissítik, így a közvetlen és az OTA-foglalások soha nem versenyeznek ugyanazért a szobáért.

Ha kézi extranet-frissítésekről vagy iCal-linkekről váltana, és az átállás előtt ellenőrizné a mappinget, kérjen demót, és közösen átnézzük Önnel.

channel managertúlfoglalásBooking.comAirbnbértékesítés