Sprzedaż tych samych pokoi na Booking.com, Airbnb, Expedia i własnej stronie internetowej to najprostszy sposób na zapełnienie małego hotelu. To także najprostszy sposób, aby sprzedać ten sam pokój dwa razy.
Overbooking jest kosztowny. Trzeba opłacić gościowi alternatywne zakwaterowanie, można stracić opinię, a OTA mogą ukarać ofertę. Dobra wiadomość jest taka, że prawie każdy overbooking ma jasną przyczynę techniczną, a większości z nich można zapobiec dzięki poprawnej konfiguracji.
Jak naprawdę dochodzi do overbookingu
Ręczne aktualizacje w extranecie
Jeśli dostępność jest aktualizowana ręcznie po zalogowaniu się do każdego extranetu, zawsze pojawia się luka między rezerwacją z jednego kanału a zamknięciem pokoju w pozostałych. W pracowity wieczór w tę lukę mogą wpaść dwie rezerwacje.
Opóźnienia iCal
Wiele małych obiektów łączy Airbnb, Vrbo i inne platformy za pomocą linków kalendarza iCal. iCal jest prosty i bezpłatny, ale nie działa w czasie rzeczywistym. Każda platforma pobiera kalendarz według własnego harmonogramu, zwykle co 30 minut do kilku godzin. W tym czasie pokój, który właśnie został sprzedany gdzie indziej, nadal wygląda na wolny.
iCal udostępnia też tylko zablokowane daty. Nie wysyła cen, ograniczeń ani liczby pozostałych pokoi, dlatego słabo sprawdza się w przypadku czegokolwiek poza pojedynczą jednostką.
Dwukierunkowe API a iCal
Dwukierunkowe połączenie API działa inaczej. Dostępność, ceny i ograniczenia są wysyłane do kanału od razu po zmianie, a nowe rezerwacje, modyfikacje i anulacje wracają automatycznie do systemu. Okno czasowe, w którym może dojść do podwójnej rezerwacji, skraca się z godzin do sekund.
Błędy mapowania typów pokoi
Każdy kanał ma własną listę typów pokoi, a channel manager musi poprawnie je zmapować. Jeśli „Double with balcony” zostanie przypisany do niewłaściwego pokoju na Booking.com albo dwa typy pokoi z kanału wskazują na tę samą fizyczną pulę pokoi bez wspólnego liczenia, dostępność się rozjedzie.
Mapowanie planów cenowych
Plany cenowe, takie jak bezzwrotne, ze śniadaniem lub długi pobyt, również wymagają mapowania. Plan cenowy, który nie jest zmapowany albo jest przypisany do niewłaściwego pokoju, może pozostać otwarty w kanale, choć w obiekcie uznano go za zamknięty.
Zamknięte daty nie zostały wysłane
Data zostaje zamknięta z powodu konserwacji lub prywatnego wydarzenia we własnym systemie, ale zamknięcie nigdy nie trafia do jednego z kanałów, być może dlatego, że jest on połączony przez iCal albo dany typ pokoju nie jest zmapowany. Kanał nadal sprzedaje.
Anulacje nie wracają do systemu
Gdy anulacja lub modyfikacja w OTA nie dotrze do systemu, pokój pozostaje zablokowany albo, co gorsza, zmieniony zakres dat nie zostaje zaktualizowany. Czasem dzieje się odwrotnie: rezerwacja zostaje anulowana w systemie, ale kanał nadal traktuje ją jako aktywną.
Lista kontrolna konfiguracji
Większość pracy związanej z zapobieganiem overbookingowi wykonuje się raz, podczas podłączania kanałów. Warto dokładnie przejść przez tę listę.
- Wybierz jedno źródło prawdy. Cała dostępność powinna pochodzić z jednego miejsca: PMS i channel managera. Należy przestać edytować dostępność bezpośrednio w extranetach, z wyjątkiem sytuacji awaryjnych.
- Zmapuj każdy typ pokoju. Sprawdź, czy każdy typ pokoju w każdym kanale jest przypisany do właściwego pokoju w systemie i czy nic nie pozostało niezmapowane.
- Zmapuj każdy plan cenowy. To samo należy zrobić z planami cenowymi. Zamknij lub usuń w kanale każdy plan cenowy, którego nie zamierzają Państwo sprzedawać.
- Ustaw maksymalną sprzedaż na kanał, jeśli jest potrzebna. Allotmenty lub wartość „max to sell” pozwalają ograniczyć liczbę pokoi, które może pobrać każdy kanał, na przykład zostawiając dwa pokoje na rezerwacje bezpośrednie w wysokim sezonie.
- Rozważ niewielki bufor. W terminach o wysokim popycie zatrzymanie jednego pokoju poza OTA daje miejsce, w którym można zakwaterować gościa, jeśli coś pójdzie nie tak.
- Ustaw minimalną długość pobytu i inne ograniczenia centralnie. Minimalna długość pobytu, zamknięcie na przyjazd i zamknięcie na wyjazd powinny być ustawiane raz i wysyłane do każdego kanału, a nie utrzymywane osobno.
- Zastąp iCal tam, gdzie to możliwe. Korzystaj z połączeń dwukierunkowych dla każdego kanału, który je oferuje, a iCal zostaw tylko dla platform, gdzie API nie jest dostępne.
- Przetestuj przed uruchomieniem. Zrób testową rezerwację i anulację w każdym kanale oraz sprawdź, czy poprawnie pojawiają się w kalendarzu.
- Regularnie sprawdzaj dziennik połączeń. Dobry channel manager pokazuje nieudane aktualizacje. Przez pierwsze tygodnie warto zaglądać tam codziennie.
Co zrobić, gdy overbooking mimo wszystko się zdarzy
Nawet przy starannej konfiguracji overbooking nadal może się zdarzyć, na przykład podczas awarii kanału. Warto mieć gotowy plan, aby nie improwizować przy gościu stojącym przy recepcji.
Działaj jak najwcześniej. Gdy tylko zauważą Państwo podwójną rezerwację, trzeba zdecydować, która rezerwacja zostanie przeniesiona. Kontakt z gościem kilka dni wcześniej jest znacznie lepszy niż informowanie go przy przyjeździe.
Miej procedurę przeniesienia gościa. Procedura przeniesienia określa, jak relokować gościa, którego nie można zakwaterować. Zwykle obejmuje pobliskie obiekty, z których się korzysta, to, kto płaci za alternatywny pokój i transport, oraz kto podejmuje decyzję.
Przenieś gościa do obiektu o takim samym lub wyższym standardzie. Warto mieć krótką listę pobliskich hoteli o podobnym lub wyższym standardzie oraz z góry uzgodnić z ich właścicielami wzajemną pomoc w razie potrzeby.
Zaproponuj uczciwą rekompensatę. Opłać różnicę w cenie i taksówkę oraz rozważ gest, na przykład rabat na przyszły pobyt. Dobrze przeprowadzona relokacja często nadal kończy się pozytywną opinią.
Skontaktuj się z supportem partnerskim OTA. Jeśli rezerwacja przyszła przez Booking.com, Airbnb lub inny kanał, poinformuj zespół wsparcia dla partnerów, co się stało. Mogą pomóc w kontakcie z gościem, a udokumentowanie przyczyny chroni ofertę, jeśli była to usterka techniczna.
Znajdź przyczynę. Po zaopiekowaniu się gościem należy dokładnie prześledzić, dlaczego do tego doszło: mapowanie, opóźnienie iCal, ręczna zmiana czy nieudana aktualizacja. Następnie trzeba to naprawić, aby sytuacja się nie powtórzyła.
Jak radzi sobie z tym channel manager Ospitessa
Channel manager Ospitessa jest wbudowany w PMS, dlatego kalendarz używany na co dzień jest jedynym źródłem dostępności.
- W kanałach z połączeniem dwukierunkowym dostępność, ceny i ograniczenia są wysyłane w ciągu kilku sekund od każdej zmiany, a rezerwacje, modyfikacje i anulacje wracają automatycznie.
- Połączenia obejmują Booking.com, Expedia, Airbnb, Agoda, Trip.com, Google Hotels, Vrbo, Hotelbeds, Hostelworld, HRS oraz ponad 70 innych partnerów. Pełna lista znajduje się na naszej stronie integracji.
- iCal jest dostępny tylko jako rozwiązanie awaryjne dla platform bez połączenia API.
- Typy pokoi i plany cenowe mapuje się raz, a allotmenty, minimalną długość pobytu i inne ograniczenia można ustawiać w jednym miejscu przez ceny i dostępność.
- Rezerwacje z własnego systemu rezerwacji online (booking engine) aktualizują ten sam kalendarz, więc rezerwacje bezpośrednie i OTA nigdy nie konkurują o ten sam pokój.
Jeśli przechodzą Państwo z ręcznych aktualizacji w extranecie lub linków iCal i chcą sprawdzić mapowanie przed zmianą, umów demo, a przejdziemy przez to wspólnie.



