Overbooking w systemach rezerwacyjnych - jak technologia pomaga uniknąć kosztownych błędów

Linie lotnicze sprzedają więcej biletów, niż mają foteli w samolocie, i robią to z pełną świadomością. Z danych wiedzą, ilu pasażerów nie pojawi się przy bramce, więc dosprzedają miejsca, które inaczej poleciałyby puste. Pensjonat z dwunastoma pokojami potrafi zrobić to samo, tylko przypadkiem: ten sam pokój schodzi w ciągu godziny na Booking.com i na Airbnb, a właściciel dowiaduje się o tym od drugiego gościa, który stoi w recepcji z potwierdzeniem w telefonie. Overbooking w systemach rezerwacyjnych ma więc dwie twarze. Jedna to decyzja biznesowa. Druga to awaria, której nikt nie planował. Dla klienta obie wyglądają tak samo: zapłacił i nie dostaje tego, co kupił. Różnica leży po stronie firmy. Przewoźnik ma na taką sytuację procedurę, budżet na odszkodowania i przepisy, które mówią, co komu się należy. Mały hotel ma zwykle numer do zaprzyjaźnionego obiektu po drugiej stronie ulicy i nadzieję, że tam coś się zwolniło.

Przy projektowaniu oprogramowania dla hoteli i turystyki szybko wychodzi na jaw, że podwójna rezerwacja rzadko ma jedną przyczynę. Zwykle składa się na nią kilka drobnych opóźnień, jeden ręczny wpis i kalendarz, który „prawie zawsze” jest aktualny. Ten tekst rozkłada te elementy na części i pokazuje, które z nich rozwiązuje technologia, a które trzeba naprawić w organizacji pracy.

Overbooking celowy i przypadkowy to dwa różne problemy

Celowy overbooking wynika z prostego rachunku. Część klientów rezygnuje w ostatniej chwili albo po prostu nie przychodzi, więc firma sprzedaje odrobinę więcej, niż ma, licząc na to, że rezygnacje wyrównają nadwyżkę. Tak postępują linie lotnicze, hotele z własnym działem sprzedaży i cen, a także niektóre przychodnie, które na godziny z dużą liczbą nieodwołanych wizyt zapisują dwóch pacjentów.

Skala odwołań w hotelarstwie dobrze tłumaczy tę pokusę. Firma D-Edge przeanalizowała rezerwacje online w 680 europejskich obiektach i policzyła, że w 2018 roku anulowano 39,6 proc. z nich. Przy rezerwacjach z Booking.com odsetek sięgał 50 proc., przy rezerwacjach bezpośrednich na stronie hotelu 18,2 proc. Dane mają już kilka lat, ale mechanizm się nie zmienił: darmowa anulacja zachęca do rezerwowania „na zapas”.

Przypadkowy overbooking to inna historia. Nikt niczego nie zakładał. System po prostu nie wiedział, że termin jest już zajęty, bo informacja dotarła za późno, trafiła w złe miejsce albo nie trafiła nigdzie. Rozdzielenie tych zjawisk ma praktyczne znaczenie. Celowy overbooking wymaga prognoz, limitów i planu na wypadek, gdyby prognoza zawiodła, czyli narzędzi z obszaru revenue managementu w hotelach i nieruchomościach. Przypadkowy wymaga porządnej architektury systemu. Firma, która po serii podwójnych rezerwacji kupuje narzędzie do prognozowania popytu, leczy nie tę chorobę.

Gdzie system rezerwacyjny gubi informację o dostępności

Podwójne rezerwacje mają kilka powtarzalnych przyczyn. Booking.com w dokumentacji dla partnerów technologicznych wymienia wśród nich awarie, które blokują aktualizację dostępności, spóźnione zamykanie terminów i błędnie przypisane stawki. Z perspektywy obiektu wygląda to tak.

Kalendarze, które synchronizują się co kilka godzin

Najprostszy sposób łączenia kanałów sprzedaży to iCal, czyli plik kalendarza, który serwisy pobierają od siebie nawzajem w regularnych odstępach. Działa bez umów i integracji, dlatego korzysta z niego wielu właścicieli apartamentów. Ma jednak wbudowane opóźnienie. Airbnb aktualizuje importowane kalendarze co 3 godziny, a przez ten czas termin sprzedany gdzie indziej nadal wygląda na wolny.

Przy kilku lokalach i rezerwacjach robionych z tygodniowym wyprzedzeniem ryzyko jest niewielkie. W długi weekend, gdy rezerwacje last minute wpadają jedna po drugiej, trzy godziny to bardzo długo.

