Turizmde XML Entegrasyonu: Otel ve Tur Verileri Acente Sistemine Nasıl Bağlanır?

Turizmde XML entegrasyonu, otel veya tur tedarikçisinin ürün, fiyat, müsaitlik ve desteklenen rezervasyon işlemlerini acentenin kullandığı sistemle veri üzerinden ilişkilendiren bağlantıdır. Amaç, aynı bilgiyi farklı panellere tekrar yazma ihtiyacını azaltmak ve satış ekibinin güncel veriye ulaşmasını sağlamaktır. Bununla birlikte katalogda bir tur görmek, o tur için yer ayırabilmek veya rezervasyonu kesinleştirebilmek aynı özellik değildir. Başarılı bir proje önce bu sınırları açıkça tanımlar.

Bu rehber, tur veya otel satan acente yöneticileri, operasyon sorumluları ve yazılım teklifi değerlendiren ekipler için hazırlandı. Bir sağlayıcıya ait bağlantı şifresi, hazır kod veya bütün sistemlerde çalışan ortak bir uç nokta sunmuyor. Bunun yerine kapsam tablosu, örnek satış akışı, kabul senaryoları ve bakım soruları veriyor. Buradaki sayısal örnekler varsayımsaldır; kullanılan sağlayıcının dokümanı, sözleşmesi ve hesabınıza tanımladığı yetkiler uygulamadaki son kontrol kaynağıdır.

XML, API ve entegrasyon aynı şeyi mi anlatır?

XML bir veri işaretleme biçimidir. API, yazılımların hangi işlemleri ve hangi kurallarla birbirine açtığını tanımlar. Bir API XML kullanabileceği gibi JSON gibi başka bir biçim de kullanabilir. Bu nedenle sektörde kullanılan “XML bağlantısı” ifadesi, teknik olarak farklı yöntemlerle çalışan entegrasyonları kapsayabilir. XML'in yapısal niteliği için W3C XML standardına bakılabilir; rezervasyon yeteneği ise veri biçiminden değil sağlayıcının sunduğu işlemlerden anlaşılır.

Teklif görüşmesinde dosyanın uzantısından önce iş akışını sorun. Bağlantı yalnızca tur başlığını, görselini ve açıklamasını mı alıyor? Tarih seçilince canlı fiyat sorabiliyor mu? Çocuk yaşı ve oda dağılımını taşıyor mu? Satış kaydı tedarikçiye gönderiliyor mu, yoksa yalnız kendi panelinizde bir dosya mı açılıyor? Bu sorular yanıtlanmadan “entegrasyon tamam” ifadesi kapsamı belirsiz bırakır. Aynı sağlayıcının farklı paketleri veya müşteri hesapları bile farklı işlemlere izin verebilir.

Bağlantı kapsamını beş ayrı katmanda değerlendirin

Her satırın karşısına destekleniyor, manuel yürütülüyor, kapsam dışında veya doğrulama bekliyor seçeneklerinden birini yazın. Özellikle “yapılabilir” ile “mevcut hesabınızda çalışıyor” ifadelerini ayırın. İlk ifade teknik olasılığı, ikincisi kabul edilmiş bir işlevi anlatır. Proje dosyanızda bir sağlayıcı için rezervasyon satırı boşken başka bir sağlayıcının başarılı demosunu kanıt olarak kullanmayın. Kapsam tablosu, satış ekibinin hangi durumda müşteriye kesin yanıt verebileceğini de belirleyen günlük bir çalışma belgesidir.

Yerel dosya, opsiyon ve tedarikçi onayının farkını tur satışında opsiyon ve kontenjan takibi yazısında ayrıca ele alıyoruz. Entegrasyon projesini bu iş akışından bağımsız satın almak, bağlantı kurulsa bile ekibin aynı kelimeyle farklı durumları anlatmasına yol açabilir.

Katalog aktarımı neden tek başına satış altyapısı değildir?

Katalog; tur adı, destinasyon, program, otel tanımı, görsel ve benzeri açıklayıcı alanları içerebilir. Bunların bazıları sık değişmez, bazıları sezonla birlikte yenilenir. Bir hareketin satışa açık olması ise belirli tarih, kişi sayısı, oda tipi ve tedarikçi koşuluna bağlıdır. Katalog ekranında görünen başlangıç fiyatını bütün tarihlerin kesin fiyatı gibi sunmak, satış temsilcisini sonradan düzeltmek zorunda kalacağı bir teklif hazırlamaya yöneltebilir. Katalog verisini ürün tanıtımı olarak konumlandırın; satış anındaki sorgunun görevini ona yüklemeyin.

