CRS nedir? Merkezi rezervasyon sistemi ve PMS’ten farkı

CRS, yani merkezi rezervasyon sistemi, bir otelin veya otel grubunun satabileceği her şeyin satış tarafındaki kaydıdır: oda tipleri, fiyatlar, kısıtlamalar, acentelerle ve kurumsal müşterilerle yapılmış anlaşmalar ve her kaynaktan gelen rezervasyonlar. Binayı yöneten tesis sistemlerinin üstünde, satışı yapan kanalların altında durur.

Bir grubun rezervasyon ofisi telefonla bir odayı onaylarken, tesisteki resepsiyon aynı odanın sonuncusunu satıyor olabilir. İki sistem de odayı boş gösterir, çünkü ikisi de sahibi olduğuna inanır. CRS'in çözmek için var olduğu sorun budur; kural konmadan eklendiğinde yarattığı sorun da budur. Bu yazıyı okuduktan sonra CRS'i teknoloji altyapınızda doğru yere koyabilecek, ihtiyacınız olup olmadığına karar verebilecek ve aynı odanın iki kez satılmasını önleyen tek kuralı yazıya dökebileceksiniz.

Otelde CRS nedir?#

CRS, satış katmanında satılabilir ürünün kaydıdır: hangi oda tipleri, hangi fiyatlarla, hangi koşullarda, kime satılabilir ve şu ana kadar hangi rezervasyonlar alınmış. Tesis sistemlerinin genellikle tutmadığı şeyleri tutar: birden çok binaya uygulanan fiyat planlarını, seyahat acenteleri ve kurumsal hesaplar için görüşülmüş fiyatları, konaklama süresi ve belirli tarihe girişte satış kısıtlamalarını ve henüz fiziksel bir odaya bağlanmamış rezervasyonları.

Misafirin girişini (check-in) yapmaz, oda atamaz, kat hizmetlerini planlamaz, gün sonu işlemini kapatmaz, hesap hazırlamaz. Bunlar otel yönetim sisteminin (PMS), binayı yöneten yazılımın işidir. CRS'teki bir rezervasyon oda tipi üzerine verilmiş bir sözdür, oda numarası değil; oda numarası ancak tesis sistemi atadığında ortaya çıkar.

Farklı satıcılar üç ayrı ürüne "CRS" diyor: satış kaydının kendisi, misafirin gördüğü rezervasyon sayfası (rezervasyon motoru) ve fiyat ile müsaitliği kanallara ileten haberci (kanal yöneticisi). Bunları ayrı adlarla anmak satın alma hatalarının çoğunu önler. İşe yarar bir test: bina yarın kapansa sistem hâlâ ne yapardı? CRS fiyatları tutmaya ve rezervasyon almaya devam ederdi; PMS'in yönetecek bir şeyi kalmazdı. CRS satış kaydı olduğu için bir grubun ticari kuralları da orada yaşar: kim, hangi fiyatla, hangi kapora ve iptal koşullarıyla satabilir.

Dört sistem, tek tabloda#

Bu parçaların nasıl ayrıştığıyla ilgili daha fazlası için PMS, kanal yöneticisi ve rezervasyon motoru: hangisi ne işe yarar? yazısına bakabilirsiniz.

CRS ile PMS arasındaki fark nedir?#

PMS binayı yönetir; CRS satılabilir ürünü. Bir rezervasyon iki sistem arasında bir kez geçer; müsaitlik ise sürekli ters yönde akar. Rezervasyonlar ve koşulları CRS'ten tesis sistemine iner; müsaitlik, kısıtlamalar ve satış durdurma kararları tesis sisteminden satış katmanına yükselir.

Bu sınır pratikte bulanıklaşır. PMS'inizde zaten bir rezervasyon motoru ve kanal yöneticisi olup olmadığını kontrol edin; varsa tek tesis, ayrı bir CRS satın almadan CRS benzeri işlevlere kavuşur. Tek başına bir PMS'in kötü yönettiği durumlar: beş tesisi kapsayan bir acente fiyat sözleşmesi, üç binada fiyat verip oda tutması gereken merkezi bir telefon hattı ya da tesis sistemi bakım için kapalıyken alınan bir rezervasyon.

