AI Otel’de otel grupları ve portallar: tek giriş, acenteler ve şirketler için ayrı portal

Çoklu otel yönetim sistemi, birden fazla oteli tek girişten yönetirken her otelin verisini ayrı tutar. AI Otel'de tek oteller ve gruplar aynı sistemi paylaşır; seyahat acenteleri ve kurumsal müşteriler kendi portallarından rezervasyon yapar. Geliştirildi, lansman öncesi: bağlı acente ya da şirket yok.

Altı oteli bir grup çoğu zaman altı ayrı girişle, paylaşımlı bir elektronik tabloyla ve üç kişinin yanıt verdiği bir rezervasyon e-posta kutusuyla çalışır. Karşı tarafındaki acentenin sorunu aynıdır, tersinden: anlaştığı fiyatı bilir, yine de sormak zorundadır. Bu yazının sonunda çoklu otel yönetim sisteminin gerçekte ne yapmak zorunda olduğunu, bir iş ortağı portalının neyi değiştirdiğini ve imzadan önce herhangi bir tedarikçiye hangi soruları soracağınızı bileceksiniz.

Çoklu otel yönetim sistemi gerçekte ne yapmak zorundadır?#

Bir gruba, otelleri arasında tek bir çalışma yeri verirken her otelin kayıtlarını, fiyatlarını ve hesaplarını ayrı tutmak zorundadır. Bu iki beklenti birbirini çeker; tasarım ya ikisini birden çözer ya da çözemez.

Çoklu otel yönetim sistemi, birden fazla tesise hizmet veren tek sistemdir. Alternatifi, otel başına ayrı bir kurulum, her birinin kendi girişleri ve kendi misafir listesi kopyası olmasıdır. Fark küçük görünür; ta ki bir misafir aynı grubun iki tesisinde kalana ve hiçbir sistem diğerinden haberdar olmayana kadar.

Aynı odalara üç tür insanın kapıya ihtiyacı vardır: otel ekibi, tek otel ya da grup olarak; seyahat acentesi; ve kurumsal müşteri. Her birinin aynı envanterin farklı bir görünümüne ihtiyacı vardır ve hiçbiri diğerlerinin koşullarını görmemelidir.

Tek giriş kolay yarısıdır. Zor yarısı, iki otelin kaydı karşılaştığında olur: başka bir acenteye sızmaması gereken sözleşmeli bir fiyat ya da yalnızca bir tesise ait olan bir hesap. Yaygın hata, ekranda tesis filtresi uygulanmış tek bir ortak veritabanıdır. Yeni bir rapor yazılana, bir liste dışa aktarılana ya da dışarıdan bir sistem bağlanana kadar doğru görünür.

Herhangi bir tedarikçiye uygulayabileceğiniz test şudur: ayrım veritabanında mı zorunlu kılınıyor, yoksa yalnızca uygulama katmanında mı; ve bunu anlatılırken değil, gösterilirken görmeyi isteyin.

Son sütun bir özellik listesi değil, denetlemeniz gereken bir gerekliliktir.

Tek giriş, otellerin verisini karıştırmadan bir grupta nasıl çalışır?#

Her otelin verisi veritabanı seviyesinde ayrılır; grup girişi, üzerine filtre konmuş tek bir havuza değil, ayrı kayıt kümelerine ulaşmanın yoludur.

Kiracı, düz bir dille, paylaşılan bir sistemin bir müşteriye ait dilimidir. Kiracı izolasyonu, bu dilimin ekrandaki görünüme değil, veritabanının kendisi tarafından ayrı tutulması demektir. Aynı kişi bir kez girer ve tesisler arasında geçer; her geçişin ardında farklı bir kayıt kümesi durur ve sistem hangi kümenin okunduğunu zorunlu kılar.

Veritabanı seviyesi önemlidir, çünkü uygulama filtresini yeni bir rapor, bir dışa aktarım ya da bir iş ortağı bağlantısı unutabilir. Veritabanının tuttuğu sınır ise her okuma ve her yazmada denetlenir.

Bir grup girişinin kendiliğinden vermediği şeyleri netleştirin: tek bir birleşik kâr rakamı, oteller arasında paylaşılan tek misafir profili ya da merkezden her tesise itilen fiyatlar. Bunları açıkça isteyin; girişten çıkarsamayın.

Bir grubun test etmesi gereken operasyonel uçlar şunlardır: gün sonu işlemi birkaç tesisin iş gününü nasıl kapatır, misafir oda yükseltmesi aldığında harcama tesisler arasında nasıl aktarılır, bir yönetici ayrıldığında erişimi kim verir ve kim alır.

