Jak nie mieć podwójnych rezerwacji w pensjonacie i agroturystyce

Podwójna rezerwacja to nie awaria systemu - to statystyka. Jeśli sprzedajesz przez 2+ kanały i nie masz dyscypliny synchronizacji, to nie pytanie "czy", tylko "kiedy" i "ile pieniędzy będzie to kosztować".

Ten artykuł rozkłada problem na czynniki pierwsze i pokazuje trzy poziomy obrony - od kosztu zerowego (czysta dyscyplina) po pełną automatyzację. Zaczniesz od poziomu 1, ale prawdopodobnie skończysz na 3.

Skąd się biorą podwójne rezerwacje

Cztery główne źródła. W tej kolejności występowania:

1. Opóźnienie synchronizacji między OTA. Booking importuje kalendarze co 1-3 godziny, Airbnb co 2-4 godziny. W tym oknie dwóch gości może zarezerwować ten sam pokój zanim systemy się dowiedzą o sobie nawzajem. To 70-80% przypadków w obiektach, które już używają iCal-a.
2. Brak synchronizacji między OTA. Klasyczne: Booking podpięty do Twojego systemu rezerwacji, Airbnb też podpięty - ale ani Booking nie patrzy na Airbnb, ani Airbnb na Booking. Wystarczy, że gość rezerwuje przez Booking i system nie zdąży zablokować pokoju w Airbnb - kolizja.
3. Ręczne dodanie rezerwacji bezpośredniej do panelu, ale nie do OTA. Telefoniczna rezerwacja, którą operator wpisał do swojego Excela / Notion / kalendarza Google, ale zapomniał zablokować w Booking i Airbnb. Częste w obiektach na 2-5 pokoi.
4. Wygaśnięcie tokenu iCal lub awaria po stronie OTA. Booking.com przestaje odświeżać Twój kalendarz Airbnb (token wygasł), a Ty się o tym nie dowiadujesz. Po dwóch tygodniach przychodzi konflikt. Bez monitoringu trudne do wykrycia.

Poziom 1 - czysta dyscyplina (koszt: 0 zł)

Działa do ~10 rezerwacji miesięcznie i 2 kanałów.

Trzy zasady:

• Jedno źródło prawdy. Wybierz jedno miejsce, w którym podejmujesz decyzje o dostępności. Może to być panel Booking.com (jeśli ma najwięcej ruchu), arkusz Google Calendar dedykowany temu obiektowi, albo dowolny kalendarz w telefonie. Każda zmiana - rezerwacja telefoniczna, blokada na własną rodzinę, kuratela - wpada najpierw tutaj.
• Czas ręcznej propagacji ≤ 30 minut. Po wpisaniu zmiany w master, idziesz do każdego OTA i blokujesz tam te same daty. Ze stoperem. Powyżej 30 minut zmiana jest już niesynchroniczna i ryzyko rośnie.
• Codzienny audyt. Pierwsze co rano: porównujesz master z każdym OTA. Jeśli rozjazd - szukasz przyczyny przed otwarciem rezerwacji.

To brzmi banalnie i jest banalne. Wymaga jednak 10-20 minut dziennie i nie skaluje się powyżej 2 OTA + 5 pokoi. Powyżej tej granicy się zawsze sypie.

Poziom 2 - iCal między OTA (koszt: 0 zł)

Działa do ~30 rezerwacji miesięcznie i 4 kanałów.

iCal to publiczny standard wymiany kalendarzy. Każdy główny OTA - Booking.com, Airbnb, Slowhop, AlohaCamp - pozwala na bezpłatny eksport i import iCal.

Architektura: gwiazda, nie siatka.

• Master: Twój system rezerwacji (Beddesk, KWHotel, Smoobu) lub jeden z OTA jako tymczasowy master.
• Slaves: pozostałe OTA, które słuchają mastera i ewentualnie zwracają mu swoje nowe rezerwacje.

Każdy pokój ma jeden adres eksportu (z mastera) i N adresów importu (z każdego OTA, który może przynieść rezerwację). Dlaczego nie spinasz Booking → Airbnb bezpośrednio? Bo każdy nowy kanał wymagałby ręcznych spięć ze wszystkimi pozostałymi - liczba połączeń rośnie kwadratowo. Pełen przewodnik konfiguracji w osobnym artykule.

Synchronizacja Booking.com + Airbnb przez iCal - kompletny przewodnikKrok po kroku, ze screenshotami z paneli Booking.com i Airbnb. Plus pułapki, które najczęściej omijają początkujący.

