GDS Nedir? Oteller ve Seyahat Acenteleri İçin Dağıtım Sistemi Rehberi

GDS, Global Distribution System ifadesinin kısaltmasıdır; Türkçede küresel dağıtım sistemi olarak kullanılır. Otel, havayolu ve benzeri seyahat sağlayıcılarıyla seyahat satan işletmeler arasında içerik, fiyat, uygunluk ve rezervasyon işlemlerini buluşturan bir dağıtım altyapısını anlatır. Bir otel açısından yeni satış noktalarına ulaşma, acente açısından farklı sağlayıcıların tekliflerini ortak çalışma ortamında değerlendirme işlevi taşıyabilir. Ancak bağlantı kurulması tek başına belirli sayıda rezervasyon geleceği anlamına gelmez.

Amadeus'un GDS açıklaması sağlayıcı ile seyahat satıcısı arasındaki aracılık işlevini, Travelport'un çalışma modeli ise arama, rezervasyon ve satış sonrası hizmet adımlarını açıklar. Bu rehber o temel ayrımdan hareketle otel ve acente yöneticilerinin soracağı iş sorularını düzenler. Sağlayıcıların güncel ürünleri, ticari koşulları ve hesap yetkileri ayrıca doğrulanmalıdır; tek bir bağlantı bütün içerik ve işlemlere aynı erişimi sağlamayabilir.

GDS ne yapar, hangi ihtiyacı karşılar?

Bir seyahat satıcısının farklı sağlayıcıların tekliflerini araştırması, uygun seçeneği bulması ve desteklenen rezervasyon işlemlerini yürütmesi gerekir. GDS bu süreçte ortak bir erişim ve işlem ortamı sağlayabilir. Otel ise envanterini, fiyatlarını ve koşullarını ilgili dağıtım yapısına doğru iletmek ister. Bu iki tarafın ihtiyacı birbirini tamamlar; fakat aynı değildir. Otel için oda ve fiyat doğruluğu, acente için erişilebilir içerik, rezervasyon akışı ve satış sonrası destek öne çıkabilir.

GDS'yi yalnız “otel listesinin bulunduğu ekran” gibi düşünmek eksik kalır. Önemli olan listelenen bilginin hangi kaynaktan geldiği, hangi koşulla satılabildiği ve işlemden sonra kaydın nasıl doğrulandığıdır. Aynı şekilde GDS'nin kendi başına bir fiziksel oda envanterinin sahibi olduğunu varsaymayın. Dağıtım, kaynak sistem ve ticari sağlayıcı ilişkisini ayırın. İncelediğiniz bağlantıda hangi kurumun hangi işlemi onayladığını öğrenmek, ekrandaki fiyatın nereden geldiğini bilmek kadar gereklidir.

GDS, OTA, PMS, CRS ve channel manager farkı

Bu tablo işlev ayrımıdır; bütün otellerde aynı sistem sırası bulunduğunu söylemez. Bazı işletmeler birden fazla işlevi tek ürün içinde kullanabilir, bazıları farklı sağlayıcıları bağlar. Bu yüzden zorunluymuş gibi tek bir PMS, channel manager, CRS ve GDS zinciri çizmek yerine mevcut bağlantı haritasını çıkarın. Her ok için hangi veri aktarıldığını, yönünü ve sorumlusunu yazın. Bir sağlayıcının kendi ürün ailesindeki bağlantı, başka ürünle veya başka hesapta aynı biçimde çalışmayabilir.

Rezervasyon motorunun görevini booking engine seçim rehberinde, otel sistemleri arasındaki bağlantıları yazılım entegrasyonu hizmetinde ayrıca inceleyebilirsiniz. Farklı araçları aynı isim altında değerlendirmek, satın alma sırasında eksik işlevleri görünmez kılabilir.

Otel için GDS bağlantısı ne zaman araştırılmalı?

Önce hedeflediğiniz misafir ve satış kanalını belirleyin. Kurumsal seyahat, belirli acente ilişkileri veya dağıtım temsilcisi üzerinden erişim gibi ihtiyaçlar varsa GDS bağlantısının rolü araştırılabilir. Ancak şehirde bulunmak ya da iş oteli olmak tek başına bağlantının sizin için uygun olduğunu kanıtlamaz. Mevcut talep, boş kalan tarihler, oda ürünleri ve hedef alıcılarla çalışma ihtiyacı birlikte değerlendirilmelidir. Bağlantıyı yalnız teknik bir kutucuk olarak tamamlamak, ticari satış planı hazırlamaktan farklıdır.

