Hesabını gösteren teklif: AI Otel dağıtım merkezi nasıl tasarlandı?

B2B otel dağıtım merkezi, otellerin sözleşmeli fiyatlarını seyahat acentelerine açtığı ve rezervasyonlarını aldığı yazılımdır. AI Otel dağıtım merkezi, her teklifin hesabını göstermesi için geliştirildi: otelin net fiyatı, uygulanan her fiyat kuralı ve son fiyat. Geliştirildi, demo verisiyle; henüz bağlı bir acente yok.

Bir acente, teklife tek satırla yanıt verir: geçen ay bu konaklama daha ucuza mal oluyordu, neden? Rezervasyon müdürü bir elektronik tablo açar, üst üste yığılmış dört kural bulur ve gönderilen sayıyı hangisinin ürettiğini kesin olarak söyleyemez. Bu yazı, hesabını gösteren bir teklifin ne içerdiğini, tek bir motorun iki onay modelini nasıl karşıladığını ve imza atmadan önce her dağıtım platformuna hangi soruları soracağınızı anlatıyor. Ayrıca merkezimizin bugün durumunu, var olan ve olmayan şeylerle birlikte açıkça belirtiyor.

B2B otel dağıtım merkezi nedir, hesabını göstermek ne demek?#

B2B dağıtım merkezi, bir otelin sözleşmeli fiyatlarını seyahat acentelerine açtığı ve rezervasyonlarını aldığı yerdir. Hesabını göstermek ise teklifin yalnızca son rakamı değil, ara sayıları ve arkasındaki kuralları da yazdırması demektir.

Sözleşmeli fiyat, bir otel ile bir acente arasında önceden kararlaştırılan, koşullara bağlı bir fiyattır: konaklama tarihleri, oda tipi, pansiyon türü, iptal penceresi ve release süresi. Net fiyat ise otelin oda için aldığı tutardır. Acente üzerine kendi marjını ekler ve gezgine kendi fiyatıyla satar. Bu iki sayı farklıdır ve asla birbirine karıştırılmamalıdır.

Hesabını göstermek ifadesi okuldan gelir: yalnızca cevap yetmez, adımlar da yazılır ki herkes kontrol edebilsin. Bir channel manager müsaitlik ve fiyatları satış kanallarına iter. Bir dağıtım merkezi ise ticari ilişkiyi de taşır: koşulları, acenteye özel fiyatları ve her teklifin arkasındaki hesabı. Piyasa bu fikre birkaç farklı ad veriyor. Önemli olan etiket değil, platformun bir fiyatı sonradan açıklayabilmesidir.

Test basittir: teklifi, onu hazırlamayan bir çalışma arkadaşına verin ve sayıyı yeniden üretmesini isteyin.

Bugün bir otel teklifi neden izlenemiyor?#

Çünkü teklif çoğu zaman tek bir sayı olarak gidiyor ve o sayıyı üreten kurallar bir elektronik tabloda, bir e-posta zincirinde ya da tek bir kişinin hafızasında yaşıyor.

Kurallar üst üste yığılır: sezonluk fiyat, hafta sonu farkı, konaklama süresi indirimi, erken rezervasyon, oda tipi yükseltmesi, acenteye özel ayarlama, çocuk politikası, vergiler. Her biri meşru bir ticari karardır. Otelden çıkan yalnızca son sayıdır. Gerekçe arkada kalır, iç kullanım için hazırlanmış bir dosyada.

Acente neden diye sorduğunda biri hesabı tersten kurar. Bu yeniden kurulum zaman baskısı altında yapılır ve orijinaliyle eşleşmeyebilir. Maliyet iki tarafta da saatlerle ölçülebilir ve yavaş bir yanıt genelde daha hızlı yanıt veren bir otele kaybedilen rezervasyonla sonuçlanır. Bu kuralların pratikte nasıl birleştiğini görmek isterseniz, seyahat acentelerine net fiyat yazımız onları tek tek ele alıyor.

Bir de güven maliyeti var. Açıklanmayan bir sayı, acentenin oteli şişirdiğini varsaymasına davetiye çıkarır ve bu varsayımı geri çevirmek zordur. Bir de iç maliyet var: tabloyu kuran kişi ayrıldığında fiyat mantığı da onunla gider ve bir sonraki teklif tahmin olur.