Ürün kimliğini de yalnız başlıkla eşleştirmeyin. İki farklı sağlayıcı aynı tur adını kullanabilir; benzer adlı iki otel farklı bölgelerde bulunabilir. Kaynak sağlayıcı, kaynak ürün kimliği, yerel kayıt ve son eşleşme tarihi birlikte tutulmalıdır. Görsellerin kullanım hakkı, açıklamaların dil sürümleri ve yayımdan kaldırılan ürünün davranışı da içerik akışına dahildir. Sağlayıcı katalogdan bir ürünü çıkardığında sitenizin bunu otomatik silmesi mi, satışa kapatması mı, editör kontrolüne göndermesi mi gerektiğini önceden kararlaştırın.

Fiyat sorgusunda tarih, kişi ve koşul birlikte taşınmalı

Bir tur veya otel fiyatı yalnız ürün kimliğinin sonucu değildir. Giriş ve çıkış tarihi, hareket, yetişkin sayısı, çocuk yaşları, oda dağılımı, pansiyon, para birimi ve iptal koşulu fiyatın anlamını değiştirir. Satış ekranı bu alanları taşımıyorsa, bağlantı teknik olarak yanıt verse bile istenen ürünü fiyatlamıyor olabilir. Özellikle tek yetişkin ve bir çocuk, iki oda, sezon geçişi ve minimum gece gibi örnekler için ayrı kabul senaryosu hazırlayın. Kaynakta olmayan alanı sessizce varsayılan değere çevirmek yerine eksik bilgiyi görünür kılın.

Örneğin aynı aile için iki yetişkin ve sekiz yaşında bir çocuk sorgulanırken kaynak yanıtının iki yetişkine ait olması kabul edilemez. Ekranda benzer bir toplam görmek bu farkı telafi etmez; konaklama kapasitesi ve misafirin alacağı hizmet değişmiştir. Ekip, aranan koşulu, dönen koşulu ve müşteriye gösterilen koşulu aynı satırda karşılaştırabilmelidir. Fiyatın kaynağı, sorgu zamanı ve geçerlilik bilgisi de teklifin yanında izlenmelidir. Bu bilgiler yoksa müşteriyle paylaşılan PDF'in hangi veriye dayandığını sonradan açıklamak zorlaşır.

Oda, çocuk yaşı ve sezon geçişi gibi hesap başlıkları için otel kontrat fiyatı hesaplama rehberini kullanabilirsiniz. Kontrat hesabı ile sağlayıcının canlı teklifini aynı sonuçmuş gibi birleştirmeyin; her ikisinin veri kaynağı ve uyguladığı koşullar farklı olabilir.

Arama, yeniden doğrulama ve rezervasyon onayı

Sağlayıcılar rezervasyon öncesindeki adımları farklı tasarlar. Örneğin Hotelbeds iş akışı, RECHECK ve BOOKABLE fiyat türlerini ayırır; RECHECK için CheckRate adımı gerekir. Booking.com Demand API sipariş akışı ise önizleme ile oluşturmayı ayrı işlemler olarak tanımlar. Bu örnekler ortak bir kopyalama şablonu değil, her bağlantının kendi akışına göre uygulanması gerektiğinin göstergesidir.

Kendi ekranınızda da bilgi talebi, teklif hazır, müşteri kabulü, sağlayıcıya gönderildi, onaylandı ve sonuç belirsiz gibi durumları ayırın. Müşterinin teklifi kabul etmesi, sağlayıcının o koşullarla rezervasyon kabul ettiği anlamına gelmez. Onay için hangi referansın gerektiğini ve bu referansın hangi sistemden geldiğini yazın. Tedarikçi işlem numarası, yerel dosya numarası ve ödeme işlem numarası ayrı alanlarda tutulmalıdır. Birini diğerinin yerine kullanmak operasyonun yanlış kaydı aramasına neden olabilir.

Yanıt gelmezse aynı işlemi hemen tekrar göndermeyin

Rezervasyon isteği gönderildikten sonra bağlantı kesilmesi iki farklı durumu gizleyebilir: istek sağlayıcıya hiç ulaşmamış olabilir veya rezervasyon oluşmuş fakat yanıt alınamamış olabilir. İkinci durumda kontrolsüz tekrar, çift rezervasyon riski yaratır. Uygulanacak sorgulama ve tekrar yöntemi sağlayıcının desteklediği işlem kimliği, durum sorgusu ve tekrar kurallarına bağlıdır. Ekip için “sonuç belirsiz” kuyruğu oluşturun; bu kuyruğu ne başarısız satış diye otomatik kapatın ne de kesin rezervasyon diye müşteriye bildirin.