Acente portalı nedir ve neyin yerine geçer?#

Acente portalı, acentenin bir otelle sözleştiği fiyatları gördüğü ve bu fiyatlar üzerinden rezervasyon yaptığı, giriş yapılan bir yerdir; rezervasyon masasına e-posta atıp beklemek yerine.

Yerine geçtikleri, somut olarak: e-posta ya da telefonla talep, iki tarafta ayrı tutulan kontenjan tablosu, onay bekleme süresi ve anlaşıldıktan sonra aynı rezervasyonun otelin sistemine yeniden elle girilmesi.

Sözleşmeli fiyat demek, acentenin otelin genel satış fiyatıyla değil, otelin o acenteyle anlaştığı net fiyat ve kurallarla çalışması demektir. Portal, anlaşmanın uygulandığı yerdir; anlaşmanın koşullarının ilk kez belirlendiği yer değil.

Onay iki modda çalışır: tek bir motor, bağlı otellerde anında onay verir; elle onaylayan otellere ise talebi iletir. Anında onay, otelin kendi kurallarına duyulan güvenle ilgili bir karardır; elle onay kontrolü elinde tutar, gecikmeyi de elinde tutar.

Her teklif hesabını gösterir: otelin net fiyatı, devreye giren her fiyat kuralı ve son fiyat. Tartışmalı bir fiyat, e-posta kutusunda arayarak değil, teklifi okuyarak çözülür. Bu, hesabını gösteren tekliflerin dağıtım merkezindeki tasarımının ardındaki mantıktır.

Portal geliştirildi ve lansman öncesi; bağlı acente yok. Bu bölümdeki hiçbir cümle acente kullanımına dair bir rapor değildir.

Bir grubun tartması gereken ödün şudur: e-postayı yalnızca yansıtan bir portal hiçbir şeyi değiştirmez. Kazanç, rezervasyonun otelin sistemine zaten bir rezervasyon biçiminde düştüğü anda gelir.

Kurumsal rezervasyon portalı bir şirket hesabında neyi değiştirir?#

Şirketin rezervasyonlarını tek bir kişinin e-posta kutusundan çıkarır, şirketin kendi kullanıcılarının anlaştığı fiyatları görebildiği ve bu fiyatlarla rezervasyon yapabildiği bir yere taşır.

Anlaşmadan başlayın: kurumsal fiyat, indirim kodu değil; oda tipleri, tarihler, hacimler ve koşullar üzerine kurulmuş bir sözleşmedir. Portal, bu sözleşmenin bir rezervasyona uygulandığı yerdir. Sözleşme kötü yazılmışsa portal onu düzeltmez; kurumsal fiyat anlaşmasının nasıl yapıldığına bakın.

Şirket tarafında tek hesap altında birkaç kişi rezervasyon yapabilir: bir asistan, insan kaynakları ekibi ya da seyahat koordinatörü. Otel tarafındaki kazanç mekaniktir: rezervasyon, vardiyanın sonunda bir resepsiyonistin yeniden yazdığı bir mesaj olarak değil, fiyatı eklenmiş bir rezervasyon olarak gelir.

Bir şirketi portala geçirmeden önce netleştirin: hangi fiyatlar ve oda tipleri, hangi tarih aralıkları, şirkette kim rezervasyon yapabilir, anlaşılan kontenjan tükenince ne olur ve bir sorun çıktığında otel kimi arar.

Kurumsal portal geliştirildi ve lansman öncesi; bağlı kurumsal müşteri yok.

Portallar, dağıtım merkezi ve tek oda envanteriyle nasıl ilişkilidir?#

Hepsi aynı odaların üç görünümüdür: portal acentenin ya da şirketin rezervasyon yaptığı yerdir, dağıtım merkezi arkasındaki fiyatlandırma ve onay motorudur, envanter ise hepsinin beslendiği tek oda sayımıdır.

Envanter ilkesi şudur: tek bir oda envanteri otelin kendi web sitesini, rezervasyon sitelerini, seyahat acentelerini ve yapay zekâ asistanlarını aynı anda besler; böylece bir yerde satılan oda başka bir yerde sunulmaz. Bu, tek oda envanteri tasarımının ta kendisidir.

Güvenliği sağlayan mekanizma tutmadır (bloke): bir oda tutulduğunda sayımdan düşer, tutma süresi dolduğunda oda envantere geri döner. Tek bir sayım yoksa her kanal kendi sayımını tutar ve otel aynı odayı iki kez satar.

