Gelir yönetimi yazılımı (RMS) nedir? Küçük bir ekip ne zaman ihtiyaç duyar?

Gelir yönetimi yazılımı (RMS), otelin rezervasyon geçmişini, defterdeki mevcut satışları ve piyasa fiyatlarını okuyup her tarih için gerekçesiyle birlikte önerilen oda fiyatları ve kısıtlamalar üreten, bir kişinin onayına sunan yazılımdır. Fiyatı o karar verir; dağıtımını kanal yöneticisi yapar.

Fiyat tablosunun kırk sekmesi var ve onu kuran kişi izinde. Üç kanal aynı Cumartesi'yi üç farklı fiyattan satıyor ve binada kimse hangisinin doğru olduğunu söyleyemiyor. Bu sahne tanıdıksa, bu yazı ihtiyacınız olan şeyin bir gelir yönetimi yazılımı mı yoksa daha iyi bir rutin mi olduğuna karar vermenize yardım eder. Yazılımın ne okuduğunu, ne verdiğini, otelinizden önce ne beklediğini, nerede işe yaramadığını ve satıcı iddialarını nasıl sınayacağınızı anlatıyor.

Gelir yönetimi yazılımı nedir?#

Rezervasyon verilerini ve piyasa fiyatlarını, her tarih için gerekçesiyle birlikte önerilen oda fiyatlarına ve satış kısıtlamalarına dönüştüren yazılımdır; öneri bir kişinin onayına sunulur.

Bir satış aracı değildir. Kanallara fiyat göndermez, rezervasyon almaz, resepsiyonun yerini almaz. Kanal yöneticisi gelir yönetimi yazılımının karar verdiği fiyatı dağıtır; otel yönetim sistemi (PMS) gerçekleşeni kaydeder. Bu üç işi kafanızda ayrı tutun; satıcı sunumlarının çoğu okunması kolaylaşır.

Ürünün çıktı birimi, oda tipi ve tarih başına bir karardır: bir fiyat ve çoğu zaman bir kısıtlama. Sık görülen kısıtlamalar minimum konaklama süresi, belirli güne varışa kapama, belirli güne ayrılışa kapama veya durdurulmuş bir fiyat planıdır. Fiyat toplayıcı (rate shopper) rakiplerin açık fiyatlarını toplar; gelir yönetimi yazılımı bunları geçmişin, defterdeki talebin ve yürürlükteki kısıtlamaların yanında tek bir girdi olarak kullanır.

Kategori geniştir. Bir uçta, otelin kendi yazılı fiyat politikasını otomatik uygulayan kural tabanlı araç durur. Öteki uçta üzerine istatistiksel modeller ekleyen ürünler. Alış soruları, aşağıda göreceğiniz gibi, ikisi için de aynıdır.

İnsan döngünün içinde kalır. Sistem önerir, gelir müdürü ya da patron onaylar ve onay kayda geçer; böylece karar daha sonra patrona, denetçiye ya da Kasım ayındaki kendinize açıklanabilir. Ve sistem yalnızca fiyatlandırmaya yetkili olduğu şeyi fiyatlandırır: toptancıya söz verilmiş, allotmanda tutulmuş ya da gruba bloke edilmiş odalar genellikle onun yetkisi dışındadır.

Gelir yönetimi yazılımı, kanal yöneticisi, fiyat toplayıcı: üç ayrı iş#

Bu araçların taşıdığı rutinde yeniyseniz, otel gelir yönetimini işleyen bir rutin olarak okuyarak başlayın.

Gelir yönetimi yazılımı ne okur, ne verir?#

Üç şeyi okur: ne olduğu, ne satıldığı ve piyasanın ne istediği. Karşılığında her tarih için, gerekçesi ekli, bir fiyat ve bir kısıtlama verir.

Geçmiş demek, tarihe göre doluluk oranı; liste fiyatı değil gerçekten satılan fiyatlar; iptaller, gelmeyen misafirler, konaklama süresi ve her oda gecesini hangi segmentin aldığı demektir. Defterdeki rezervasyonlar demek, tarih ve segment bazında bloktan kullanılan oda sayısı (pick-up); böylece sistem bu sezonun temposunu bir hisle değil, geçen yılın aynı dönemiyle karşılaştırır. Piyasa fiyatları demek, aynı tarihlerde karşılaştırılabilir oda tiplerinin açık fiyatları ve otelin sisteme bildirdiği etkinlikler, tatiller ve kapanmalar.