Turizm XML entegrasyonu için örnek kabul dosyası

Aşağıdaki örnek, üç yetişkin ve bir çocuğun iki odada konaklayacağı varsayımsal bir taleptir. Teste başlamadan önce sağlayıcının izin verdiği ortamı, test hesabını ve varsa gerçek envanter etkisini belirleyin. Gerçek rezervasyon veya ödeme oluşturan denemeler operasyon tarafından planlanmalıdır. Başarılı kabul, yalnız HTTP yanıtını görmekle bitmez; kaynak sistemdeki durumun, yerel kaydın ve müşteriye sunulan belgenin aynı koşulları göstermesi gerekir. Her senaryoya sorumlu, beklenen sonuç ve kanıt alanı ekleyin.

• Birinci oda iki yetişkin, ikinci oda bir yetişkin ve bir çocuk olacak şekilde kişi dağılımını koruyun.
• Tarih veya çocuk yaşı değiştirildiğinde eski fiyatın yeni koşulda kesin fiyat olarak kalmadığını kontrol edin.
• Müsait olmayan üründe satışın durduğunu, benzer bir oda ya da başka tarihin sessizce seçilmediğini doğrulayın.
• Sağlayıcı zaman aşımında belirsiz işlem kuyruğunu ve durum sorgusuyla uzlaştırma adımını deneyin.
• Onaylı rezervasyonda kaynak referansı, toplam, para birimi ve iptal koşulunu yerel dosyayla karşılaştırın.
• Desteklenmeyen iptal veya değişiklikte ekibin doğru manuel iş listesine yönlendirildiğini kontrol edin.

Eski veri, önbellek ve bağlantı kesintisi nasıl ele alınmalı?

Varsayımsal olay: müşteri kabulünden sonra toplam değişirse

Bir acentenin, iki odalı aile talebi için pazartesi öğleden sonra teklif hazırladığını düşünelim. Müşteri salı sabahı kabul ediyor; satış temsilcisi aynı dosyayı yeniden açtığında sağlayıcının yeni toplamı daha yüksek. Burada önce iki sorgunun aynı koşulları taşıyıp taşımadığına bakılır. Tarih, kişi, çocuk yaşı, pansiyon ve iptal koşulu gerçekten aynıysa fark bir fiyat güncellemesi olabilir. Alanlardan biri değişmişse sorun yalnız fiyat hareketi değildir; karşılaştırılan iki ürünün kapsamı da değişmiştir.

Temsilci eski PDF'i değişmeden rezervasyona çevirmek yerine dosyada yeni sorgu zamanını ve yeni koşulları görünür kılar. Müşteriye hangi unsurun değiştiği açıklanır ve kabul yeniden alınır. Yerel yazılım önceki sürümü saklar; eski teklifi sanki hiç gönderilmemiş gibi silmek yerine yeni sürümle ilişkilendirir. Operasyonun kendi kopyasında eski tutar kaldıysa o kayıt da incelenir. Böylece satış, tahsilat ve tedarikçi onayı farklı tutarları esas alarak ilerlemez. Bu, belirli bir sağlayıcının hazır özelliği değil, önerilen kontrol akışıdır.

Müşteri yeni fiyatı kabul etmiyorsa ekip alternatif tarih, oda veya ürün arayabilir. Alternatif önerisi yeni bir seçimdir; eski rezervasyonun devamı sayılarak sessizce uygulanmamalıdır. Aile odasından standart odaya geçiş veya iade edilebilir üründen farklı koşullu ürüne geçiş, toplam benzer olsa bile müşterinin kararını etkiler. Dosyadaki değişiklik gerekçesi bu yüzden yalnız “fiyat düzeltildi” olmamalıdır. Hangi koşulun değiştiği, kim tarafından kontrol edildiği ve müşterinin hangi sürümü kabul ettiği izlenebilir kalmalıdır.

Proje sorumluluklarını örnek bir haftalık gündeme çevirin

