Dynamic packaging w branży travel - technologia stojąca za spersonalizowanymi pakietami
Dynamic packaging pozwala składać pakiet z lotu, hotelu, transferu i dodatków w chwili, gdy klient go szuka. Rozkładamy taki system na warstwy i pokazujemy, co dzieje się w każdej z nich, od API dostawców po rezerwację i obsługę zmian.
Klient wpisuje „Lizbona, 12-17 maja, dwie osoby” i po dwóch sekundach widzi kilkanaście gotowych propozycji: lot z Warszawy, hotel w Alfamie, transfer z lotniska. Każda z jedną ceną. Żadnej z nich rano jeszcze nie było, bo nikt jej wcześniej nie zaplanował. Tak działa dynamic packaging w branży travel, czyli technologia stojąca za spersonalizowanymi pakietami. Zamiast katalogu gotowych wycieczek z rezerwacją miejsc w samolocie na cały sezon system składa pakiet z dostępnych w tej chwili usług różnych dostawców. Dla klienta to wygoda. Dla biura podróży oznacza to zupełnie inny rodzaj oprogramowania niż klasyczny katalog.
Taki system łatwiej zrozumieć, rozkładając go na warstwy. Każda z nich rozwiązuje osobny problem, a większość kłopotów we wdrożeniach bierze się z tego, że któraś warstwa została potraktowana zbyt lekko. Poniżej idziemy od dołu do góry.
Dynamic packaging, czyli pakiet składany w chwili wyszukiwania
Klasyczny touroperator kupuje miejsca w samolotach czarterowych i pokoje w hotelach z wyprzedzeniem, w blokach. Potem sprzedaje gotowe pakiety z katalogu. Ryzyko niesprzedanych miejsc leży po jego stronie, ale oferta jest prosta i przewidywalna. W modelu dynamicznym biuro niczego nie kupuje z góry. Wyszukiwarka pyta dostawców o aktualną dostępność i ceny, łączy wyniki w propozycje i dolicza marżę. Klient może sam wybrać lotnisko wylotu, długość pobytu i standard hotelu, a biuro sprzedaje kierunki, których nigdy nie miałoby w katalogu.
Z punktu widzenia technologii to przejście od bazy danych z ofertami do systemu, który przy każdym wyszukiwaniu rozmawia z kilkoma lub kilkunastoma zewnętrznymi systemami. Te rozmowy są wolne, drogie i zawodne. Cała reszta architektury istnieje po to, żeby klient tego nie zauważył.
Większość biur korzysta z obu modeli naraz. Czartery z katalogu dla najpopularniejszych kierunków, pakiety dynamiczne dla reszty. System musi wtedy pokazywać jedne i drugie w jednej wyszukiwarce.
Typowy system dynamic packaging łączy się z kilkoma grupami dostawców:
loty: systemy rezerwacyjne GDS, takie jak Amadeus czy Sabre, połączenia bezpośrednie z liniami przez standard NDC oraz API linii niskokosztowych,
noclegi: hurtownie hotelowe, tak zwane bedbanki, które oferują setki tysięcy obiektów przez jedno API, oraz bezpośrednie połączenia z wybranymi hotelami,
transfery, wynajem samochodów i atrakcje na miejscu,
ubezpieczenia podróżne dodawane do pakietu.
Każde z tych połączeń to osobny projekt. Dostawcy różnią się formatem danych, sposobem opisu pokoi, zasadami anulacji, limitami zapytań i procesem certyfikacji, który potrafi trwać tygodnie. Dlatego architektura zwykle ma warstwę pośrednią, która tłumaczy każdego dostawcę na jeden wspólny format. Dodanie nowego hotelu czy linii lotniczej nie wymaga wtedy zmian w całym systemie. To klasyczny problem integracji wielu systemów w jednym środowisku, tylko w wersji, w której dostawcy nie są własnością firmy i mogą zmienić swoje API z kilkutygodniowym wyprzedzeniem.
Zapytanie do API linii lotniczej trwa od kilkuset milisekund do kilku sekund. Hotelowe podobnie. Gdyby przy każdym wyszukiwaniu pytać wszystkich dostawców o wszystkie kombinacje, klient czekałby kilkadziesiąt sekund. Do tego dochodzą koszty. Dostawcy pilnują proporcji między liczbą zapytań a liczbą rezerwacji, nazywanej look-to-book. Biuro, które wysyła tysiące zapytań na jedną sprzedaż, płaci dodatkowo albo dostaje ograniczenia.
Rozwiązaniem jest pamięć podręczna, czyli cache: system przechowuje niedawne wyniki i pokazuje je klientowi od razu, a świeże dane pobiera tylko tam, gdzie to konieczne. Do tego zwykle służy Redis, baza danych działająca w pamięci. Ceny lotów starzeją się szybciej niż ceny hoteli, więc każdy typ danych ma inny czas ważności. Wyszukiwanie po kierunkach, standardach, udogodnieniach czy odległości od plaży obsługuje silnik wyszukiwania, na przykład Elasticsearch. Opisy hoteli, zdjęcia i lokalizacje zmieniają się rzadko, więc trzyma się je we własnej bazie i aktualizuje w tle.
Ceną za szybkość jest to, że wynik z cache może być nieaktualny. Dlatego przed rezerwacją system zawsze sprawdza cenę i dostępność u dostawcy jeszcze raz. Jeśli się zmieniły, klient musi to zobaczyć przed płatnością, a nie po niej.
Warstwa 3: silnik łączenia
Mając loty i hotele, system musi z nich zbudować sensowne pakiety. To trudniejsze, niż się wydaje.
Lot przylatuje o 23:40, a hotel ma recepcję czynną do 22:00. Powrót jest o 6:10 rano, a transfer z hotelu trwa godzinę. Lot jest z bagażem tylko podręcznym, a pakiet sprzedawany jako dwutygodniowe wakacje rodzinne. Silnik łączenia odrzuca takie kombinacje albo oznacza je dla klienta, zanim ten trafi na nie w praktyce. Reguły łączenia ustala biuro: które lotniska obsługują dany kierunek, jakie transfery są dostępne, czy do hotelu w danym standardzie dodawać ubezpieczenie. Dobrze zaprojektowany silnik pozwala zmieniać te reguły z panelu, a nie zamawiać zmian u programistów przed każdym sezonem.
Liczba możliwych kombinacji szybko rośnie. Dwadzieścia lotów i trzysta hoteli to sześć tysięcy pakietów dla jednego zapytania. Silnik musi je zawęzić, posortować i pokazać kilkadziesiąt najlepszych, zanim klient straci cierpliwość.
Cena pakietu to suma cen składników plus marża, ale w praktyce rzadko jest to prosta suma. Biuro często ma ceny hotelowe nieprzeznaczone do sprzedaży osobno, które może pokazać tylko w pakiecie, bez rozbijania na składniki. To jedna z głównych przewag pakietów dynamicznych nad rezerwowaniem wszystkiego osobno. Marża może zależeć od kierunku, terminu, kanału sprzedaży i obłożenia. W okresach dużego popytu biuro zarabia więcej na pakiecie, w słabszych schodzi z marży, żeby utrzymać sprzedaż. To podejście znane z hotelarstwa jako revenue management, czyli zarządzanie ceną w zależności od popytu, przeniesione na pakiety.
Do tego dochodzą waluty. Hotel w Tajlandii rozlicza się w bahtach, linia lotnicza w euro, a klient płaci w złotych. System musi przeliczać kursy, pilnować różnic kursowych między wyszukiwaniem a rozliczeniem z dostawcą i pokazać klientowi jedną, stałą cenę.
Warstwa 5: personalizacja
Na tej warstwie pakiet przestaje być tylko tani, a zaczyna być trafny. System, który wie, że klient dwa razy jechał z dziećmi do hoteli z aquaparkiem i zawsze wylatuje z Katowic, może pokazać mu najpierw właśnie takie propozycje.
Personalizacja opiera się na danych: historii rezerwacji, wyszukiwań i kliknięć. Modele uczenia maszynowego uczą się na nich, które pakiety mają największą szansę na sprzedaż dla danego klienta, i zmieniają kolejność wyników. Prostsze rozwiązania korzystają z reguł, na przykład osobnego zestawu propozycji dla rodzin i dla par. Coraz częściej pojawia się też wyszukiwanie w języku naturalnym. Klient pisze „ciepło, plaża, lot do czterech godzin, budżet 6 tys. na dwie osoby w czerwcu”, a chatbot AI zamienia to na zapytanie do wyszukiwarki i proponuje kilka pakietów. Działa to dobrze tylko wtedy, gdy warstwy niżej są szybkie i mają aktualne dane.
Warstwa 6: rezerwacja i wszystko, co dzieje się później
Klient klika „Rezerwuję” i płaci. System musi teraz zarezerwować lot u jednego dostawcy, hotel u drugiego i transfer u trzeciego. Jeśli lot i hotel się udadzą, a transfer nie, pakietu nie da się sprzedać w takiej postaci. Dlatego rezerwacja pakietu to sekwencja kroków z planem wycofania. System rezerwuje najpierw składniki, które najtrudniej odzyskać, zwykle lot, potem resztę. Gdy któryś krok się nie powiedzie, anuluje wcześniejsze albo proponuje klientowi zamiennik. Takie operacje obsługuje się asynchronicznie, przez kolejkę zadań, na przykład RabbitMQ, żeby awaria jednego dostawcy nie blokowała całej sprzedaży.
Podobne zasady dotyczą dostępności. Biuro, które sprzedaje także własne miejsca, musi pilnować, żeby ostatniego pokoju nie sprzedać dwa razy, co dobrze pokazuje problem overbookingu w systemach rezerwacyjnych. Po rezerwacji zaczyna się obsługa: zmiany godzin lotów, które linie wprowadzają tygodnie przed wylotem, prośby o zmianę terminu, anulacje, reklamacje. Każda zmiana w jednym składniku może wpływać na pozostałe. Przesunięty lot oznacza inny transfer i czasem dodatkową noc w hotelu.
W Unii Europejskiej dynamicznie złożony pakiet jest z punktu widzenia prawa imprezą turystyczną, więc biuro odpowiada przed klientem za całość, także za usługi dostawców. W praktyce oznacza to, że system musi mieć pełną historię każdej rezerwacji i zmian, a zespół obsługi musi widzieć cały pakiet, a nie pięć osobnych rezerwacji.
Budować czy korzystać z gotowej platformy
Na rynku są gotowe silniki dynamic packaging, udostępniane w modelu abonamentowym lub od transakcji. Mają już połączenia z dużymi dostawcami, wyszukiwarkę i podstawowe reguły. Dla biura, które chce szybko zacząć sprzedawać pakiety, to rozsądny punkt startu.
Własny system ma sens, gdy biuro chce się wyróżnić czymś, czego gotowe platformy nie robią: własnymi regułami łączenia, nietypowymi produktami, personalizacją czy zintegrowanym systemem rezerwacyjnym dla własnych obiektów. Często najlepszy jest model pośredni: gotowe połączenia z dostawcami i własna warstwa wyszukiwania, ceny i sprzedaży. Własny silnik budujemy jako zestaw usług wokół wspólnego modelu danych. Interfejs sprzedażowy powstaje w Next.js, który dobrze radzi sobie z SEO stron kierunków i hoteli. Usługi integracyjne i silnik łączenia działają w Node.js z NestJS, dane o rezerwacjach przechowuje PostgreSQL, a płatności obsługuje bramka taka jak Stripe. Całość uruchamiana jest w kontenerach Docker, co ułatwia skalowanie w szczycie sezonu.
Czas zależy przede wszystkim od liczby dostawców. Pierwsza wersja z jednym dostawcą lotów, jednym bedbankiem, wyszukiwarką i rezerwacją to zwykle od czterech do sześciu miesięcy pracy kilkuosobowego zespołu. Każdy kolejny dostawca to od kilku tygodni do dwóch miesięcy, licząc certyfikację. Pełna platforma z personalizacją, panelem reguł i obsługą zmian to projekt na rok lub dłużej.
Najlepiej zacząć od jednego kierunku albo jednej grupy klientów i sprawdzić, jak pakiety dynamiczne sprzedają się obok katalogu. Dane z pierwszych miesięcy powiedzą więcej niż jakakolwiek analiza.
FAQ - Najczęściej zadawane pytania o dynamic packaging
Tak, małe biuro podróży może sprzedawać pakiety dynamiczne, najczęściej korzystając z gotowej platformy zamiast budować własny system. Takie platformy mają już połączenia z dostawcami lotów i hurtowniami hotelowymi, a biuro płaci abonament lub prowizję od sprzedaży i dostosowuje wygląd wyszukiwarki do swojej marki. Pozwala to zacząć sprzedaż w ciągu kilku tygodni, bez wielomiesięcznego projektu. Własny system ma sens dopiero wtedy, gdy biuro chce się wyróżnić nietypowymi produktami lub regułami, których platformy nie obsługują. Wybór zależy od skali sprzedaży, liczby kierunków i tego, jak ważna jest dla biura kontrola nad doświadczeniem klienta.
Tak, pakiety dynamiczne mogą zawierać loty tanich linii, choć ich podłączenie bywa trudniejsze niż w przypadku linii tradycyjnych. Część przewoźników niskokosztowych udostępnia własne API dla pośredników, część jest dostępna przez agregatory lub systemy GDS, a niektóre ograniczają sprzedaż przez biura podróży. W praktyce biuro korzysta zwykle z dostawcy, który zbiera oferty kilku linii w jednym miejscu. Trzeba przy tym uważnie obsłużyć opłaty za bagaż i wybór miejsc, bo w tanich liniach to osobne usługi, które zmieniają końcową cenę pakietu. Zakres dostępnych linii zależy od wybranego dostawcy i rynku, na którym działa biuro.
Tak, dobrze zaprojektowany system łączy w jednej wyszukiwarce własne miejsca biura, na przykład w samolotach czarterowych lub hotelach z zakontraktowanymi pokojami, z ofertami pobieranymi na bieżąco od zewnętrznych dostawców. Własne zasoby zwykle mają pierwszeństwo w wynikach, bo biuro już za nie zapłaciło i musi je sprzedać. Wymaga to wspólnego modelu danych dla obu źródeł i pilnowania dostępności własnych miejsc, żeby nie sprzedać ich dwa razy. Połączenie obu modeli to częsty scenariusz w biurach, które mają katalog i chcą stopniowo rozszerzać ofertę o kierunki dynamiczne. Czas wdrożenia zależy od tego, w jakim systemie biuro prowadzi dziś swoje zasoby.
Tak, wyszukiwarkę można osadzić na obecnej stronie biura jako moduł lub zbudować na niej osobne podstrony z wynikami, bez przebudowy całego serwisu. Gotowe platformy oferują zwykle widżet wyszukiwarki i ścieżkę rezerwacji w barwach biura, a systemy budowane na zamówienie udostępniają API, z którego korzysta strona. Przy okazji warto zadbać o to, żeby strony kierunków i hoteli były widoczne w Google, bo wyniki generowane wyłącznie w przeglądarce trudno zaindeksować. Czas integracji zależy od technologii obecnej strony i zakresu zmian: prosty widżet to kilka dni, pełna integracja ze ścieżką zakupu i kontem klienta to kilka tygodni.
Tak, ten sam silnik może sprzedawać pakiety bezpośrednio klientom i przez sieć agentów, partnerów czy innych pośredników. Agenci dostają wtedy osobny panel z własnymi cenami, prowizjami i limitami, a partnerzy mogą korzystać z API lub wyszukiwarki pod własną marką. System musi rozróżniać kanały sprzedaży, bo marża i warunki często są w nich inne, a rozliczenia prowizji powinny powstawać automatycznie. Model B2B wymaga też dodatkowych funkcji, takich jak rezerwacje grupowe, płatności odroczone czy faktury dla firm. Zakres prac zależy od liczby kanałów i od tego, jak skomplikowany jest system prowizji.
Tak, system może przyjmować zaliczkę przy rezerwacji i resztę płatności w określonym terminie przed wyjazdem, choć wymaga to dopasowania do warunków poszczególnych dostawców. Linie lotnicze zwykle wymagają pełnej płatności przy wystawieniu biletu, a hotele często pozwalają na późniejsze rozliczenie, więc biuro musi zaplanować przepływy pieniędzy tak, żeby nie finansować dostawców z własnych środków. Harmonogram płatności system ustala automatycznie na podstawie składników pakietu i terminu wyjazdu. Możliwe są też raty przez zewnętrznych operatorów płatności. Szczegóły zależą od polityki finansowej biura i umów z dostawcami.
Tak, dobrze zaprojektowany system sprawdza aktualną cenę i dostępność u dostawców tuż przed płatnością i pokazuje klientowi każdą zmianę, zanim ten zapłaci. Jest to potrzebne, bo wyniki wyszukiwania często pochodzą z pamięci podręcznej i ceny lotów mogą się zmienić w ciągu kilku minut. Jeśli cena wzrosła, klient widzi nową kwotę i decyduje, czy kontynuować, a jeśli spadła, system może od razu pokazać korzystniejszą ofertę. Częstotliwość takich zmian zależy od kierunku i terminu: w szczycie sezonu zdarzają się częściej. Przejrzysta informacja na tym etapie zmniejsza liczbę porzuconych rezerwacji i reklamacji.
Współczesne przedsiębiorstwa korzystają z wielu systemów i aplikacji, które wspierają różne obszary działalności – od sprzedaży, przez logistykę, aż po obsługę klienta. Problem pojawia się wtedy, gdy te narzędzia nie są ze sobą zintegrowane, co prowadzi do chaosu informacyjnego, błędów i nieefektywności procesów. Enterprise Application Integration (EAI) jest rozwiązaniem, które pozwala połączyć rozproszone systemy w spójny ekosystem, zapewniając płynny przepływ danych i automatyzację…
W świecie najmu, gdzie popyt potrafi zmieniać się z miesiąca na miesiąc, a konkurencja reaguje szybciej niż kiedykolwiek, decyzje cenowe nie mogą być oparte wyłącznie na intuicji. Coraz więcej firm wdraża RMS, ale przy większej skali i złożonych procesach gotowe narzędzia zaczynają ograniczać: brakuje integracji, elastycznych reguł i pełnego wykorzystania danych. Właśnie dlatego rośnie zainteresowanie dedykowanymi rozwiązaniami revenue management, budowanymi pod konkretny portfel i strategię.
Overbooking bywa świadomą strategią, ale znacznie częściej jest zwykłym błędem synchronizacji. Pokazujemy, gdzie system rezerwacyjny gubi informację o dostępności, ile kosztuje sprzedanie tego samego terminu dwa razy i które rozwiązania techniczne naprawdę temu zapobiegają.
Machine learning, to dziedzina informatyki skupiająca się na tworzeniu systemów, które potrafią uczyć się i dostosowywać do dostarczanych im danych. Jest to technologia bardzo ważna w dzisiejszym świecie, ponieważ pozwala na automatyzację procesów i zwiększenie efektywności w wielu dziedzinach, takich jak rozpoznawanie obrazów, analiza tekstu czy prognozowanie pogody.
System rezerwacyjny to dziś jedno z kluczowych narzędzi, które usprawnia pracę firm działających w modelu usługowym. Umożliwia klientom szybkie i wygodne umawianie wizyt online, a przedsiębiorcom pozwala automatyzować wiele procesów, które wcześniej wymagały ręcznej obsługi. Dzięki nowoczesnym rozwiązaniom rezerwacja terminu staje się prostsza, bardziej przejrzysta i dostępna o każdej porze.
Ceny w turystyce zmieniają się dziś szybciej niż kiedykolwiek, a za każdą z tych zmian stoi algorytm, który w tle analizuje setki zmiennych jednocześnie. Dynamic pricing oparty na sztucznej inteligencji przestał być przewagą największych graczy i stał się operacyjnym standardem branży, od linii lotniczych, przez sieci hotelowe, po touroperatorów i platformy OTA.
