Kluczową zmianą będzie zmiana narzędzia do „wyszukiwania rabatów korporacyjnych” w „asystenta decyzyjnego – aktywnie rezerwującego podróż służbową”
Zamiast:
- formularz → wyniki → filtr → wybór
będzie:
- „lecę jutro do Monachium, budżet 1200 PLN, preferuję LH” → AI załatwia całość
AI:
- interpretuje politykę firmy,
- wybiera lot, hotel, payment,
- dba o compliance + duty of care.
AI przestaje być narzędziem, a staje się operatorem procesu.
Kontekst zamiast surowych danych
LLM-y łączą:
- historię podróży,
- kalendarz,
- cele biznesowe,
- preferencje (np. „nie tanie linie rano”).
To rozwiązuje dzisiejszy problem:
systemy wiedzą co zostało zarezerwowane, ale nie wiedzą dlaczego.
Automatyzacja operacji
Już dziś AI:
- automatyzuje booking i approval flow,
- obsługuje zapytania przez chatboty,
- porównuje ceny i optymalizuje decyzje.
W przyszłości:
- AI będzie robić reshoping automatycznie (price drop → rebook)
- będzie reagować na disruption (cancel flight → rebook + notify klienta)
2. Jak LLM-y będą używane przez TMC
TMC nie znikną — zmienią rolę z „operatora bookingów” na warstwę orkiestracyjną i kontrolną.
Redukcja pracy operacyjnej
AI:
- automatyzuje powtarzalne taski
- zmniejsza workload agentów
Konsultanci ds podróży służbowych zajmą się:
- complex travel,
- VIP,
- disruption handling.
„AI-powered TMC stack”
Nowa architektura TMC:
-
Warstwa danych
- GDS + NDC + hotel APIs + internal contracts
-
Warstwa agregacji
- normalizacja contentu (najtrudniejszy element)
-
Warstwa AI
- ranking ofert
- compliance check
- rekomendacje
-
Interfejs
Personalizacja i compliance jednocześnie
AI pozwala pogodzić coś, co dziś jest konfliktem:
- traveler experience vs policy
AI:
- proponuje „najlepszą opcję zgodną z polityką”
- tłumaczy użytkownikowi wybory (Explainable AI)
Proaktywna obsługa
AI:
- daje alerty o ryzyku podróży
- wspiera duty-of-care w czasie rzeczywistym
3. Dlaczego idealny Self Booking Tool NIE istnieje (i to nie przez UX)
AI nie stworzy „idelanego systemu rezerwacji z dostępem do wszystkich taryf i wszystkich hoteli”. Jest to święty gral branży podróży służbowych.
DLACZEGO?
Problem 1: fragmentacja contentu (największy blocker)
Loty:
- część taryf w GDS
- część tylko w NDC
- część tylko na stronie linii
niektóre taryfy lotnicze są dostępne wyłącznie w jednym kanale.
Corporate Booking Tool często nie widzi najtańszych opcji:
- user widzi lepsze ceny na stronie airline
system musi agregować wiele źródeł jednocześnie
Hotele:
- GDS
- OTAs
- wholesalerzy
- direct connect
- corporate negotiated rates
dane są:
- rozproszone,
- niespójne,
- często ze sprzecznymi cenami
Problem 2: brak standaryzacji danych
- GDS → EDIFACT (legacy)
- NDC → XML/API
- hotel APIs → każdy inny
ogromny koszt normalizacji i utrzymania
💸 Problem 3: interesy rynku (to ważniejsze niż technologia)
Dostawcy celowo fragmentują dystrybucję:
Linie lotnicze:
- chcą unikać opłat GDS
- chcą kontrolować klienta
- oferują lepsze ceny direct lub w NDC
Hotele:
- różne ceny per kanał (pricing strategy)
- kontrakty corporate nie są publiczne
nie ma biznesowego interesu w „pełnej transparentności”
Problem 4: integracja i operacje
Aby zrobić „idealny Self Booking Tool dla podróży służbowych” musisz:
- połączyć 5–10 różnych źródeł danych.
- utrzymać spójność cen i bookingów w systemie.
- zapewnić:
- ticketing
- changes
- refunds
Problem 5: „plan vs book gap”
AI:
- obecnie dobrze planuje podróż
- słabo „zamyka booking”
Podsumowanie (kluczowa teza)
LLM-y zmienią UX (chat zamiast formularza);
Przejmą decision-making;
Zautomatyzują operacje
ALE nie rozwiążą same problemu inventory i dostępu do wszystkich oraz najlepszych cen. Bo problem to fragmentacja rynku, brak wspólnych standardów oraz sprzeczne interesy dostawców.
„Idealny Self Booking Tool dla firmy” to nie problem AI. To problem: dystrybucji i kontroli danych w globalnym rynku podróży służbowych.