Dağıtım merkezi portalların arkasında durur: oteller sözleşmeli fiyatlarını kendi koşullarıyla seyahat acentelerine açar ve her teklif otelin net fiyatını, devreye giren kuralları ve son fiyatı gösterir. Geliştirildi, demo verisiyle; bağlı acente yok. Portallar bir acentenin ya da şirketin ön kapısıdır; dördüncü bir envanter ya da ayrı bir fiyat listesi değildir.

Müsaitlik ve fiyatlar, Channex entegrasyonumuz üzerinden büyük rezervasyon sitelerine aktarılır; entegrasyon canlıya geçiş öncesi test aşamasında. Bugün bağlı acente ya da OTA yok. Her tedarikçi için doğan soru şudur: sistem kaç envanter tutuyor ve iki kanal son odayı sattığında hangisi kazanıyor?

Bugün geliştirilmiş olan nedir, olmayan nedir?#

Grup girişi ve iki portal geliştirildi ve çalışıyor, lansman öncesi. Bağlı acente ya da kurumsal müşteri yok.

Geliştirildi sözcüğü, lansman öncesinde çalışan ve müşterilerin eline geçmemiş yazılım demektir; faaliyette ile aynı şey değildir. AI Otel'in durumunda sistem tek otelleri ve grupları tek girişten yönetir, seyahat acenteleri ve kurumsal müşteriler kendi portallarından rezervasyon yapar ve her otelin verisi veritabanı seviyesinde ayrılır.

OtelCiro bugün ücret ödeyen otel müşterileriyle çalışır; otel işletim sistemi geliştirildi ve çalışıyor, lansman öncesi.

Dürüst sıfırlar: bağlı acente, kurumsal müşteri, OTA ya da iş ortağı yok; teknoloji üzerinde bir otel, rezervasyon ya da kullanıcı sayısı yok; müşteri adı ve referans yok. Okurların soracağı ama burada iddia edilmeyenler de şunlardır: oteller arası birleşik raporlama, merkezden fiyat itme, açıklanmış bir yetki modeli ve büyük acente dağıtım ağlarına bağlantı.

Bu sıfırların yazılmasının nedeni basittir: bir demo etkisiyle imza atan grup, demonun hangi parçalarının çalıştığını ve hangilerinin tasarlandığını bilmeyi hak eder.

Bir grup imzadan önce herhangi bir tedarikçiye ne sormalı?#

Panoyu değil, ayrımı isteyin: iki otelin verisi arasındaki sınır nerede duruyor ve o sınırı kim geçebiliyor?

İki gerçek tesisle, sunum slaytıyla değil gösterim isteyin: aynı misafir, aynı tarih ve aynı oda tipi her ikisinde de, ve her girişin ne görebildiği. Sınırın nerede zorunlu kılındığını sorun, veritabanında mı ekranda mı, ve gelecek yıl yeni bir rapor ya da dışarıdan bir bağlantı eklendiğinde ne olacağını. Bir grup yöneticisi rol değiştirdiğinde erişimin nasıl verildiğini ve alındığını sorun; verilişi değil, alınışı görün. Grup görünümünün ne hesapladığını ve hangi otelin kayıtlarından hesapladığını sorun ki birleşik bir rakam denetlenmiş bir rakamla karıştırılmasın. Bir acentenin kendi fiyatını, başka acenteninkini görmeden nasıl gördüğünü; bir şirketin yalnızca kendi anlaşmasını nasıl gördüğünü sorun. Son olarak durumu düz bir dille isteyin: geliştirildi mi, testte mi, yoksa arayabileceğiniz müşterileriyle faaliyette mi. Bunu net yanıtlayan bir tedarikçi, başka her konuda da daha kolay güvenilir.

Daha fazla yönetişim sorusu için otel grubu yönetimi kontrol listesine bakın.

Şimdi ne yapmalı#

Panoyu değil, sınır sorusunu sorun: herhangi bir tedarikçiden iki otelin verisinin nerede ayrıldığını ve o sınırı kimin geçebildiğini göstermesini isteyin, sonra demonun hangi parçalarının bugün çalıştığını sorun. Grup girişi, iki portal ve dağıtım merkezi tek bir tasarımdır ve bu tasarım, arkasındaki envanter tek olduğu sürece ayakta kalır. Bu soruların çalışan sistem üzerinde yanıtlanmasını isterseniz, görüşme talep edin.