Channel manager, który też ma swoje okno

Channel manager w hotelu to system pośredniczący między obiektem a portalami rezerwacyjnymi, który wymienia z nimi dane przez API, czyli bezpośrednie połączenie między programami, a nie przez pliki kalendarza. Opóźnienie spada z godzin do sekund lub minut. Nie znika jednak całkiem. Booking.com zaleca partnerom pobieranie nowych rezerwacji co 30 sekund lub częściej, bo przy rzadszym odpytywaniu rośnie ryzyko, że termin zostanie zamknięty dopiero po tym, jak ktoś go kupi. Znaczenie ma też konfiguracja. Źle przypisany typ pokoju, np. apartament z balkonem połączony w portalu z inną kategorią niż w systemie obiektu, potrafi sprzedawać się podwójnie mimo najszybszej synchronizacji.

Dwa kliknięcia w tej samej sekundzie

Ten problem dotyczy głównie własnego silnika rezerwacji na stronie. Dwie osoby wybierają ten sam termin, system dla każdej z nich sprawdza dostępność, obie widzą „wolne” i obie przechodzą do płatności. Programiści nazywają to race condition, czyli wyścigiem operacji, w którym wynik zależy od tego, która z nich skończy się pierwsza. Przy spokojnym ruchu zdarza się rzadko. Przy promocji startującej o konkretnej godzinie może powtarzać się wielokrotnie w ciągu kilku minut.

Rezerwacje wpisane obok systemu

Telefon do recepcji, mail od stałego klienta, grupa „na słowo” od handlowca, który trzyma opcję w swoim arkuszu. Każda taka rezerwacja, która nie trafi od razu do wspólnego kalendarza, jest dla pozostałych kanałów niewidzialna. Szczególnie narażone są obiekty sprzedające też sale i pakiety grupowe, w których opcje i terminy ich zwolnienia często żyją w notatkach, poza systemem do zarządzania hotelem.

Dlatego narzędzia dla działu sprzedaży powinny korzystać z tych samych danych co system rezerwacyjny. Tak działa panel ofertowy dla operatora apartamentów, który zbudowaliśmy dla firmy zarządzającej ponad 400 lokalami na tym samym zapleczu co jej platforma rezerwacyjna: handlowiec przygotowuje ofertę na podstawie tych samych terminów i cen, które widzi klient rezerwujący online.

Anulacje i zmiany, które otwierają kalendarz

Ta przyczyna jest mniej oczywista. Gość skraca pobyt albo anuluje rezerwację, system automatycznie przywraca noce do sprzedaży, a w tym samym czasie inny kanał trzyma jeszcze starą wersję. Booking.com wymienia błędne przywracanie dostępności po anulacjach jako jedną z typowych przyczyn overbookingu. Kłopot rośnie, gdy zmiana rezerwacji jest technicznie anulacją i nową rezerwacją, a obie operacje docierają do kanałów w odwrotnej kolejności.

Ile naprawdę kosztuje termin sprzedany dwa razy

Najłatwiej policzyć koszt bezpośredni. Obiekt musi znaleźć gościowi zastępczy nocleg, zwykle o standardzie nie niższym niż zarezerwowany, a często pokryć różnicę w cenie i dojazd. W sezonie, gdy okoliczne hotele też są pełne, zastępczy pokój bywa droższy niż cała pierwotna rezerwacja. Do tego dochodzą kary kanałów sprzedaży. Airbnb za anulowanie potwierdzonej rezerwacji pobiera od gospodarza opłatę za anulację w wysokości od 10 do 50 proc. wartości rezerwacji, zależnie od tego, ile czasu zostało do przyjazdu. Blokuje też kalendarz oferty na anulowane daty i może odebrać status Superhosta. Podwójna rezerwacja jest w tych zasadach wymieniona wprost. W lotnictwie koszty określa prawo. Pasażer, któremu w UE odmówiono wejścia na pokład wbrew jego woli, ma prawo do odszkodowania od 250 do 600 euro zależnie od długości trasy, niezależnie od zwrotu biletu albo lotu zastępczego.

Najtrudniej wycenić to, czego nie widać w rozliczeniu. Negatywna opinia zostaje w profilu obiektu na lata. Recepcja traci godzinę albo dwie na telefony. Gość, który spędził wieczór w taksówce do innego hotelu, raczej nie wróci.

Taki rachunek ma sens dopiero w skali roku. Koszt jednego incydentu trzeba pomnożyć przez liczbę incydentów i porównać z ceną zmian w systemie. Dla obiektu, który zalicza jeden overbooking na dwa lata, wynik będzie zupełnie inny niż dla sieci apartamentów, w której zdarza się to co miesiąc.

