Systemy rezerwacyjne i channel manager od strony technicznej, algorytmicznej

0

Cześć!

Czy ktoś z Was ma doświadczenie w tworzeniu systemów wymienionych w temacie? Wiem, że silnik rezerwacji na stronie www to jedno, a channel manager spinający dostępność z kilku kanałów sprzedaży hotelu (strona www, PMS, serwisy OTA) to drugie. Bardziej chodzi mi o stosowane rozwiązania, by dostępność była aktualizowana jak najszybciej, by uniknąć overbookingów. Szczególnie interesujące w przypadku większych graczy, przykładowo kilkaset pokoi o podobnym (tym samym) standardzie. Robimy promocję i nagle jesteśmy zasypywani wieloma rezerwacjami niemalże w tym samym czasie.

Inna sytuacja - dzwoni gość, hotel ma ostatni wolny pokój, recepcjonista zaczyna wpisywać rezerwację i bach! Nie skończył, a ktoś w tym samym czasie zrobił rezerwację przez zewnętrzny serwis OTA (np. booking.com).

Nie wiem czy to dobry dział, bo zapewne ma to związek z webmasteringiem, ale pewnie chodzi również o rozwiązania algorytmiczne i sprzętowe.

2

System rezerwacji się wydaje trudny ale jest to proste.

  1. w momencie startu blokada danego dnia/godziny/pokoju
  2. jeśli blokada zakończona sukcesem to wykonanie wszelkich operacji w tranzakcji

Przy rejestracji z biura blokada powinna następować w momencie otwarcia formularza z konkretnego dnia.

1

Inna sytuacja - dzwoni gość, hotel ma ostatni wolny pokój, recepcjonista zaczyna wpisywać rezerwację i bach! Nie skończył, a ktoś w tym samym czasie zrobił rezerwację przez zewnętrzny serwis OTA (np. booking.com).

To jedyny problem z wymienionych przez Ciebie z jakim się spotkałem. Wszystko zależy od koncepcji. W systemie nad którym pracuję są 2 główne rozwiązania.

  1. Klient tworzy rezerwację na zasadzie kto pierwszy, ten lepszy. Jeśli w trakcie robienia rezerwacji, ktoś go uprzedzi i zarezerwuje ten zasób szybciej, to klient otrzymuje informacje, że ten zasób nie jest dostępny. Jednocześnie otrzymuje sugestię, że może go zastąpić innym, który aktualnie jest wolny i posiada podobne parametry. Dodatkowo cena zasobu nie jest blokowana. Tzn. jeśli np. cena się zwiększy pomiędzy rozpoczęciem rezerwacji, a zakończeniem, klient otrzymuje informację, iż cena zasobu się zwiększyła / zmniejszyła. Jest to dość częsta sytuacja, gdy cena zasobu jest ustalana bardzo dynamicznie.
  2. Klient tworząc rezerwację, blokuje zasób na pewien okres. W momencie tworzenia rezerwacji, zakładana jest blokada na dany zasób i jego ewentualne elementy składowe na określony czas, np. 15 minut. Klient wtedy ma pewnośc, że rozpoczęta rezerwacja zostanie przez niego ukończona. Dodatkowo cena może także zostać ustalona taka, jaka była w momencie rozpoczynania rezerwacji, nawet gdy zmieniła się w jej trakcie.

Akurat w systemie nad którym pracuję, rozpoczynaliśmy od koncepcji nr 2, ale obecnie jesteśmy na koncepcji nr 1. Głównie dlatego, że gdy zaczynaliśmy zasobów mieliśmy mało, a klientów dość sporo. Wobec czego sytuacja, gdy ktoś kogoś uprzedził mogła być dość często i należało uchronić klientów przed taką sytuacją. To jednak wiązało się z pewnym skomplikowaniem procesu rezerwacji od strony technicznej i rozwoju systemu. W momencie, gdy doszliśmy do etapu dość znacznej liczby zasobów, sytuacja, że ktoś kogoś uprzedzi realnie nie występuje. Problemem jednak rozwiązania z blokadą jest fakt, że np. konkurencja może Ci wejść na stronę, rozpocząć proces rezerwacji wszystkich zasobów, niczego nie zakończy, a Tobie zlikwidują całą, dostępną ofertę.
Kiedyś taki tryb miało lokalne kino w mojej miejscowości. Miejsc na sali jest generalnie niewiele, a jeden rząd jest najlepszy. Jak wiedziałem, że chcę się wybrać do kina, ale jeszcze nie wiedziałem ile osób ze mną pójdzie, to rozpoczynałem proces rezerwacji dla 8 miejsc, blokując je dla innych, aż znajomi się nie zdecydowali w ciągu kilku h, kto na pewno pójdzie. Wtedy płaciłem za tyle miejsc ile chciałem i zwalniałem blokadę. Teoretycznie mógłbym z łatwością zablokować całe kino, aż do rozpoczęcia seansu, bo system nie był zbyt dobrze przemyślany pod tym kątem.

W moim systemie w praktyce niekiedy łączymy te dwa rozwiązania w trybie składania złożonej oferty (koszyk). Jeśli ktoś buduje ofertę złożoną z kilku zasobów, to generalnie obowiązuje punkt 1, aż do momentu dodania zasobu do koszyka. Wtedy na czas kompletowania zamówienia, zasób dodany do koszyka znika na określony czas z puli ogólnej oraz blokuje się jego cena. Finalne zamówienie jest składane na bazie danych zapisanych w koszyku.

1 użytkowników online, w tym zalogowanych: 0, gości: 1