Her aktarım noktası, bir mesajın gecikebileceği, çoğaltılabileceği ya da kaybolabileceği bir yerdir. Aktarım azaldıkça aynı odanın iki kez satılma yolu da azalır. Gruplarda desen genellikle birden çok tesis sisteminin üstünde tek CRS'tir; ikisinin birden taklidini yapan devasa bir PMS değil. Temel sistemlerin birbirine nasıl bağlandığını Otel teknoloji altyapısı: temel sistemler birbirine nasıl bağlanır? yazısı daha derinlemesine ele alıyor.

Misafir kaydını hangi sistem tutar?#

Tek otelin CRS'e ihtiyacı var mı?#

Genellikle ayrı bir ürün olarak yoktur. Tek envanterli bir tesis, satılabilir odalarını PMS'inde tutabilir, kanal yöneticisiyle yayımlayabilir ve rezervasyon motoruyla satabilir. Tek otelin gerçekten ihtiyacı olan şeyler şunlardır: tek bir envanter, bir vitrin, kanallara giden bir haberci ve müsaitliğin sahibinin hangi sistem olduğuna dair yazılı bir kural.

Ayrı bir CRS maliyetini karşılamaya başlar: ikinci bir tesis açıldığında, merkezi bir rezervasyon hattı birden çok binaya hizmet verdiğinde, acente ve kurumsal fiyatlar merkezden belirlendiğinde ya da tek bir rezervasyon yolunun birden fazla markayı kapsaması gerektiğinde. Erken almanın gerçek bir maliyeti vardır: eşit tutulması gereken ikinci bir envanter, fiyat değişikliğinin yapıldığı ikinci bir yer, ikinci bir kullanıcı hesabı seti ve iki sistem arasına giren yeni bir arıza biçimi.

Birleşik kurulumun size dar geldiğinin işaretleri: aynı fiyat değişikliğinin iki kez yapılması, rezervasyon ofisinin kendi elektronik tablosunu tutması, acente fiyatlarının bellekten verilmesi ya da bir grup talebine yanıt vermek için üç telefon görüşmesi gerekmesi. Orta bir yol da vardır: ayrı bir satış sistemi satın almadan önce, PMS'i kayıt olarak tutup onun içinde çalışan merkezi bir rezervasyon ofisi kurmak. Ne seçerseniz seçin, karar kaç ürün aldığınızla değil, müsaitliğin sahibiyle ilgilidir.

Bir otel grubu merkezi rezervasyon ofisini nasıl kullanır?#

Merkezi rezervasyon ofisi (CRO), birden çok tesis için tek bir yoldan rezervasyon alan, merkezde tutulan fiyat kurallarından fiyat verip onaylanan her rezervasyonu doğru tesis sistemine yönlendiren ekiptir. Tek bir resepsiyonun baş edemeyeceği işleri üstlenir: tesis adı belirtmeyen telefon ve e-posta talepleri, birden çok binayı kapsayan acente istekleri ve tesisler arasında taşınabilen grup blokları.

Merkezde olması gerekenler: fiyat planları, görüşülmüş acente ve kurumsal fiyatlar, kapora ve iptal politikaları, komisyon kuralları ve fiyatı kimin değiştirebileceği listesi. Tesiste kalması gerekenler: oda ataması, belirli bir tarih için satış durdurma, plana göre serbest bırakılan allotmanlar ve binanın gerçekten sunabildiği yerel paketler. Rezervasyon yolu, yanıt üç tesis sisteminden sırayla gelse bile, tek bir giriş noktası ve misafirin elinde tutabileceği tek bir onay isteyecek şekilde kurulmalıdır.

Raporlama sessiz ama değerli kazanımdır: tesise göre bloktan kullanılan oda sayısı (pick-up), acenteye göre üretim ve her rezervasyonun kaynağı, elle derlenmek yerine tek yerden okunur. Merkezi rezervasyon ofisi yazılımdan önce bir ekip ve kural setidir; kuralları kabul etmeden sistem satın almak, aynı tartışmaların daha hızlı bir sürümünü üretir. Örneğin merkez ofis bir kurumsal fiyat verebiliyorsa da bloktan oda açmayı yalnızca tesis yapabiliyorsa, bu bölünme ilk telefondan önce yazıya geçirilmelidir.

Nasıl kurulabileceğine dair bir örnek: AI Otel'in otel işletim sistemi, tek otelleri ve otel gruplarını tek girişten yönetmek üzere geliştirildi; seyahat acenteleri ve kurumsal müşteriler kendi portallarından rezervasyon yapar. Çalışan yazılım, lansman öncesi.