Verdiği şey, oda tipi ve tarih başına önerilen fiyat ve minimum konaklama, kapalı varış günü ya da kapatılmış fiyat planı gibi kısıtlamalardır. Sayıdan önce gerekçe gelir. Kullanılabilir bir öneri, onu üreten kuralı ya da karşılaştırmayı adıyla söyler; böylece bir kişi saniyeler içinde onaylar, düzeltir ya da geri çevirir.

Otel girmediği sürece göremedikleri de var: maliyetler, bir grubun restoran ve bara değeri, dönen bir misafirin geçmişi, geçen ay imzalanan sözleşme, Mart'a planlanan tadilat. Her öneriyi, gerçekte karşılaştığınız sorudan daha dar bir sorunun yanıtı olarak değerlendirin.

Öneri gerekçesiyle gelir, kararı insan verir#

Tek bir öneriyi derinlemesine denetlemek için yapay zekâ fiyat önerisini onaylamadan önce gerekçede neye bakılacağını okuyun.

Otelinizden önce neye ihtiyaç duyar?#

Temiz segmentlere, tam bir işlem geçmişine ve otelin kendi sistemiyle canlı bağlantıya. Bu üçü olmadan gelir yönetimi yazılımı kötü girdilerden kendinden emin sayılar üretir.

Segmentler önce gelir. Her fiyat planı tek bir şeyi ifade etmeli: esnek direkt, iade edilemez direkt, OTA, kurumsal, grup, toptancı. Bir plan üç tür iş taşıyorsa geçmiş hiçbir şeyle karşılaştırılamaz; oysa yöntemin tamamı karşılaştırmadır.

Geçmiş, yüksek ve düşük sezon içeren en az bir tam dönem kapsamalı ki sistemin elinde mevcut tempo için bir temel olsun. Yeni bir tesis yalnızca piyasa verisiyle başlar; satıcı bunu düpedüz söylemeli, aksini ima etmemelidir.

Bağlantı, veri kadar önemlidir. Sistem pazartesileri dışa aktarılan bir tablo okuyorsa önerileri bir hafta geridedir. Bağlantı, rezervasyonları, iptalleri ve güncel fiyatları iki yönde taşımaya devam etmelidir. Çıktının bir sahibi olmalı: kimseye öneri sunmayan bir sistem hiçbir şeyi değiştirmez. Ve otelin önce yazılı bir politikaya ihtiyacı vardır: taban ve tavan fiyatlar, ne kadar ileriye fiyat verileceği, hangi segmentler ne zaman kapatılabilir. Sistem otelin politikasını uygular; politika icat etmez.

Son olarak zaman. Birinin önerileri, genellikle her gün ya da haftada birkaç kez, gözden geçirmesi gerekir. O insan saati, lisans ücretinin yanına maliyet karşılaştırmasına girmelidir.

Az şeye dokunabildiği yer: sözleşmeli fiyatlar ve allotmanlar#

Gelir yönetimi yazılımı, otelin satmakta hâlâ özgür olduğu odaları fiyatlandırır. Bir tur operatörüne sözleşmeli fiyatla verilmiş ya da allotmanda tutulmuş odalar onun erişimi dışındadır.

Sezon öncesinde toptancılarla euro bazlı sözleşmeler imzalayan bir tatil köyü, envanterinin ve fiyatının büyük bir bölümünü sabitlemiştir. Sistem yalnızca kalan üzerinde çalışabilir. Allotmanlar da aynı davranır: bir iş ortağı için serbest bırakma tarihine dek tutulan odalar fiyatlandırılamaz; sistem onları havuza geri dönene dek taahhüt edilmiş görür. Grup blokları odaları sabit bir fiyatla fiyatlandırma havuzundan çıkarır ve sistem konaklama ortasında bunları yeniden fiyatlandıramaz.