Kurulum toplantısında satış, operasyon, finans, yazılım ve tedarikçi taraflarını aynı kapsam tablosunda buluşturun. Satış temsilcisi müşteri sorularını ve teklif alanlarını, operasyon hareket ve oda kurallarını, finans tahsilat ile kaynak maliyet ayrımını açıklar. Yazılım ekibi bunların veri karşılığını ve hata durumlarını belirler. Sağlayıcı ise gerçekten açılabilecek işlemleri doğrular. Beş tarafın aynı toplantıda olması her projede mümkün olmayabilir; önemli olan eksik yanıtın bir varsayımla kapanmaması ve sahibinin belli kalmasıdır.

Haftalık değerlendirmede tamamlanan ekran sayısı yerine kapanan belirsizlikleri okuyun. Örneğin oda eşleştirmeleri onaylandı mı, çocuklu konaklama testi geçti mi, belirsiz rezervasyon sorgusu denenebildi mi, iptal işleminin manuel sahibi belirlendi mi? Açık konular için beklenen belgeyi ve bir sonraki kontrol tarihini yazın. Bağlantı teknik olarak hazırken sağlayıcı yetkisi bekleniyorsa durumu doğru adlandırın. “Hazır” etiketi yerine, hangi adımın hangi bağımlılık nedeniyle kullanılamadığını anlatmak ekiplerin satış beklentisini daha sağlıklı yönetir.

İlk kabulden sonra eğitimde de aynı örnek dosyayı kullanın. Bir çalışan normal satışı, bir çalışan zaman aşımını, bir çalışan yanlış oda eşleşmesini çözsün. Her biri hangi kaynağı kontrol edeceğini ve müşteriye hangi aşamada ne söyleyebileceğini açıklasın. Eğitim yalnız butonların yerini göstermekle sınırlı kalırsa sorun anında ekip yine kişisel deneyimine döner. Sürecin çalışması, kritik bir dosyanın farklı bir vardiyada aynı kayıt ve aynı kurallarla devralınabilmesiyle daha somut biçimde değerlendirilir.

Her veri türü için tek bir yenileme süresi belirlemek genellikle yetersizdir. Otel açıklamasının güncellenme ihtiyacı ile son odanın müsaitliğinin kontrolü aynı değildir. Kaynak sistemin sunduğu veri türünü, geçerlilik koşulunu ve sorgu sınırlarını esas alın. Katalog aktarımının zamanı, son başarılı fiyat sorgusu ve son rezervasyon uzlaştırması ayrı izlenmelidir. Bir ürünün açıklaması güncelken fiyatı eski olabilir; yalnız genel bir “senkronize” etiketi bu ayrımı satış ekibinden gizler.

Kesinti sırasında hangi işlemlerin devam edebileceğini yazılı olarak kararlaştırın. Açıklayıcı içerik gösterilebilirken canlı fiyat veya kesin rezervasyon sözü durdurulabilir. Ekranda müşteri için anlaşılır bir sonraki adım bulunmalı: yeniden sorgula, temsilciye yönlendir veya talep oluştur. Teknik hata kodunu müşteriye taşımak yerine operasyonun kullanacağı ayrıntıyı kendi iş listesinde tutun. Eski fiyatı yeniymiş gibi göstermemek, sorunu müşteriyle fiyat anlaşmazlığına dönüşmeden yönetebilmek için temel bir kontrol önerisidir.

Sorgu başarısız olduğunda boş yanıt ile gerçekten sıfır müsaitlik sonucunu da ayırın. Bir otelde oda kalmaması satış verisidir; sağlayıcıya erişilememesi teknik durumdur. İkisine aynı “uygun otel bulunamadı” mesajını vermek hem müşteriyi yanıltır hem izleme raporunu bozar. Operasyon, hangi ürünlerde güncel yanıt alınamadığını görebilmeli ve sağlayıcıyla konuşurken ilgili sorgu kimliğine ulaşabilmelidir. Başarılı yeniden sorgudan sonra da daha önce müşteriye iletilen tekliflerin kendiliğinden güncellendiğini varsaymayın.

Veri eşleştirmesi ve günlük mutabakat

İlk katalog aktarımı doğru görünse bile zaman içinde yeni oda tipleri, farklı pansiyon adları, kapanan hareketler veya değişen ürün kodları oluşabilir. Bu yüzden eşleştirme tablosu bir defalık kurulum çıktısı olarak bırakılmamalıdır. Yeni veya tanınmayan kod geldiğinde sistemin hangi davranışı göstereceği belirlenmelidir. Açıklamasız bir varsayılan odaya aktarmak yerine kontrol kuyruğu kullanmak daha izlenebilir bir süreç sağlar. Hangi eşleştirmeyi kimin değiştirdiğini ve değişikliğin hangi kayıtlara etki ettiğini kaydedin.

