NDC povezivanje: zašto izravna integracija nije samo tehničko pitanje
Nedavno sam razgovarao s kolegom koji razmišlja o izravnim NDC integracijama za svoju turističku agenciju. Pitanje koje je postavio bilo je sasvim logično: zašto koristiti agregatora ili drugi distribucijski kanal ako se agencija može izravno povezati s aviokompanijom?
Na papiru takav pristup zvuči privlačno. Agencija dobiva veću kontrolu nad sadržajem, može izravno prikazivati brendirane tarife i dodatne usluge te nije potpuno ovisna o mogućnostima posredničke platforme.
Međutim, razgovor je brzo došao do važnijeg pitanja. Što se događa nakon što je karta prodana?
Može li agent jednostavno promijeniti datum? Može li automatizirano izračunati razliku u cijeni, napraviti djelomičan povrat ili dodati prtljagu? Kako se obrađuje promjena reda letenja? Što se događa s računovodstvenim podacima i plaćanjem?
Upravo na tim pitanjima postaje jasno da NDC integracija nije samo povezivanje s još jednim API-jem.
NDC nije jedan univerzalan API
IATA definira New Distribution Capability kao otvoreni standard za razmjenu podataka koji se temelji na upravljanju ponudama i narudžbama. Cilj je aviokompanijama omogućiti da kroz različite prodajne kanale nude bogatiji sadržaj, dodatne usluge i preciznije oblikovane proizvode.
Ipak, izraz „NDC standard” može stvoriti pogrešan dojam da sve aviokompanije koriste isto tehničko sučelje i iste poslovne procese.
U praksi istodobno postoje brojne generacije NDC shema. Osim toga, aviokompanije same odlučuju koje će funkcije implementirati. Dvije kompanije mogu koristiti istu verziju, ali imati potpuno različite procese za kupnju dodatnih usluga, promjenu rezervacije ili povrat novca.
Zato oznaka „NDC enabled” ne govori mnogo o stvarnom korisničkom iskustvu agenta. Veza može podržavati pretraživanje i rezervaciju, ali istodobno zahtijevati ručnu obradu gotovo svake složenije radnje nakon prodaje.
Od prodaje dodatnih usluga do upravljanja narudžbom
Verzija 17.2, objavljena 2017. godine, postala je prvi široko prihvaćen operativni temelj NDC-a. Jasnije je odvojila pretraživanje, provjeru i konačnu izradu rezervacije. Poboljšala je prikaz sjedala, prodaju dodatnih usluga te obradu promjena i otkazivanja.
Iako su poslije objavljene naprednije verzije, 17.2 i dalje je prisutna kod niza aviokompanija i tehnoloških pružatelja. Razlog nije nužno tehnološka zaostalost. Za mnoge prijevoznike ta verzija i dalje pokriva najveći dio komercijalnih potreba, dok bi prelazak zahtijevao promjene u većem broju povezanih sustava.
Generacije 18.x, 19.x i 20.x postupno su proširivale NDC prema strukturiranim pravilima tarifa, plaćanjima, obračunu i financijskom izvještavanju. Time je standard počeo izlaziti iz okvira same kupnje aviokarte.
Veći strukturni pomak stigao je s verzijama 21.x. Zajednički podatkovni elementi smanjili su dio nedosljednosti između ponuda i narudžbi, dok je funkcija OrderQuote omogućila da se prije potvrde promjene izračuna njezin financijski učinak. Verzija 21.3 postala je važna nova polazna točka za cjelovitije procese servisiranja i budući razvoj modela Offers and Orders.
Verzije 24.x dodatno su povezale stavke narudžbe, plaćanja, penale i preostalu vrijednost neiskorištenih usluga. To je važno za agencije jer omogućuje preciznije razumijevanje koliko putnik treba doplatiti ili koliko mu aviokompanija duguje nakon promjene.
Najnovija verzija nije uvijek najvažnija
IATA je 16. ožujka 2026. objavila paket standarda 26.1. Među važnijim novostima bili su plaćanje jedne stavke narudžbe s više načina plaćanja, simulacija naknada prije potvrde transakcije te detaljnija razmjena podataka o PDV-u, GST-u i drugim porezima na potrošnju.
Verzija 26.2 objavljena je 4. lipnja 2026., ali njezine su glavne promjene bile usmjerene na poruke povezane s prtljagom. To dobro pokazuje zašto veći broj verzije ne znači automatski i veliku promjenu za svaku turističku agenciju.
Za agenciju je važnije podržava li konkretna integracija njezine procese nego koristi li tehnički najnoviju shemu.
Izravna integracija donosi kontrolu, ali i obveze
Direktno povezivanje može imati smisla za agenciju koja ostvaruje velik promet s manjim brojem strateški važnih aviokompanija. Može biti opravdano i kada agencija razvija vlastitu platformu, želi oblikovati posebno korisničko iskustvo ili treba sadržaj koji nije jednako dostupan kroz druge kanale.
Međutim, svaka izravna veza zahtijeva razvoj, testiranje, nadzor i održavanje. Potrebno je obraditi različite formate odgovora, pogreške, metode autentifikacije, ograničenja broja upita i promjene verzija. Uz to dolaze plaćanja, povrati, poremećaji u prometu, usklađivanje financijskih podataka i podrška agentima.
Problem postaje još složeniji kada jedna aviokompanija koristi noviju shemu za pretraživanje i rezervaciju, a stariji proces za servisiranje. Takve hibridne implementacije nisu neuobičajene jer prijevoznicima omogućuju uvođenje novih funkcija bez potpune zamjene postojeće infrastrukture.
Agregator ili GDS ne uklanja tu kompleksnost. On je preuzima na sebe i pokušava različite integracije pretvoriti u ujednačeniji proces za agenciju. Zauzvrat, agencija može imati manje kontrole nad pojedinim funkcijama ili ovisiti o brzini kojom posrednik uvodi sadržaj određene aviokompanije.
Zato odluka nije jednostavan izbor između „izravno” i „preko posrednika”. Mnogim će agencijama najbolje odgovarati hibridan model: izravne veze s nekoliko najvažnijih prijevoznika, dok se ostali NDC i tradicionalni sadržaj preuzimaju kroz agregatora ili GDS.
Kolegi s početka priče na kraju nisam preporučio da prvo pita koju verziju NDC-a aviokompanija koristi. Korisnija su pitanja bila: koje procese možemo završiti od početka do kraja, koliko će nas koštati njihovo održavanje i što se događa kada putniku treba pomoć nakon kupnje?
Upravo se tada otkriva stvarna vrijednost NDC integracije. Ne u trenutku kada se ponuda prikaže na ekranu, nego kada rezervaciju treba promijeniti, servisirati i financijski zatvoriti bez ručnog rada i poziva korisničkoj podršci.