Słabość iCal: opóźnienie 2-4 godziny po stronie OTA. W tym oknie podwójna rezerwacja jest możliwa. Standardowe rozwiązanie - overbooking buffer: blokujesz w każdym OTA dzień po końcu i dzień przed początkiem każdej rezerwacji. Cena: tracisz ~10% potencjalnych rezerwacji typu "weekend exact-fit". Ale eliminujesz ~95% kolizji.

Poziom 3 - channel manager z API (koszt: od ok. 80 zł/m-c)

Powyżej 30 rezerwacji miesięcznie iCal przestaje wystarczać. Wtedy przechodzisz na channel managera z integracją API - narzędzia, które łączą się z Booking, Airbnb itd. nie przez publiczny iCal, tylko przez wewnętrzne API tych serwisów.

Różnice względem iCal:

• Synchronizacja w czasie rzeczywistym (sekundy, nie godziny).
• Synchronizacja cen - zmieniasz stawkę w jednym miejscu, propaguje się wszędzie.
• Synchronizacja dostępności na poziomie typu pokoju (overbookings przez OTA są niemożliwe).

Cena: od ok. 80 zł/miesiąc za proste rozwiązania na polskim rynku do 600+ zł za enterprise. Dla pensjonatu na 5-25 pokoi sensowny przedział to 99-249 zł/m-c - konkretne ceny dostawców zweryfikuj na ich stronach, plany się zmieniają.

Channel manager dla małego pensjonatu - czego naprawdę potrzebujeszCo odróżnia mały segment od enterprise. 3 czerwone flagi przy wyborze. Funkcje must-have vs nice-to-have.

Trzy warstwy obrony, których używa Beddesk

Niezależnie od tego, czy jesteś na poziomie 2 czy 3, dobry system rezerwacji ma wiele warstw wykrywania kolizji - bo każda z nich łapie inny typ błędu:

1. Walidacja w bazie danych. Zanim rezerwacja w ogóle zostanie zapisana, baza sprawdza, czy te daty nie nakładają się z istniejącą rezerwacją w tym samym pokoju. Jeśli tak - odrzuca operację. To pierwsza i najtwardsza obrona, działa nawet w przypadku race condition (dwóch operatorów klika "zapisz" w tej samej milisekundzie).
2. Kontrola kolizji przy każdej akcji w UI. Zanim zobaczysz przycisk "zapisz rezerwację", system już wie, że pokoju nie ma. Mniej irytujące dla użytkownika, ale mniej twarde - można obejść w teorii.
3. Monitoring synchronizacji iCal. Jeśli któryś kanał przestaje odświeżać Twój kalendarz, dostajesz powiadomienie zanim przyjdzie kolejna rezerwacja. To łapie najtrudniejsze przypadki - te, których pierwsze dwie warstwy nigdy nie zobaczą, bo problem jest po stronie zewnętrznej.

W praktyce: nawet jeśli Booking.com przyśle Ci kolizyjną rezerwację (bo iCal opóźnił się o 4 godziny), system odrzuci ją w bazie i wyśle Ci powiadomienie z opcjami. Ty ręcznie decydujesz: relocate? rekompensata? upgrade?

Co zrobić, gdy podwójna rezerwacja już nastąpiła

Realnie się zdarza. Trzy rzeczy:

1. Najpierw zadzwoń do gościa, którego "stracisz" - zanim Booking lub Airbnb ich poinformują z zimna. Twoja narracja jest dużo lepsza niż automatyczny komunikat platformy.
2. Zaproponuj konkretną alternatywę, nie ogólnik. "Mamy zarezerwowany pokój w X (właściwy adres, link, kontakt) + zwracamy 100% Twojej wpłaty + dorzucamy 200 zł vouchera u nas". Konkrety > przeprosiny.
3. Sprawdź swój system. Konflikt zawsze ma przyczynę. Wygasł token iCal? Ktoś dodał rezerwację bezpośrednią bez blokowania OTA? Channel manager spóźnił się 6h? Bez audytu, drugi konflikt to kwestia tygodni.

Beddesk: trzy warstwy obrony, monitoring, polski

Synchronizacja Booking.com / Airbnb / Slowhop / AlohaCamp przez iCal, walidacja w bazie + kontrola w UI + monitoring każdego kanału. Powiadomienie, gdy synchronizacja przestaje działać. Po polsku, w 5 minut do startu.

Dołącz do bety BeddeskZamknięta beta - bezpłatnie. Bez karty, bez zobowiązań.