Hedef alıcıların hangi sistemi kullandığını ve otelinizi hangi koşulda satabileceğini öğrenin. İçeriğiniz doğru, fiyat planlarınız anlaşılır ve rezervasyon süreciniz yönetilebilir olmalıdır. Eğer temel oda eşleştirmeleri veya iptal koşulları henüz tutarlı değilse önce bunları düzeltmek gerekebilir. GDS incelemesinin sonunda bağlantı kurmaya karar verebileceğiniz gibi, mevcut web veya acente satış akışını iyileştirmeyi daha öncelikli de bulabilirsiniz. Karar, bağlantının adıyla değil işletmenizde tamamlayacağı belirli satış işiyle gerekçelendirilmelidir.

Seyahat acentesi açısından kullanım soruları

Acente, hangi seyahat ürünlerini araştırıp satacağını ve hangi satış sonrası işlemleri yapacağını netleştirmelidir. Otel, uçuş veya araç içeriğinin bulunmasıyla bütün ürünlerin aynı ticari koşulda rezervasyona açılması farklıdır. Kullanılan terminal, API, içerik paketi ve hesap yetkisi incelenmelidir. Operasyon ekibinin değişiklik, iptal ve destek işlemlerini nerede tamamlayacağı sorulmalıdır. Sadece ilk fiyat aramasını gösteren bir demo, acentenin satış sonrası sorumluluklarını değerlendirmek için yeterli olmaz.

Mevcut CRM'iniz ve dosya takibiniz de bu değerlendirmeye dahildir. GDS'de oluşan rezervasyonun müşteri kartına ve teklif geçmişine nasıl bağlanacağını sorun. Aynı bilgiyi başka programa yeniden yazmanız gerekiyorsa hangi alanların taşınacağı ve hatanın nasıl kontrol edileceği belli olsun. Müşterinin seçtiği alternatif, kaynak rezervasyon numarası, ödeme bilgisi ve belge birbirine doğru bağlanmalıdır. GDS erişimi edinmek, müşteri ilişkileri yönetimini veya kurum içi iş listesini kendiliğinden kurmaz; bunlar ayrı ihtiyaçlar olarak planlanabilir.

Acente tarafındaki seçim sorularını seyahat acentesi yazılımı rehberiyle birlikte ele alın. Bağlantı biçimini anlamak için de turizm XML entegrasyonu rehberindeki katalog, fiyat, rezervasyon ve satış sonrası işlem ayrımını kullanın.

Oda, fiyat planı ve koşullar dağıtımın temelidir

Bir otel ürününün doğru satılabilmesi için oda tipinin, yatak düzeninin, kapasitenin, yemek planının ve fiyat koşulunun anlaşılır olması gerekir. Aynı oda farklı kanallarda farklı adlarla sunuluyorsa eşleştirme tablosu hazırlayın. Fiyatı karşılaştırırken yalnız rakama bakmayın; tarih, kişi sayısı, vergi, ödeme zamanı ve iptal koşulu aynı mı kontrol edin. İş seyahatindeki bir alıcı için esneklik veya çalışma alanı önemli olabilir; bu bilgiyi karşılamayan ucuz fiyat, ihtiyaçla uyumlu teklif anlamına gelmeyebilir.

Kapalı fiyat veya kurumsal anlaşma gibi planların kimlere sunulacağını da açıkça tanımlayın. Bir fiyatın sisteme yüklenmesi, bütün kullanıcılar tarafından aynı biçimde görüntüleneceği anlamına gelmez. Erişim ve ürün kuralı sağlayıcıyla doğrulanmalıdır. Açıklamalar farklı sistemlere taşınırken kesiliyor veya farklı anlam kazanıyorsa bu da kabul sırasında incelenmelidir. Satış temsilcisinin önüne gelen son görünümü görmek, yalnız otelinizin kaynak panelindeki doğru ayarı göstermekten daha kapsamlı bir kontroldür.

Müsaitlik, fiyat ve içerik güncellemeleri aynı akış olmayabilir