Neyi merkezileştirmek, neyi tesislerde bırakmak#

Müsaitliğin sahibi kim: CRS mi, PMS mi?#

Müsaitliğin tam olarak tek bir sahibi vardır. Diğer her sistem, sona erme tarihi olan bir kopya tutar; kopyanın süresi dolduğunda oda sahibine geri döner. Kural, envanterin sahibi olduğuna inanan iki sistemin er ya da geç aynı odayı iki kez satması ya da boş bir odayı görünmez kılması yüzünden var.

Kopya, bir tutma ya da bir allotmandır: bir kanal, bir acente veya bir satış ofisi için belirli bir süreyle ayrılmış oda sayısı. Süre bittiğinde satılmayan odalar kendiliğinden geri döner. Sahibi seçerken: tek otelde, fiziksel odaya en yakın sistem, yani PMS. Tesisler arasında satış yapan bir grupta ise CRS satılabilir havuzu sahiplenebilir, her tesis bir allotman tutar.

Kararı yazıya geçirin ve iki ekibin de görebileceği bir yere koyun. Çift satış tartışmalarının çoğu, kimsenin yazmadığı bir kural üzerindeki anlaşmazlıklardır. Her gün sabit bir saatte kontrol yapın: sahibin boş dediğiyle her kanalın aynı tarihler için gösterdiğini karşılaştırın. Bir fark, ulaşmamış bir mesajdır. Kırık bir kuralın belirtileri: kimsenin satamadığı bloke odalar, bir sistemde olup diğerinde olmayan bir rezervasyon ya da bir yerde değişen ve diğerinde değişmeyen bir fiyat. Bu arızaların arkasındaki mekanizmayı Çift rezervasyon neden olur, kanallar arasında nasıl önlenir? yazısı ele alıyor.

CRS eklemadan önce ne sormalısınız?#

Şunu sorun: müsaitliğin sahibi kim, bir değişiklik ne kadar hızlı yayılıyor, sistemler arasındaki bağlantı koptuğunda ne oluyor. Bu yanıtlar, satın alımın işi azaltıp azaltmayacağını ya da yönetilecek ikinci bir envanter ekleyip eklemeyeceğini belirler.

Sahiplikle başlayın: müsaitliğin sahibi hangi sistem ve bu, yalnızca toplantıda konuşulan bir şey değil, sözleşmeye ve kurulumaya yazılmış bir madde mi? Sonra hızı sınayın: bir fiyat ya da kısıtlama değişikliği her kanala ne kadar hızlı ulaşıyor ve ulaştığını varsaymak yerine nasıl doğruluyorsunuz? Bu sorunun arkasındaki mesajları Kanal yöneticisi entegrasyonu nasıl çalışır? İki yönlü bağlantı, gecikme ve hatalar yazısı açıklıyor.

Bağlantı koptuğunda ne olacağını sorun: tesis satmaya devam ediyor mu, sonrasında rezervasyonları kim uzlaştırıyor, mükerrer kayıtlar nasıl bulunuyor? Bir iptalin envantere nasıl döndüğünü ve odanın yeniden satılabilir hale gelmesinin ne kadar sürdüğünü sorun. Fiyatı kimin değiştirebileceğini ya da bloğu kimin açabileceğini ve her değişikliğin adla ve saatle kayda geçip geçmediğini sorun. Grup bloklarının ve allotmanların hangi takvimle serbest bırakıldığını ve bunları kimin uzatabildiğini sorun. Ve çıkışı sorun: her rezervasyonu, fiyatı ve anlaşmayı kullanılabilir bir biçimde dışa aktarabiliyor musunuz, yoksa geçmişiniz arkada mı kalıyor?

Şimdi ne yapmalı#

Tek sayfalık bir belge yazın: müsaitliğin sahibi olan sistemi, misafir kaydını tutan sistemi ve her gün ikisini birbiriyle karşılaştıracak kişiyi adıyla belirleyin. CRS binanın üstündeki bir satış kaydıdır, PMS binanın kendisidir ve tasarımın tamamı, biri envanterin sahibi olduğunda ve diğeri süresi dolan bir kopya tuttuğunda çalışır. Tek bir sistemin iki tarafı da taşıyabildiğini görmek isterseniz görüşme talep edebilirsiniz.