Yine de yaptığı iş gerçek iştir: serbest kısmı fiyatlandırır, o kısmın inceldiği tarihleri işaretler ve sözleşmeli işin kazandırdığını, aynı odalara açık piyasanın ödeyebileceğiyle karşılaştırır. Ne kadar taahüt edilecek, hangi fiyatla, hangi serbest bırakma koşullarıyla sorusu, iş ortağıyla verilen ticari bir karardır; yazılım ayarı değildir. Bu dengede okumak için tur operatörlerine statik mi dinamik fiyat mı verilmeli yazısına bakın.

Satın almadan önce pratik bir denetim: sezon açılmadan önce normalde taahüt edilen oda gecelerinin payını sayın. O pay, sistemin dokunamayacağı işin bölümüdür.

Tablo ve haftalık toplantı mı, sistem mi? Bir sınama#

Ölçüt oda sayısı değil, haftalık karar sayısıdır. Fiyat kararları ekibin ayırabildiği zamanı aştığında sistem yerini kazanmaya başlar.

Kararları sayın: ekip bir haftada gerçekte kaç tarih ve oda tipini yeniden fiyatlandırıyor ve her yeni fiyat kaç kanala ulaşmak zorunda. Sonra girdileri sayın: defter raporu, rakip fiyatları, etkinlikler ve grup hattı arasında her karardan önce kaç kaynağın kontrol edilmesi gerekiyor.

Tablo; tesisin oda tipi azsa, kanal bir ya da ikiyse, tekrarlayan ya da sözleşmeli işin tabanı dengeliyse ve dosyayı iyi tanıyan tek bir kişi varsa güçlüdür. Tablonun tükendiği belirtiler: fiyatlar sezon başında bir kez konuyor, dosyanın yazarı yokken bozuluyor, aynı gece için iki kanal farklı fiyat gösteriyor ya da bir fiyatın neden değiştiğini kimse söyleyemiyor.

Sistemin erken olduğu belirtiler: segmentler temiz değil, otel sistemine bağlantı elle dışa aktarım olacak ya da önerileri gözden geçirecek kimseye zaman yok. Asla boşa çıkmayan bir ara adım: tabloyu koruyun, segmentleri düzeltin ve fiyat politikasını yazıya dökün. Bu iş her satın alımdan önce gereklidir ve sonraki her teklifi karşılaştırılabilir kılar. Yazılımın dosyanın yerini ne zaman aldığının geniş resmi için küçük bir tesis tablodan ne zaman vazgeçmeli yazısını okuyun.

Kaba bir kural olarak üç ya da daha fazlası varsa sistem fiyatlandırmaya değer; daha azı varsa tablo ve haftalık toplantı hâlâ daha ucuz yanıttır.

Demo öncesinde satıcıya sorulacak sorular#

Kendi tarihlerinizden kurulmuş, gerekçesiyle birlikte tek bir öneri isteyin; onu kimin onayladığını ve nasıl geri alındığını sorun. Satıcının örnek otelindeki demo bunların hiçbirini yanıtlamaz.

Çıkışı da sorun: otel ayrılırsa fiyatlar ve geçmiş nasıl çıkar, sözleşme bittikten sonra otel ne borçlanır. Gelir vaadi istemeyin. Kendi tarihleriniz üzerinde işlenmiş bir örnek isteyin ve satıcıları aynı örnek üzerinden karşılaştırın. Teklifleri gerçekten karşılaştırılabilir kılmak için demolar başlamadan önce bir ihtiyaç listesi dosyası hazırlayın.

Şimdi ne yapmalı#

Demo almadan önce son dört haftanın fiyat kararlarını yazın: tarih, oda tipi, eski fiyat, yeni fiyat, gerekçe ve onaylayan kişi. O sayfayı dolduramıyorsanız sorun yazılımda değil rutindedir ve yukarıdaki segment ve politika bölümü önce neyi düzelteceğinizi söyler. Doldurabiliyorsanız, her satıcının geçmesi gereken sınamayı elinizde tutuyorsunuz demektir; bu yazıdaki sorular da demoyu bir karşılaştırmaya çevirir.