Oda açıklaması, fiyat ve satılabilir envanter farklı sıklıklarla ve farklı bağlantılarla güncellenebilir. Bir içerik değişikliğinin hemen görünmesi, son oda satışının da aynı hızla bütün kanallara yansıdığını kanıtlamaz. Her veri türü için kaynak sistem, aktarım yöntemi ve hata halinde yapılacak işlem tanımlanmalıdır. Bağlantı haritasındaki “senkronize” etiketi yerine son başarılı aktarım ve kontrol bilgilerini izlemek daha açıklayıcıdır. Özellikle satış kapatma, minimum konaklama ve kişi kurallarını ayrı deneyin.

Kesinti sırasında operasyonun hangi paneli esas alacağı belli olmalıdır. Aynı oda iki yerde farklı görünüyorsa çalışanların tahminle en avantajlı sonucu seçmesi yerine uzlaştırma süreci bulunmalıdır. Kaynak kaydı, son aktarımı ve karşı taraftaki kabul sonucunu karşılaştırın. Bir mesajın gönderilmiş olması veya yerel takvimde rengin değişmesi nihai durumun doğrulandığını göstermez. Bu nedenle GDS projesinin kabulü yalnız bağlantı açılışına değil, değişiklik ve hata örneklerinin izlenmesine de dayanmalıdır.

Rezervasyon, referans ve satış sonrası hizmet

İlk aramadan sonra hangi işlemin rezervasyonu oluşturduğunu, onayın hangi sistemden döndüğünü ve hangi referansların saklanacağını yazın. Yerel teklif numarası, GDS işlem kaydı ve otelin kaynak onayı aynı kimlik olmak zorunda değildir. Operasyonun destek talebi açarken doğru numaraya ulaşması gerekir. Müşteri için hazırlanan belge de kabul edilmiş ürün ve koşulları esas almalıdır. Dosyaya bir PDF eklenmesi, eksik sağlayıcı onayını tamamlamaz veya belirsiz işlemi kesin rezervasyona dönüştürmez.

Değişiklik ve iptal akışlarını ilk rezervasyon kadar dikkatle deneyin. Bir tarihin değişmesi yeni fiyat veya farklı koşul doğurabilir; desteklenen işlem sırası sağlayıcıya göre değişebilir. Bağlantı yalnız bazı adımları destekliyorsa kalan işin nerede ve kim tarafından yürütüleceği belli olsun. Yanıt alınamayan durumda aynı işlemi yeniden göndermeden önce kaynak durumun nasıl sorgulanacağını öğrenin. Özellikle farklı satıcılardan geçen bir dosyada ilk destek muhatabının kim olduğu, hizmet kalitesini doğrudan etkileyen bir kapsam sorusudur.

Belge ve onayın ayrımı için otel voucher ve konfirme rehberini, satış sonrası durumların rapora etkisi için otellerde no-show yönetimini inceleyebilirsiniz. Bir kaydın değişmesi, ödeme ve envanter dahil bütün bağlı işlemlerin aynı anda tamamlandığı anlamına gelmez.

Maliyet değerlendirmesinde hangi kalemler sorulmalı?

GDS için herkesin ödeyeceği tek bir sabit maliyet varsaymayın. Kullanılan sağlayıcı, temsilci, ürün, bağlantı ve ticari sözleşme farklı kalemler içerebilir. Kurulum, kullanım, işlem, komisyon, temsil, içerik yönetimi ve destek başlıklarının hangilerinin geçerli olduğunu açıklatın. Bir kalemin ilgili üründe bulunmaması mümkündür; amaç bütün bedelleri zorunlu göstermek değil, farklı tekliflerin aynı kapsam üzerinden karşılaştırılmasını sağlamaktır. Toplam değerlendirmeye işletmenin içerik ve operasyon emeğini de dahil edin.

Varsayımsal bir kanalda yüksek brüt rezervasyon tutarı görülmesi tek başına daha fazla katkı sağlandığını göstermez. Gerçekleşen konaklama, iptal, no-show, kanal maliyeti ve operasyon yükü birlikte okunmalıdır. Yeni kanaldan gelen satışların daha önce başka kanaldan gelecek satışların yerini alıp almadığı da araştırılabilir; bunu tek bir rapordan kesin olarak çıkarmayın. Karşılaştırmada aynı konaklama dönemi, oda ürünü ve koşulları kullanın. Kanalı açmanın amacı, yalnız rapora yeni bir satır eklemek değil, belirlenmiş ticari ihtiyacı değerlendirmektir.