Sorun kural sayısı değil. Kuralların, birinin onları görmeye ihtiyaç duyduğu anda görünmez olmasıdır.

Hesabını gösteren bir teklif ne içerir?#

Üç şey: otelin net fiyatı, etkisiyle birlikte uygulanan her fiyat kuralı ve acenteye sunulan son fiyat.

İlk satır konaklamayı sabitler: tarihler, oda tipi, kişi sayısı ve pansiyon türü. Bu olmadan geri kalan hesabın dayanağı yoktur. İkinci blok, uygulanan kuralları listeler; her biri adıyla, her biri eklediği ya da düşürdüğü tutarla. Uygulanmayan kurallar listelenmez, böylece teklif okunabilir kalır. Üçüncü satır son fiyattır. Çoğu kişinin okuduğu tek sayı budur ve artık bir argümanın tamamı değil, son satırıdır.

Örneğin, belirtilen bir netten üç gecelik konaklama, ikinci geceye hafta sonu farkı ve üçüncü gecenin bir kısmını düşüren konaklama süresi kuralı, tek bir son rakamla sonuçlansın. Sayılar örnektir ve hiçbir gerçek otele ait değildir.

Acente somut bir şey kazanır: müşterisine fiyat vermeden önce kendi marjının hâlâ çalışıp çalışmadığını görür ve oteli aramadan fiyatı ileriye doğru açıklayabilir. Otel de aynı kaydı tersinden kazanır. Geçen hafta neden daha ucuzdu sorusu, eski teklifi açarak yanıtlanır, yeniden kurulmaz.

Teklif tarihli bir kayıttır, bir yazışma değil. Bir koşul değişirse yeni bir teklif düzenlenir ve eskisi olduğu yerde kalır. Bu kayıtların çevresindeki sözlük için otel dağıtım terimleri rehberimize bakabilirsiniz.

Tek bir motor, anında onay veren otelleri ve elle onaylayan otelleri nasıl karşılar?#

Aynı motor ikisini de karşılar: bağlı bir otelde rezervasyonu anında onaylar, elle onaylayan otele talebi iletir ve yanıtı geri taşır.

Bazı oteller canlı müsaitlik tutar ve rezervasyonun o anda kapanmasını ister. Bazıları ise her talebe bir kişinin bakmasını ister; özellikle gruplarda, olağandışı tarihlerde ya da hiç çalışmadığı bir müşteride. İkisi de ticari tercihtir, olgunluk düzeyi değil. Elle onaylayan bir otel fiyat bütünlüğünü korur, geride kalmaz.

Motorun işi hangi modun geçerli olduğunu bilmek ve acenteyi asla tahmin ettirmemektir. Durum bilgisi olmadan bir e-posta kutusuna kaybolan talep, yavaş bir yanıttan daha kötüdür. Talep otelde beklerken oda başka bir yerde iki kez satılmamalıdır. Mekanizma, süresi dolan bir geçici tutmadır: kimse yanıtlamazsa envanter geri döner.

Acentenin ekrandan iki şeye ihtiyacı vardır: talebinin durumu ve tutmanın ne zaman bittiği. Bundan azı, önlem olarak başka yerden rezervasyon yapmasına yol açar. Ödünleşme gerçektir. Anında onay son dakika işini kazanır. Elle onay, otelin koşullu bir evet demesini sağlar ve o tarihlerde açmayı düşünmediği bir fiyatı korur.

Tasarım ilkesi şudur: mod oteline aittir, platforma değil. Platformun tek görevi modun görünür olmasıdır. Geçici tutmalar ve release süreleri birbiriyle ilişkili kavramlardır; allotment sözleşmesi yazımız kontrol edilecek maddeleri ele alıyor.

Otel neyi yönetir, acente neyi görür?#

Otel koşulları, fiyatları ve hangi acentenin hangisini göreceğini belirler. Acente kendisine açılanı görür, başka bir acenteye ait olan hiçbir şeyi görmez.

Koşullar: iptal pencereleri, release süreleri, minimum konaklama, satışa kapalı tarihler (blackout), pansiyon türü ve çocuk politikası. Bunlar sözleşme kararlarıdır ve platform bunları taşımakla yükümlüdür, icat etmekle değil. Fiyatlar: acenteye, sezona ve oda tipine göre sözleşmeli fiyatlar. Bir acente için kurulan fiyat kamuya açık bir fiyat değildir ve öyle de davranmamalıdır.

