Otel XML entegrasyonu nedir? Tur operatörü ve bedbank bağlantıları

Otel XML entegrasyonu, otelin sistemi ile bir tur operatörü ya da bedbank sistemi arasındaki otomatik veri alışverişidir: otel müsaitlik, fiyat ve kısıt bilgilerini gönderir, iş ortağı rezervasyonları geri gönderir. Otel, bu veriyi doğru tutmayı, bağlantıdan gelen rezervasyonları kabul etmeyi ve canlıya geçmeden önce eşleştirmeyi test etmeyi taahhüt eder.

E-posta, tur operatörünün XML ile bağlanacağını bildiriyor ve bilgilerinizi cuma gününe kadar istiyor. Odadaki kimse o bağlantıdan gerçekte ne geçeceğini ya da bir rezervasyon gelmediğinde sorumlunun kim olduğunu söyleyemiyor. Bu yazının sonunda her yönde ne taşındığını adıyla sayabilecek, iş ortağınıza push ve pull tartışmalarını bitiren soruları sorabilecek ve elle fiyat yüklemeyi ne zaman durdurmanın güvenli olduğuna karar verebileceksiniz.

Otel XML entegrasyonu nedir?#

Otel XML entegrasyonu, otelin rezervasyon sistemi ile iş ortağının sistemi arasındaki yapılandırılmış veri alışverişidir; hiçbir taraf diğerinin bilgisini yeniden yazmaz.

XML, veriyi etiketleyerek iki sistemin aynı alanı aynı şekilde okumasını sağlayan bir yöntemdir. Etiketten çok anlam üzerindeki mutabakat önemlidir: otel tarafındaki çift kişilik oda, iş ortağı tarafında da aynı çift kişilik oda olmalıdır. Giden yönde otel, tarih ve oda tipi bazında müsaitliği, fiyat planı bazında fiyatları ve minimum konaklama, belirli varış günlerine kapama, satış durdurma gibi kısıtları gönderir. Gelen yönde iş ortağı, yeni rezervasyonları, değişiklikleri ve iptalleri gönderir; her biri, otelin kendi kaydıyla eşleştirebileceği bir referans taşır.

Alışveriş insanlar arasında değil, sistemler arasında yürür: e-posta yok, portal girişi yok, yeniden yazma yok. Otelin kendi sistemi, ekibin çalıştığı kayıt olmaya devam eder. Otelin imzaladığı şey aslında bir biçim değil, bir yükümlülüktür: veriyi güncel tutmak, bağlantıdan gelene kabul etmek ve tesisin kendi kayıtlarıyla mutabakat yapmak.

Teknik konunun arkasında ticari bir konu vardır. Bir bedbank daha ileriye satış yapabilir; rezervasyondaki acente adı, sözleşmedeki adla her zaman aynı olmayabilir. Odalarınızı kimin hangi fiyatla satmaya yetkili olduğunu sorun. Bağlantının kendisi hiçbir şey kararlaştırmaz; otelin zaten kararlaştırıp yüklediğini taşır.

Push ve pull: konuşmayı kim başlatır?#

Push, otelin sisteminin bir şey değiştiğinde güncelleme göndermesidir. Pull, iş ortağının gezgin arama yaptığı anda güncel tabloyu istemesidir.

Push, bir rezervasyon, bir kapama ya da fiyat düzenlemesi gibi bir olayla ya da sabit bir takvimle tetiklenir. İş ortağının sistemi erişilemez durumdayken yeniden deneme mekanizması ve son güncellemenin ulaşıp ulaşmadığını gösteren bir ekran gerektirir. Pull ise iş ortağının belirlediği süre içinde sorulup yanıtlanan bir sorudur. Otelin sistemi yavaş yanıt verirse arama boş döner ya da daha eski bir tabloya geri düşer.

Çoğu bağlantı ikisini birlikte kullanır: gün boyu işleyen tablo için push, gezgin rezervasyon yapmadan önceki son kontrol için pull. İkisi arasındaki boşluk, çift satışların yaşadığı yerdir. Örneğin resepsiyonda 14:02'de satılan bir oda 14:05'te gönderildiğinde, iş ortağının odayı hâlâ boş bildiği üç dakikalık bir pencere kalır.