Bu karşılaştırmanın genel çerçevesi OTA ve direkt kanal maliyet karşılaştırmasında bulunur. Oradaki yöntem GDS'ye otomatik aynı maliyetleri atamak için değil, kanal bazında hangi kalemlerin gerçekten geçerli olduğunu sormak için kullanılmalıdır.

Kurumsal fiyat ve acente ilişkisi ayrı çalışma gerektirir

Belirli bir kurum veya seyahat yönetimi şirketine yönelik fiyat çalışması yapıyorsanız kapsamı teknik bağlantıdan ayırın. Hangi tarihler, oda tipleri, müsaitlik kuralları ve hizmetlerin konuşulduğu yazılı olmalıdır. Fiyat planının ilgili alıcı tarafından görülebildiğini ve beklenen koşulla rezervasyon yapılabildiğini test edin. Sadece genel listede görünmekle belirli bir anlaşmanın doğru tanımlandığını kabul etmeyin. Ticari tarafın onayladığı koşulla teknik tarafta tanımlanan ürünün aynı olduğunu iki tarafın birlikte kontrol etmesi yararlıdır.

Otel içeriğinin alıcının karar sorularını yanıtlaması da önemlidir. Konum, ulaşım, çalışma alanı, internet, toplantı alanı veya ödeme koşulu gibi bilgiler hedef müşteriye göre öncelik kazanabilir. Bu özellikleri desteklenmeyen bir sertifika veya ölçülmemiş performans vaadine dönüştürmeyin. Güncel fotoğraf ve doğru açıklama, dağıtım sisteminde de ürünün anlaşılmasına katkı sağlayan içerik çalışmalarıdır. Hangi alanların hangi sistemde görüntülenebildiği sağlayıcı tarafından doğrulanmalı; web sitenizdeki bütün içeriğin aynen taşındığı varsayılmamalıdır.

Bağlantı öncesi hazırlık dosyası

• Tesis ve oda kimlikleri, ürün adları, kapasite, yatak ve pansiyon eşleştirmesi.
• Fiyat planları, hangi alıcılara sunulacağı ve koşulların onay sahibi.
• PMS, CRS, channel manager ve rezervasyon motorunu gösteren mevcut veri akışı haritası.
• Rezervasyon, değişiklik, iptal ve belirsiz yanıt için operasyon sorumluları.
• Güncel tesis açıklaması, gerçek fotoğraflar ve içerik güncelleme sorumlusu.
• Ticari maliyet kalemleri, sağlayıcı desteği, veri çıkışı ve bağlantı sonlandırma soruları.

Hazırlık dosyasını yalnız teknik personele bırakmayın. Satış ekibi hedef alıcıları ve fiyat planlarını, operasyon oda ve rezervasyon durumlarını, finans maliyet takibini, web ekibi ise açıklama ve görselleri kontrol etmelidir. Farklı ekiplerin aynı odanın adını farklı kullanması gibi basit görünen sorunlar bağlantı sırasında daha görünür hale gelebilir. Önceden kararlaştırılmış veri sahibi, hata olduğunda kimin doğru kaydı sağlayacağını da belirler. Projenin takvimi bu hazırlık bağımlılıkları tamamlanmadan kesinmiş gibi sunulmamalıdır.

Varsayımsal pilot: bir oda tipi ve iki fiyat planı

Bir şehir otelinin tek oda tipi ve iki fiyat planıyla sınırlı pilot başlattığını düşünelim. Birinci plan genel satış, ikinci plan belirli alıcı koşuluna bağlı olsun. Önce her planın açıklaması ve görünürlüğü doğrulanır. Ardından aynı tarih ve kişi sayısı için kaynak fiyat, satıcı ekranındaki fiyat ve rezervasyon sonrası onay karşılaştırılır. Planlardan birinin yanlış alıcıya açılması veya iptal koşulunun eksik görünmesi, fiyat rakamı aynı olsa bile açık kabul konusu olarak kaydedilir.

İkinci turda minimum konaklama, satış kapatma ve değişen müsaitlik örnekleri denenir. Bir rezervasyon oluşturulduğunda kaydın doğru oda tipine ve fiyat planına bağlandığına bakılır. Sonra desteklenen değişiklik veya iptal adımı test edilir. Her adımda işlem zamanı, kaynak referansı ve beklenen sonuç tutulur. Gerçek envanter veya ödeme etkisi olan testler operasyonla önceden planlanmalıdır. Pilotun kısıtlı olması bütün işlemlerin güvenli veya etkisiz olduğu anlamına gelmez; test koşulları sağlayıcıyla açıkça belirlenir.