Görünürlük: hangi acente hangi fiyatı ve hangi kuralları görür. En çok e-postaya bırakılan, sonradan en çok yanlış anlaşılan kısım budur. Acentenin tarafı temiz kalır: kendi fiyatları, kendi teklifleri, kendi rezervasyonları. İşini yapmak için başka bir acentenin sözleşmesini görmesi gerekmez.

Yayımladığı şeyden otel sorumlu kalır. Bir dağıtım merkezi otelin fiyatını sessizce değiştirseydi bu bir fiyatlandırma motoru olurdu; bu merkez öyle değil. Sözleşme disiplini burada karşılığını verir: yazılı hale getirilip sisteme taşınan bir release süresi, tartışmasız uygulanabilen bir release süresidir.

AI Otel dağıtım merkezinin tam durumu nedir?#

Geliştirildi, demo verisiyle; henüz bağlı bir acente yok.

Geliştirildi demek, lansman öncesi çalışan yazılım demektir; müşterilerin elinde değil. Bu, kullandığımız beş durum etiketinden biridir ve Faaliyette'nin altında yer alır. Demo verisi demek, yazılımın uçtan uca çalıştırılabilmesi için yüklenmiş örnek veri demektir. Bu bir müşteri, bir pilot ya da imzalı bir acente değildir.

Bağlı acente olmadığı için acente adı yok, rezervasyon sayısı yok ve acentelerin kullandığı iddiası yok. Var olan: hesabıyla birlikte teklif, tek motorda iki onay modu ve otelin koşullar, fiyatlar ve görünürlük üzerindeki denetimi. Olmayan: bağlı acenteler, canlı rezervasyonlar ve merkeze bağlı herhangi bir ticari rakam. Bunların hiçbirini yayımlamıyoruz.

AI Otel'in ekosistem kolu olan OtelCiro, otel büyüme ve danışmanlık şirketi olarak bugün ücretli otel müşterileriyle çalışıyor. Dağıtım merkezi ise onların elinde değil. Dürüst cümle kısadır ve kullanılacak cümle budur: geliştirildi, demo verisiyle; henüz bağlı bir acente yok.

İmza atmadan önce herhangi bir B2B dağıtım platformuna ne sormalısınız?#

Hesabı, onay modunu ve çıkışı sorun. Bu üç yanıt, çalışan bir dağıtım merkezini bir fiyat listesinden ayırır.

Gerçek bir teklif isteyin: uygulanan her kural ve her birinin oynattığı tutarla birlikte yazdırılmış. Platform yalnızca son sayıyı gösterebiliyorsa, sonradan da bir fiyatı açıklayamaz. Hangi acentenizin hangi fiyatı göreceğini sorun ve bunu bir destek talebi açmadan kendinizin değiştirip değiştiremeyeceğinizi sorun.

Platformun anında onay verdiğini mi yoksa talebi ekibinize ilettiğini mi sorun ve bunu otelin tamamı için değil, acente acente seçip seçemeyeceğinizi sorun. Ekibiniz karar verirken bir talebe ne olduğunu sorun: oda tutuluyor mu, ne zamana kadar, acente ekranında ne görüyor.

Fiyat ve rezervasyon verisinin kime ait olduğunu ve ayrılırsanız neyi geri aldığınızı sorun. Okuyamadığınız bir dışa aktarım dosyası bir çıkış yolu değildir. Durumu düz sözlerle isteyin: geliştirildi mi, faaliyette mi, yol haritasında mı ve bugün hangi acenteler bağlı. Buradaki belirsiz yanıt, diğer yanıtların nasıl kurulduğunu size söyler.

Şimdi ne yapmalı#

Üç fikir birbirine oturur: hesabını yazdıran bir teklif iki tarafça da savunulabilir, oteline ait bir onay modu ticari tercihi olması gereken yerde tutar ve geliştirildi diyen bir durum etiketi konuşmayı dürüst tutar. Bir sonraki adım: en son tartışmaya yol açan kendi teklifinizden birini alın ve bir platformdan onu satır satır yeniden üretmesini isteyin. Bizimki nasıl tasarlandı görmek isterseniz görüşme talep edin.