Jedno źródło prawdy o dostępności

System odporny na podwójne rezerwacje zaczyna się od prostej zasady: dostępność jest przechowywana w jednym miejscu. Wszystkie kanały, czyli strona internetowa, portale, recepcja i handlowcy, czytają z niego i do niego zapisują. Żaden kanał nie prowadzi własnego kalendarza, który trzeba potem uzgadniać z resztą. W hotelarstwie tę rolę pełni zwykle centralny system rezerwacji (CRS) albo system zarządzania obiektem połączony z channel managerem. Druga zasada: dostępność się oblicza, a nie wpisuje. Liczba wolnych pokoi na dany dzień powinna wynikać z rezerwacji, blokad i wyłączeń serwisowych, a nie z pola, które ktoś zmienia ręcznie. Ręcznie ustawiany licznik prędzej czy później rozjedzie się z rzeczywistością.

Kolejna kwestia to sposób przekazywania zmian. Zamiast czekać, aż kanały same zapytają o nowy stan, system powinien powiadamiać je od razu, np. przez webhook, czyli automatyczne powiadomienie wysyłane do innej aplikacji w chwili, gdy coś się zmienia. Jeśli portal akurat nie odpowiada, komunikat nie może przepaść. Trafia do kolejki wiadomości w architekturze systemu, która ponawia wysyłkę do skutku i pilnuje kolejności zmian. Dzięki temu anulacja nie dotrze do portalu przed rezerwacją, której dotyczy.

Dobrze zaprojektowany system rezerwacyjny z własnym silnikiem rezerwacji łączy te zasady w całość. Nie zawsze trzeba go budować od zera. Często wystarczy porządnie wpiąć własną stronę rezerwacji w istniejący system obiektu i channel manager.

Co się dzieje, gdy dwie osoby klikają „rezerwuj” w tej samej sekundzie

Tu wchodzimy do środka aplikacji, ale mechanizmy da się opisać bez kodu.

Pierwsza linia obrony to transakcja w bazie danych, czyli zestaw operacji, które wykonują się w całości albo wcale. Sprawdzenie dostępności i zapis rezerwacji muszą należeć do jednej transakcji, inaczej między nimi zmieści się cudza rezerwacja. Na tym opierają się transakcje ACID w relacyjnych bazach danych. Druga to reguła zapisana w samej bazie. W bazie danych PostgreSQL można zdefiniować tzw. ograniczenie wykluczające, które nie wpuści do tabeli dwóch rezerwacji tego samego pokoju w nakładających się terminach. Nawet jeśli w kodzie aplikacji pojawi się błąd, baza odrzuci drugi zapis. Przykład z oficjalnej dokumentacji PostgreSQL dotyczy zresztą właśnie rezerwacji sal. Próba zajęcia tej samej sali na godzinę, która zachodzi na istniejącą rezerwację, kończy się błędem. Dokładnie o to chodzi.

Trzecia to czasowa blokada terminu. Gdy gość przechodzi do płatności, system odkłada termin na kilkanaście minut, żeby nikt inny go nie kupił. Jeśli płatność w tym czasie nie dotrze, termin wraca do sprzedaży. Długość blokady to decyzja biznesowa. Zbyt długa blokuje sprzedaż w szczycie. Zbyt krótka sprawia, że płatność przychodzi już po zwolnieniu terminu, więc system musi umieć to obsłużyć, np. automatycznie zwracając pieniądze.

Czwarta to idempotencja, czyli gwarancja, że powtórzenie tej samej operacji nie wywoła drugiego skutku. Gość, który przy słabym zasięgu dwa razy kliknie „zapłać”, powinien dostać jedną rezerwację i jedno obciążenie karty. Bramki płatnicze takie jak Stripe obsługują to przez tzw. klucze idempotencji, ale system rezerwacji musi z nich korzystać. Takich błędów nie widać przy ręcznym klikaniu, bo jedna osoba nie zasymuluje stu jednoczesnych rezerwacji. Robią to testy obciążeniowe aplikacji, które wysyłają do systemu setki równoległych żądań o ten sam pokój i sprawdzają, czy w bazie powstała dokładnie jedna rezerwacja.

Kontrolowany overbooking w systemach rezerwacyjnych - kiedy ma sens