İş ortağına hangi yöntemi kullandığını, ne sıklıkla push ya da pull yaptığını, zaman aşımının ne olduğunu ve başarısız bir güncellemenin başına ne geldiğini sorun. Push ve pull, kimin önce konuştuğunu anlatır; iki tablo çeliştiğinde hangisinin doğru olduğunu söylemez. Bu yüzden mutabakat rutini, yöntemden daha önemlidir. Mesajların içinde neler olduğuna, gecikmelere ve hata yönetimine dair ayrıntı için kanal yöneticisi entegrasyonu nasıl çalışır yazısına bakın.

Kontrat fiyatları ve dinamik fiyatlar bağlantı üzerinden nasıl taşınır?#

Kontratlı fiyat, bir fiyat planı olarak yolculuk eder: adı konmuş bir oda tipi, pansiyon tipi ve tarih aralığı için adı konmuş bir fiyat, iptal ve konaklama kuralları ekli. Dinamik fiyat ise ya iş ortağının uygulayabileceği bir kural ya da otelin sürekli gönderdiği bir fiyat olarak taşınır.

Kontrat girişi; tarihleri, oda tipini, pansiyon tipini, kapasiteyi, fiyatın net olup olmadığını ya da iş ortağının marjını taşıyıp taşımadığını, iptal son tarihlerini, minimum konaklamayı ve oda bloğuna tahsis edilen kontenjanların geri alım tarihlerini kapsar. Bunlar sektör uygulamalarıdır, bir yönetmelikle sabitlenmiş terimler değil. Otel tarafındaki bir fiyat planı, iş ortağı tarafındaki tam olarak bir fiyat planına karşılık gelmelidir. Birleştirilmiş bir eşleştirme, yanlış fiyatın misafire ulaşma yoludur.

Kontenjan (allotment), otelin iş ortağına tahsis ettiği oda bloğudur. Serbest satışta iş ortağı, otelin canlı müsaitliğinden satar. İkisi aynı bağlantı üzerinden, farklı kurallarla yürüyebilir. Erken rezervasyon ya da uzun konaklama gibi özel teklifler, yalnızca iş ortağının sisteminde koşul için bir alan varsa taşınır. Alan yoksa teklif elle kalır ve bunu hatırlaması gereken biri olur.

Dinamik fiyatta iş ortağının ya kendi değerlendirebileceği bir kurala ya da otelin gönderdiği bir fiyata ihtiyacı vardır. Fiyatı otel gönderiyorsa, push sıklığı fiyatın doğruluğu olur. Bazı şeyler hiç yolculuk etmez: sözlü vaatler, "her zaman bir oda buluruz" cümlesi ve otelin yüklemediği her fiyat.

Fiyatlarınızın diğer kanallara göre konumu, ticari ve hukuki bir sorudur; bağlantı bunu kararlaştırmaz, danışmanınız değerlendirir. Acente fiyatlarını sisteme yükleme adımları için kontrat girişi kontrol listesi yazısına bakın.

Canlıya geçmeden önce ne eşleştirilip test edilmeli?#

İş ortağının sattığı her oda tipi, fiyat planı, pansiyon tipi ve iptal politikası, otelin sistemindeki karşılığıyla birebir eşleştirilmeli, sonra iki yönde test rezervasyonlarıyla kanıtlanmalıdır.

Eşleştirme bir listedir, bir his değil. Oda tipi oda tipi, fiyat planı fiyat planı yazın ve iki tarafın aynı belgeyi onaylamasını sağlayın. Pansiyon tipleri ve kapasite kuralları kendi satırını ister: iş ortağının "iki yetişkin artı bir çocuk" olarak sattığı bir oda, otelin sistemine tam olarak öyle inmelidir. Para birimi ve vergi düzeni yazılı olmalıdır: dönüşümü hangi tarafın yaptığı, vergiyi hangi tarafın eklediği ve misafire ne gösterildiği.

Sıradanını da zor olanı da test edin: yeni rezervasyon, değişiklik, iptal, satış durağı, dolu tarih ve fiyat değişikliği, her biri iki ekranda kontrol edilerek. Test, rezervasyon otel tarafında göründüğünde bitmez; otelin onayı iş ortağına ve gezgine ulaştığında biter. Kimin onaylayıp imzalayacağını ve hangi kanıtın saklanacağını kararlaştırın ki sonradan çıkacak bir anlaşmazlığın bir başlangıç noktası olsun. Bu adımın ayrıntıları için kanal yöneticisinde oda tipi ve fiyat planı eşleştirme yazısına bakın.