Son turda teknik aksama incelenir. Fiyat alınamayan, işlem yanıtı belirsiz kalan veya envanter güncellemesi kabul edilmeyen örneklerde ekranın ve iş listesinin ne gösterdiğine bakılır. Hata halinde bütün fiyatları eski kayıtla göstermeye devam etmek veya işlemi sessizce başarısız saymak gibi davranışlar özellikle sorgulanır. Satış temsilcisinin hangi kaynağa dönmesi gerektiği ve müşteriye hangi aşamada kesin bilgi verebileceği yazılı hale getirilir. Kabul, yalnız normal satışın başarıyla tamamlanmasına dayanmaz.

Canlıya geçiş sonrası hangi göstergeler izlenmeli?

Örnek uyuşmazlık: kaynakta açık, satıcı ekranında kapalı

Pilot sırasında otelin kaynak panelinde bir oda açık görünürken acente ekranında sonuç çıkmadığını düşünelim. İlk adım, iki ekrandaki tarih, kişi sayısı, oda ürünü ve fiyat planının aynı olduğunu doğrulamaktır. Ardından ilgili alıcının planı görme yetkisi, minimum konaklama ve satış kapatma gibi kurallar incelenir. Yalnız “sistem senkronize olmuyor” demek sorunun hangi katmanda olduğunu açıklamaz. Aynı koşulları taşıyan sorgu ve kaynak kaydı birlikte saklanırsa sağlayıcıya daha somut bir inceleme dosyası iletilebilir.

Kurallar doğruysa aktarımın hangi aşamada kaldığı araştırılır. Kaynak güncelleme üretmiş mi, aradaki sağlayıcı mesajı almış mı, karşı tarafta kabul sonucu var mı? Her proje bu ayrıntıları kullanıcı ekranında sunmayabilir; ancak destek ekibinin hangi kanıtı sağlayacağını önceden bilmek yararlıdır. Belirsizliği kapatmak için fiyatı veya oda eşleştirmesini rastgele değiştirmeyin. Böyle bir düzeltme ilk sorunu gizleyip başka alıcılarda yeni farklar doğurabilir. Önce aynı sorgunun hangi veri ve kuralla farklılaştığını bulun.

Sorun çözüldükten sonra yalnız aynı ekranı yenileyip sonucu görmekle yetinmeyin. Etkilenen oda ve fiyat planını, bağlı diğer planları ve sonraki güncellemeyi de belirlenmiş örneklerle kontrol edin. Düzeltmenin kapsamını ve değiştirilen ayarı kaydedin. Eğer mesele kullanıcı yetkisiyse bütün envanter akışının bozuk olduğu söylenmemelidir; mesele veri eşleştirmesiyse yalnız hesabın yeniden açılması yeterli kabul edilmemelidir. Bu ayrım, sonraki bir uyuşmazlıkta ekibin geçmiş denemeleri tekrar etmek yerine doğru başlangıç noktasına dönmesini sağlar.

Arama veya görüntülenme, oluşturulan rezervasyon, gerçekleşen konaklama, değişiklik, iptal ve manuel müdahale farklı göstergelerdir. Hepsini tek başarı oranında birleştirmeden önce tanımlarını sabitleyin. Bir dönemde rezervasyon sayısı artarken ortalama değer veya gerçekleşme oranı değişmiş olabilir. Hedef alıcıya erişim, talebin geldiği tarihler ve operasyon yükü de değerlendirilmelidir. Veri alınamayan alanı sıfır kabul etmeyin; raporda hangi göstergenin hangi sistemden ve hangi kapsamda geldiğini açıklayın.

İlk dönemde günlük kayıt mutabakatı, daha sonra işletmenin işlem hacmine göre belirlenen düzenli kontrol kullanılabilir. Kaynak ve yerel sistem arasındaki farkları yaşına ve nedenine göre listeleyin. Yinelenen kayıt, eksik referans, yanlış plan ve gecikmeli güncelleme aynı sorun değildir. Tek bir toplamı eşitlemek için dosya değiştirmek yerine farkın nedenini araştırın. Destek taleplerinde işlem kimliği ve maskelenmiş örnek paylaşmak, gereksiz kişisel veri dolaştırmadan daha açıklayıcı bir inceleme başlangıcı sağlar.