Lotnictwo pokazuje, że celowy overbooking da się prowadzić przy bardzo małym ryzyku dla klienta. Według raportu amerykańskiego Departamentu Transportu w czwartym kwartale 2024 roku dziesięciu amerykańskich przewoźników objętych raportowaniem odmówiło wejścia na pokład wbrew woli pasażera 0,25 osoby na 10 tys. Za tym wynikiem stoją lata danych o frekwencji, modele prognostyczne i procedura, w której najpierw szuka się ochotników gotowych polecieć później za rekompensatę.

Hotel, który chce robić to samo, potrzebuje podobnych składników w mniejszej skali:

• historii anulacji i niestawień w podziale na kanał, sezon i rodzaj stawki, bo bezzwrotna rezerwacja zrobiona z wyprzedzeniem zachowuje się zupełnie inaczej niż darmowo anulowana rezerwacja z portalu,
• twardego limitu, np. jeden lub dwa pokoje ponad stan tylko w wybranym typie pokoju i tylko na daty z wysoką prognozą anulacji,
• procedury relokacji ustalonej z wyprzedzeniem, z listą obiektów partnerskich i budżetem,
• zapisu każdej decyzji, żeby po sezonie dało się sprawdzić, czy nadwyżka się opłaciła.

Technologia ma tu rolę pomocniczą. System liczy prognozę, pilnuje limitu i ostrzega, gdy nadwyżka przestaje się bilansować. Decyzję, czy w ogóle dopuszczać overbooking, podejmuje człowiek, najlepiej ten, który odpowiada za wynik finansowy obiektu.

Są też sytuacje, w których kontrolowany overbooking nie ma sensu:

• obiekt z unikalnymi zasobami, np. apartamenty różniące się lokalizacją i układem, gdzie sprzedanego lokalu nie ma czym zastąpić,
• pojedyncze zasoby, jak jedna sala konferencyjna, konkretny specjalista w gabinecie albo numerowane miejsce na wydarzeniu,
• sprzedaż głównie przez kanały, które karzą gospodarza za anulację, bo kara szybko zjada zysk z dodatkowej sprzedaży,
• brak danych historycznych, bo prognoza zbudowana na kilku miesiącach to zgadywanie z kalkulatorem,
• przewaga rezerwacji bezzwrotnych i przedpłaconych, przy których niestawień jest niewiele.

W gabinetach, salonach i usługach umawianych na godzinę lepszym rozwiązaniem niż zapisywanie dwóch osób na jeden termin bywa ograniczenie pustych terminów. Pomagają w tym przypomnienia SMS i łatwe odwoływanie wizyt, dostępne np. w oprogramowaniu dla SPA i studiów wellness.

Czego technologia nie załatwi

Najlepszy silnik rezerwacji nie pomoże, jeśli recepcjonistka w piątkowy wieczór zapisze gościa z telefonu w zeszycie, bo „system się wiesza”. Część podwójnych rezerwacji ma przyczynę organizacyjną. Brakuje zasady, że każda rezerwacja powstaje w jednym miejscu, uprawnień do blokowania terminów dla handlowców albo osoby odpowiedzialnej za konfigurację kanałów. Te sprawy trzeba ustalić równolegle z wdrożeniem, inaczej nowe narzędzie powieli stare nawyki.

Druga granica to kanały, na które nie ma się wpływu. Jeśli mały portal regionalny obsługuje tylko iCal, okno kilku godzin zostanie. Da się je zmniejszyć, np. zamykając w takich kanałach ostatni wolny pokój danego typu i zostawiając go w sprzedaży tylko tam, gdzie synchronizacja działa przez API. To kosztuje trochę sprzedaży, ale zamyka najbardziej ryzykowną lukę.

Trzecia granica jest ekonomiczna. Właściciel trzech apartamentów, któremu podwójna rezerwacja zdarzyła się raz, nie potrzebuje dedykowanego systemu. Wystarczy mu gotowy channel manager z synchronizacją przez API i dyscyplina przy ręcznych wpisach. Większość takich przypadków rozwiązuje oprogramowanie do zarządzania najmem krótkoterminowym dostępne w abonamencie.

Własne rozwiązanie zaczyna się opłacać w innych warunkach, a decyduje o tym głównie to, co się sprzedaje i jakimi kanałami. Nietypowe zasoby, jak sale, sprzęt czy powierzchnie magazynowe, słabo mieszczą się w gotowych systemach hotelowych. Tak było w przypadku platformy do wynajmu magazynów i kontenerów, w której rezerwacja, umowa i płatność działają w jednym procesie. Podobnie jest, gdy firma ma własny zespół sprzedaży, nietypowe zasady cenowe albo musi połączyć rezerwacje z ERP i księgowością. Wtedy dostępność trzeba liczyć według własnych reguł, a gotowe narzędzie staje się ograniczeniem.