Bir rezervasyon gelmezse ya da iki kez gelirse ne olur?#

Hatalar sıradandır: bir mesaj zaman aşımına uğrar, yeniden deneme aynı rezervasyonu iki kez gönderir ya da bir oda, arama ile rezervasyon arasındaki saniyelerde satılır. Önemli olan kimin fark ettiği ve kimin düzelttiğidir.

Sık görülen biçimler azdır. İş ortağı gezgine onay verir ama otelin sistemi rezervasyonu hiç almaz. Otel, yeniden deneme sonrası aynı rezervasyonu iki kez alır. Otel, çoktan kapattığı bir fiyat planı için rezervasyon alır. İki kez gönderilen bir rezervasyon tek kez işlemelidir; bunu sağlayan, iş ortağının kendi rezervasyon referansıdır, bu yüzden o alan eşleştirme görüşmesinin konusudur.

İş ortağı genellikle önce fark eder, çünkü elinde onay olan gezgindir. Otel ise çoğu zaman resepsiyonda, misafir karşısında öğrenir. Sözleşme, iki tarafta birer iletişim kişisi, bir yanıt süresi ve iki sistem arası günlük mutabakat adıyla içermelidir. Mutabakatı şikâyetten sonra değil, rutin olarak yapın: bağlantıdan gelen rezervasyonların kısa bir günlük listesini otelin kendi kayıtlarıyla eşleştirmek, çoğu açığı henüz ucuzken yakalar.

Tesiste aşırı rezervasyon, hukuki bir sorun olmaktan önce bir hizmet sorunudur. Onaylanmış bir rezervasyonun nasıl karşılanması gerektiği, danışmanınızın yanıtlayacağı bir sorudur ve hiçbir bağlantı bunu çözemez.

Elle yüklemeyi kapatmadan önce otel ne sormalı?#

Bağlantı ile eski elle süreçi, bağlantı kendini önemli fiyat planlarında kanıtlayana kadar yan yana çalıştırın; sonra her seferinde tek bir fiyat planını kapatın.

Paralel çalıştırma, belirlenen bir süre boyunca iki yoldan da yükleme yapıp her yoldan ne geldiğini karşılaştırmaktır; yalnızca bir yoldan gelen rezervasyonlar dahil. Kapsamı kontrol edin, yalnızca ana fiyat planı değil: iş ortağının sattığı her fiyat planı, elle bir yol kapatılmadan önce eşleştirilip test edilmiş olmalı. Kapanış davranışını da kontrol edin: satış durağı, dolu tarih ve varışa kapalı kuralı bağlantıdan gönderildiğinde ne oluyor?

Geceleri ve hafta sonunda bağlantıyı kimin izlediğini, bir mesaj başarısız olduğunda o kişinin ne yapacağını adıyla belirleyin. Çıkışı ihtiyaç doğmadan önce kararlaştırın: bağlantı nasıl kapatılır ve otel, yolda olan rezervasyonları kaybetmeden elle yüklemeye nasıl döner. Bağlantıdan gelen rezervasyonların otelin kendi kayıtlarıyla eşleştirildiği günlük raporu tutun; o rapor, kapatmanın güvenli olduğunun kanıtıdır.

Karar, eşleştirmeye ve mutabakat alışkanlığına duyulan güvene dayanır; verinin biçimi işin en az ilginç kısmıdır. Bu bağlantıları taşıyacak sistemi hâlâ seçiyorsanız, kanal yöneticisi seçimi yazısındaki sorular bunların hepsinden önce gelir.

Şimdi ne yapmalı#

Bir sonraki bağlantı görüşmesinden önce yazılı olarak iki belge isteyin: eşleştirme listesi ve günlük mutabakat rutini. Bu yazıdaki her şey, ne taşındığı, kimin önce konuştuğu, fiyatların nasıl taşındığı, bu ikisinden türer; bağlantının iş mi azalttığına yoksa yeni türde bir hataya mı yol açtığına onlar karar verir.

Bizim tarafımızda, iş ortakları ve yapay zekâ asistanlarının AI Otel'e sürümlü, OAuth ile korunan bir rezervasyon API'si üzerinden bağlanması ve göndereni kanıtlayan imzalı rezervasyon olayları alması için geliştirildi; henüz bağlı bir iş ortağı yok. Tasarım dağıtım merkezi sayfamızda anlatılır. Otelinizin bugünkü bağlantılarını konuşmak isterseniz görüşme talep edin.