Gün sonu mutabakatında yalnız rezervasyon adedini karşılaştırmayın. Aynı gün içinde oluşturulan, değiştirilen ve iptal edilen kayıtları ayrı kontrol edin; tarih, ürün, tutar, para birimi ve kaynak referansına bakın. Bir yerel dosya sağlayıcıdaki iki kayda bağlanmışsa toplam adetler tesadüfen eşleşebilir. Tersine, gecikmeli yanıt nedeniyle geçici fark oluşabilir. Farkların yaşını ve sorumlusunu gösteren bir liste, toplamı eşitlemek için kaydı elle değiştirmekten daha iyi bir inceleme başlangıcıdır.

Fiyat, maliyet, tahsilat ve belgeyi ayırın

Sağlayıcının döndürdüğü toplamın hangi kalemleri içerdiğini anlamadan komisyon veya satış fiyatı eklemeyin. Vergi, yerinde ödenecek bedel, indirim, iptal kesintisi ve döviz bilgisi farklı alanlarda gelebilir. Bir tutarın eksik olması onu sıfır kabul etmek için yeterli değildir. Her alan için kaynağı ve açıklamayı saklayın; hesapladığınız yerel ticari eklemeleri kaynak tutardan ayırın. Bu düzen, sonradan fiyat farkının sağlayıcıdan mı yoksa yerel teklif kuralından mı doğduğunu bulmayı kolaylaştırır.

Ödeme durumunu da rezervasyon durumundan bağımsız izleyin. Yerel dosya açılması tahsilat yapıldığı, tahsilat yapılması da sağlayıcı rezervasyonunun onaylandığı anlamına gelmez. Örneğin müşteri kapora göndermişken tedarikçi teyidi beklenebilir; bunun tersi de mümkündür. Bu iki eksende ayrı iş listeleri hazırlayın. Resmî belge, muhasebe ve ödeme yükümlülükleri işletmenizin sözleşmeleri ve uzman danışmanlarıyla değerlendirilmelidir; entegrasyon ekranındaki mali takip alanları tek başına bu işlevlerin tümünü yerine getirdiğini göstermez.

Belge akışını tasarlarken voucher ve konfirme arasındaki ayrımı, finans alanlarını düzenlerken tur dosyasında tahsilat ve maliyet takibini temel alın. Voucher üretimi, sağlayıcının rezervasyonu kabul ettiğine dair eksik kanıtı kendiliğinden tamamlamaz.

Erişim güvenliği ve kayıtların korunması

Bağlantı anahtarlarını çalışanların kişisel mesajlaşma gruplarında veya ortak tablolarında dolaştırmayın. Entegrasyon için hangi hesabın hangi işlemi yapabildiği, yetkinin sahibi ve değişiklik sorumlusu belli olsun. Test ve üretim erişimlerini ayırın; üretimde yalnız ihtiyaç duyulan işlemleri açın. Satış temsilcisinin görevi için gerekli olmayan teknik anahtarları görmesi genellikle gerekmez. Bir çalışan ayrıldığında yalnız panel erişimini değil, paylaşılmış bağlantı bilgilerini ve varsa ortak kullanıcı alışkanlığını da gözden geçirin.

OWASP API Security Top 10, nesne düzeyinde yetkilendirme ve sınırsız kaynak tüketimi gibi riskleri ayrı başlıklarda ele alır. Acente açısından pratik karşılığı, bir kullanıcının yalnız yetkili olduğu dosyaya ulaşabilmesi ve sorgu yükünün kontrol edilmesidir. Bunlar proje kabulüne eklenebilecek güvenlik sorularıdır; yalnız şifreli bağlantı kullanılması bütün güvenlik kapsamının tamamlandığını göstermez.

Destek kayıtları sorunu çözmeye yetecek bilgiyi taşımalı, gereksiz kişisel ve ödeme verisini çoğaltmamalıdır. Teknik ekibe iletilecek örnekte önce işlem zamanı, sağlayıcı, istek kimliği, hata sınıfı ve maskelenmiş dosya referansı kullanın. Pasaport, kart veya ayrıntılı yolcu bilgisinin hata ekranında ve günlük dosyalarında görünmesini normal kabul etmeyin. Saklama süresi, erişim ve silme düzenini kurumunuzun veri koruma politikasıyla birlikte belirleyin. Bu süreç, bağlantı çalışmaya başladıktan sonra hatırlanacak bir ek iş olmamalıdır.