GDS ile NDC aynı şey mi?

Hayır. IATA'nın NDC açıklaması, havayolu teklif ve sipariş süreçleri için bir veri değişim standardını anlatır. GDS ise dağıtım platformunu ifade eder. Travelport'un güncel ürün açıklaması, kendi platformunda geleneksel içerikle NDC içeriğinin birlikte bulunabildiğini belirtir. Buradan bütün hesapların aynı içeriğe eriştiği veya otel bağlantısının NDC üzerinden kurulduğu sonucu çıkarılmamalıdır.

Teklif görüşmesinde bu kısaltmalar geçiyorsa işlev karşılığını isteyin. Hangi ürün aranıyor, hangi sağlayıcıdan geliyor, kim rezervasyon oluşturuyor ve satış sonrasında hangi işlem yapılabiliyor? Standart adı veya API sözcüğü, ticari erişim ve destek kapsamını kendiliğinden açıklamaz. Otel odaklı bir projede havayolu standardının adını duymak ayrıca bir yetenek kanıtı değildir. Her özelliği kendi kullanım senaryonuzla ilişkilendirin; gerekli olmayan bir bağlantıyı yalnız güncel teknoloji başlığı olduğu için önceliklendirmeyin.

GDS bağlantısının çözmeyeceği konular

GDS, kötü tanımlanmış oda ürününü, eksik fotoğrafı, yanlış fiyat planını veya takipsiz müşteri iletişimini tek başına düzeltmez. Web sitenizin hızını artırmak, Google'daki organik görünürlüğü geliştirmek ve satış fırsatlarını düzenli takip etmek ayrı çalışmalardır. Aynı şekilde sisteme bağlanmak satış ekibinizin otomatik olarak yeni alıcı ilişkileri kurduğu anlamına gelmez. Bağlantıyı ticari planın bir parçası olarak değerlendirin; bütün dijital pazarlama ve operasyon ihtiyacının yerine koymayın. Her çalışmanın hedefi ve ölçüm kaynağı ayrı bulunmalıdır.

Otelin dağıtımını planlarken otel pazarlama planındaki tarih ve kanal hedefleriyle başlayabilirsiniz. Google tarafındaki fiyat görünürlüğü ise Hotel Ads ve metasearch başlığıdır; GDS bağlantısıyla aynı ürün veya aynı reklam faaliyeti değildir. Bu ayrım, teklif kapsamını doğru karşılaştırmak için önemlidir.

Hotel Dijital ile kapsamı nasıl değerlendirebilirsiniz?

Görüşmeye mevcut sistem adlarını, oda ve fiyat planlarını, hedef satış kanallarını ve yaşanan somut veri sorunlarını hazırlayarak gelin. Önce bağlantı ihtiyacı ile içerik, web veya süreç ihtiyacını ayıralım. Otel yazılım entegrasyonunda sağlayıcı uygunluğu, oda ve fiyat eşleştirmesi, aktarım ve rezervasyon testleri değerlendirilir. Belirli bir GDS'ye hazır erişim, sözleşme veya sağlayıcı yetkisi inceleme yapılmadan vaat edilmez. Kullanılabilir kapsam, ilgili ürün ve hesabın teknik ve ticari koşullarına bağlıdır.

Tivona ürün ailesi de bu ayrımla değerlendirilmelidir. Acente CRM'i veya otel satış takip programı adından evrensel GDS bağlantısı, PMS, online ödeme veya otomatik müşteri mesajı özelliği çıkarılmaz. Tur satan ekibin dosya ve teklif ihtiyacıyla otelin dağıtım ihtiyacı farklı olabilir. Önce gerçek kullanım senaryosunu ve veri kaynağını belirlemek, sonrasında uygun hizmet veya ürün kapsamını konuşmak daha somut bir başlangıç sağlar.

Kaynaklar ve uygulama notu

Kaynaklar: Amadeus GDS sözlüğü, Travelport çalışma modeli, Travelport sık sorulan sorular ve IATA NDC. Erişim: 28 Ekim 2026. Hazırlık dosyası ve pilot örneği Hotel Dijital'in editoryal önerileridir; sağlayıcı kabul dokümanı değildir. İşletmenizin ihtiyaçlarını değerlendirmek için keşif görüşmesi talep edebilirsiniz.