Entegrasyon teklifinde toplam kapsamı nasıl karşılaştırırsınız?

Tek bir kurulum bedeli, iki teklifin eşdeğer olduğunu göstermez. Katalog, canlı sorgu, rezervasyon, değişiklik, iptal, ödeme, belge, veri taşıma, eğitim ve bakım satırlarını karşılaştırın. Sağlayıcı lisansı veya bağlantı kullanım bedelinin kiminle yapılacak sözleşmeye bağlı olduğunu açıklatın. Sorgu hacmi, yeni ürün eşleştirmesi ve sürüm değişikliğinde ek çalışma çıkıp çıkmayacağını sorun. Sabit bir sektör fiyatı varsaymak yerine kendi satış biçiminize göre aynı teslimat listesinden teklif alın.

Kabul ve destek sorumluluğunu da maliyet tablosunun yanına koyun. Sorun tedarikçi yanıtından kaynaklanıyorsa ilk incelemeyi kim yapacak? Teklifte adı geçen bağlantı mevcut hesabınızla denenmiş mi? Operasyonun sağlayıcı paneline dönmesi gerektiğinde eğitim veriliyor mu? Çıkışta hangi verileri hangi biçimde alabileceksiniz? Teknik geliştirme tamamlanırken bu sorular açık kalırsa kullanıcı ekip günlük işin gerektirdiği sorumlulukları kendi arasında tahmin etmek zorunda kalır.

Kontrollü başlangıç ve canlıya geçiş planı

Önce sınırlı ürün ve açıkça belirlenmiş ekiplerle başlayın. Başlangıç listesi, kolay çalışan örneklerin yanında zorlayıcı koşulları da içermelidir: çocuklu oda, birden çok oda, yaklaşan hareket, değişen fiyat ve belirsiz yanıt gibi. Yeni sistemden yapılan her işlemin hangi kaynaktan doğrulanacağını tanımlayın. Eski iş akışının ne zaman kapanacağı, devam eden opsiyonların nereye taşınacağı ve hangi kayıtların eski panelde izleneceği ayrıca kararlaştırılmalıdır. Aynı dosyayı iki ekip iki panelden bağımsız yönetmemelidir.

Yayın gününde sorumlu kişiler, sağlayıcı destek kanalı, durdurma koşulları ve geri dönüş yöntemi belli olsun. Geri dönüş, yalnız yeni arayüzü kapatmak değildir; gönderilmiş ama yanıtı belirsiz işlemler, yeni tahsilatlar ve değişen envanter uzlaştırılmalıdır. İlk günün sonunda başarılı işlem yüzdesinin yanında manuel müdahale nedenlerini okuyun. Bir bağlantı az hata veriyor görünse bile satış ekibi her dosyada fiyatı başka panelden kontrol ediyorsa hedeflenen çalışma biçimine henüz ulaşılmamış olabilir.

Hotel Dijital ve Tivona tarafında doğru kapsam

Tivona Acente CRM güncel ürün kapsamı; müşteri ve fırsat takibi, çok seçenekli PDF teklif, gruba özel program, rezervasyon dosyası ve mali takip başlıklarını içerir. API/XML tedarikçi bağlantıları sağlayıcı, sözleşme ve hesap yetkisine bağlıdır. Bir kurulumda bulunan bağlantı bütün yeni müşterilere hazır sunulan bir paket olarak değerlendirilmez. PDF veya paylaşım kaydı, otomatik WhatsApp gönderimi anlamına gelmez.

İhtiyacınız otel PMS'i, channel manager ve booking engine arasındaki akışsa otel yazılım entegrasyonu hizmetini inceleyin. Tur satan acentede yazılım seçimini acente yazılımı değerlendirme rehberiyle, dağıtım yapısını ise GDS rehberiyle birlikte ele alabilirsiniz. Görüşmeye mevcut sistemlerinizi, örnek teklifinizi ve destek beklediğiniz sağlayıcı listesini getirmeniz kapsamı somutlaştırır.

Kaynaklar ve uygulama notu

Teknik kaynaklar: W3C XML, Hotelbeds Booking API iş akışı, Booking.com Demand API sipariş oluşturma ve OWASP API güvenliği. Erişim: 28 Ekim 2026. Kabul listeleri ve varsayımsal örnekler Hotel Dijital'in editoryal önerileridir; sağlayıcı dokümanı yerine geçmez. Mevcut akışınızı değerlendirmek için keşif görüşmesi talep edebilirsiniz.