Kanal yöneticisi seçerken: bağlantı, eşleme, destek ve ayrılma için on soru

Kanal yöneticisi, oda, fiyat ve kısıt bilgilerinizin tek bir kopyasını tutan ve sattığınız tüm rezervasyon sitelerine gönderen yazılımdır. Kanal yöneticisi seçerken şunları sorun: neye bağlanıyor, hangi fiyat ve kısıtları gönderebiliyor, hataları nasıl görüyorsunuz, destek neyi kapsıyor ve ayrılırken eşlemenize ne oluyor.

Sistemde fiyat doğru, rezervasyon sitesinde yanlış; ve bunu fark eden ilk kişi resepsiyondaki misafir oluyor. Kanal yöneticisi kararlarının çoğu, bu andan aylar önce, bir satış görüşmesinde veriliyor. Bu yazının sonunda elinizde soracağınız on soru, tanıtım öncesi göndereceğiniz bir kontrol listesi ve iki teklifi karşılaştırılabilir kılan bir puanlama tablosu olacak.

Kanal yöneticisi gerçekte ne yapar?#

Kanal yöneticisi, oda, fiyat ve kısıtlarınızın tek bir resmini tutar ve sattığınız her rezervasyon sitesine iter; böylece aynı değişikliği beş farklı ekstranete girmekten kurtulursunuz. Bu bir gönderen araçtır; talep kaynağı değildir, resepsiyon da değildir.

Üç yazılım üç ayrı iş yapar. Otel yönetim sistemi (PMS) rezervasyonu ve misafiri kaydeder. Rezervasyon motoru otelin kendi web sitesindeki satışı yapar. Kanal yöneticisi ise müsaitlik ve fiyatları dışarıdaki rezervasyon sitelerine, yani OTA'lara (online seyahat acenteleri) taşır. Daha geniş bir karşılaştırma için PMS, kanal yöneticisi ve rezervasyon motoru: hangisi ne işe yarar? yazısına bakabilirsiniz.

Bilginin yönü önemlidir. Fiyatlar ve kısıtlar dışarı gider; rezervasyonlar geri gelir. Rezervasyon, bir kişi yeniden yazmadan PMS'e düşmelidir; çünkü elle girilen her rezervasyon, tarihin ya da oda tipinin karışması için bir fırsattır.

Bu aracın önlemek için var olduğu arıza biçimi, iki sistemin de odayı boş sanması yüzünden aynı odanın iki kez satılmasıdır. Ne yapmadığı da en az yaptığı kadar önemlidir: talep yaratmaz, fiyatlarınızı belirlemez ve kanaldaki resmin sisteminizdeki resimle aynı olduğunu kontrol eden kişinin yerini almaz.

Satıcıları karşılaştırmadan önce doğruluk kaynağınızı belirleyin. Bir sistem, fiyat değişikliğinin başladığı yer olmalı; diğer her sistem onu izlemelidir. Kaynak PMS ise, kanal yöneticisi üzerinde kararlaştırılmış bir acil durum dışında doğrudan değişiklik yapılmamalı ve bu istisna da kayda geçmelidir.

Bir otel kanal yöneticisine sahip olabilir ve günlük kontrolü kimse üstlenmemişse bayat bir fiyat yüzünden yine oda kaybedebilir. Yazılım kendisine söyleneni gönderir; kanalın onu alıp almadığını, görüntüleyip görüntülemediğini ve doğru görüntüleyip görüntülemediğini doğrulamaz.

Hangi kanallara bağlanıyor ve her bağlantıyı kim çalışır durumda tutuyor?#

Kanal listesini, en son ne zaman kontrol edildiği tarihiyle yazılı isteyin; her kanal için bağlantının doğrudan mı yoksa üçüncü bir bağlantı sağlayıcısı üzerinden mi yürüdüğünü sorun. İkinci yanıt ilkinden daha önemlidir.

Bir bağlantı, sitede gördüğünüz bir logo değildir. Her kanalın arkasında bir tarafın bakımını üstlenmesi gereken bir arayüz vardır; kanal bu arayüzü değiştirdiğinde eşleştirmeyi birinin onarması gerekir. Kanal tarafında arayüz değiştiğinde ne olduğunu sorun: kim haberdar ediliyor, ne kadar çabuk ve otel bunu fiyat yanlış gitmeden önce mi yoksa sonra mı öğreniyor?

Doğrudan bağlantıları aracı üzerinden geçenlerden ayırın. İki atlama, fiyatın durabileceği iki nokta ve birbirini suçlayabilecek iki destek masası demektir. Bağlantı başına adı belirtilmiş bir yetkili isteyin ve satıcının destek ekibinin kanalın kendi hata mesajını mı görebildiğini yoksa yalnızca kendi sistemini mi görebildiğini sorun. Bu mesajların gerçekte nasıl yol aldığını kanal yöneticisi entegrasyonu nasıl çalışır? İki yönlü bağlantı, gecikme ve hatalar yazısında anlattık.

Listedeki kanallardan hangilerinin uçtan uca test edildiğini ya da sertifikalandırıldığını, hangilerinin "mümkün" olarak anlatıldığını sorun. "Mümkün"ü mevcut değil olarak değerlendirin. Benzer ölçek ve sezonluk özellikte bir referans otel isteyin ve o otele ilk ayda neyin bozulduğunu sorun. Canlıya geçmeden önce her kanalda bir test rezervasyonu yapın ve rezervasyonun doğru oda tipi, fiyat planı ve misafir bilgileriyle PMS'e düştüğünü doğrulayın.

Tanıtım öncesi gönderilecek bağlantı kontrol listesi#

Hangi fiyat ve kısıtları gerçekten gönderebiliyor?#

Bağlantının desteklediği fiyat ve kısıt türlerinin tam listesini kanal kanal isteyin; çünkü kanalın alamadığı bir kısıt görünür bir hata üretmez. Kaybolur ve oda sizin belirlemediğiniz koşullarla satılır.

Yaygın kümeyi tek tek geçmek yararlıdır. Gelişe kapalı (closed to arrival), bir tarihe varışı engellerken o tarihi kapsayan diğer varışlara izin verir. Minimum ve maksimum konaklama süresi rezervasyonun biçimini kontrol eder. Stop sale bir oda tipini tümüyle kapatır. Kişi sayısına göre fiyatlandırma, ek yetişkinin ya da çocuğun ne ödeyeceğini belirler. Türetilmiş fiyatlar bir baz fiyattan yeni fiyat üretir; örneğin esnek fiyattan türetilen iade edilemez bir plan.

Bu arka planda iki satış modeli vardır. Kontenjan (allotment), bir kanala ayrılmış oda bloğudur; serbest satışta ise boş her oda satılabilir. Bunların resmî bir tanımı yoktur; sözleşmede satıcının her biriyle ne kastettiği yazmalıdır.

Para birimi ve vergi kendi sorularını hak eder. Fiyat hangi para biriminde saklanıyor, kanal hangi para birimini alıyor, dönüştürmeyi kim yapıyor? Vergi ve ücret gösterimi nasıl işliyor: kanal misafirin ödediği fiyatı mı, otelin aldığı fiyatı mı gösteriyor? Pansiyon tipleri ve fiyat planları nasıl adlandırılıyor; adlandırmayı otel mi kontrol ediyor, satıcınınkini mi devralıyorsunuz?

En önemlisi: bir kısıt gönderilemediğinde sistem ne yapıyor? Uyarı mı veriyor, gönderimi mi durduruyor, yoksa kısıtsız fiyatı mı gönderiyor? Üçüncü davranış, odalarınızı yanlış koşullarla satandır. Satıcının demo tesisiyle değil, kendi fiyat planlarınızla senaryolu bir test yapın. Eşleştirmenin ayrıntılarını kanal yöneticisinde oda tipi ve fiyat planı eşleştirme (mapping) yazısında ele aldık.

Bir hatayı misafirden önce ben nasıl görürüm?#

Tanıtım sırasında hata kaydının ve uyarının anlatılmasını değil, size gösterilmesini isteyin. Otel hatayı okuyamıyorsa, hatayı yerine getiremeyeceği bir rezervasyona dönüşmeden önce düzeltemez.

Birbirine karıştırılması kolay üç durum vardır: kuyrukta, alındı ve yayında. Kuyrukta, değişikliğin sistem tarafından kabul edildiğini; alındı, kanalın onu aldığını; yayında ise bir misafirin onu görebildiğini anlatır. Yalnızca üçüncüsü tamamlanmıştır ve yalnızca üçüncüsü para kazandırır.

Kaydın ne tuttuğunu sorun: zamanı, kanalı, oda tipini, fiyat planını, gönderilen değeri ve kanalın kendi yanıtını. Otel nasıl uyarılıyor, kime ve tekrarlayan bir arıza size kaç kez yeniden bildiriliyor? Bir kez uyarıp sonra sessiz kalan bir sistem, ikinci arızanın önemli olmadığına sizin adınıza karar vermiştir.

Yeniden deneme nasıl işliyor: kaç deneme, hangi süre boyunca ve fiyat zaten bir kez daha değiştikten sonra başarısız bir gönderim tekrar deneniyor mu? Bir mutabakat ekranı isteyin: otelin gönderdiğiyle kanalın tuttuğunu tek ekranda karşılaştırabildiği bir görünüm.

Ardından bir kişinin sahip olduğu günlük kontrolü kararlaştırın. Bir oda tipi ve bir tarih seçin ve kanal yöneticisinin ekranına değil, kanalın kendi web sitesine bakın. Kaçırılan bir hatanın sonucu aşırı rezervasyondur; misafir lobide durduğunda bu artık bir yazılım sorunu değildir. İzleyen adımlar ayrı bir disiplindir; otelin onaylı rezervasyonu iptal etmesi gerektiğinde yazısında ele aldık.

Destek gerçekte neyi kapsıyor ve ne zaman?#

Destek, bir dizi saat, bir grup insan ve bu insanların yapmasına izin verilen işlerden oluşur. Üçünü de sözleşmede isteyin; çünkü eşlemenize dokunamayan hızlı bir yanıt, destek değildir.

Saatleri kendi saat diliminizde isteyin; ayrıca kanalın saat dilimini ve yoğun rezervasyon pencerenizi kapsayan saatleri sorun. Geceyi kim karşılıyor: satıcının kendi ekibi mi, ortak bir e-posta kutusu mu, yoksa sabaha kadar kimse mi? Destek hangi dilde veriliyor ve yanıtı veren kişi fiyat planlarından mı anlıyor, yalnızca kayıtlardan mı?

Destek ekibinin hesabınızda ne yapabildiğini sorun: yalnızca okuyabiliyor mu, öneri mi veriyor, yoksa eşleştirmeyi kendisi değiştirebiliyor mu? Üçüncüsü için ödeme yapmaya değer; yazılı isteyin. Sorunun kanal tarafında olduğu durumda ne olacağını sorun; iki şirketin nasıl birlikte çalıştığını ortaya çıkaran durum budur. Sorunun yükseltme yolu ve ulaştığı kişinin adı da yazılı olmalıdır.

İmzalamadan önce test edin. Satış süreci sırasında gerçek ama zararsız bir istek gönderin ve yanıt süresini ölçün. Ardından yanıt taahhüdünü ve istisnaları sözleşmeye koyun; istisnaları okuyun, çünkü genellikle kanal tarafındaki kesintileri kapsarlar.

Ayrıldığımda eşlememe ne oluyor?#

Oda tipleriniz, fiyat planlarınız ve bunları her kanala bağlayan kodlar sizin verinizdir; iyi bir ayrılma, son haftada değil sözleşmede kararlaştırılır. İlk fiyat gönderilmeden önce örnek bir dışa aktarım dosyası ve ayrılma adımlarını isteyin.

Dışa aktarımın ne içerdiğini sorun: oda tipi adları, fiyat planı adları, kanalın kendi kodları ve aralarındaki bağlantı, bir insanın okuyabileceği bir biçimde. Kanal tarafındaki kodların kime ait olduğunu sorun; çünkü yeni sistem bu kodları yeniden kullanmak zorundadır, yoksa kanal kopyalar oluşturur ve bir kanalın ekstranetindeki çift fiyat planlarını ayıklamak yavaş, elle yapılan bir iştir.

İhtar süresini ve sözleşmenin paralel döneme izin verip vermediğini sorun; paralel dönemde iki sistem de aynı envanteri tutar. Paralel dönem tehlikelidir: aynı kanala müsaitlik gönderen iki sistem iki farklı yanıt üretebilir; bu yüzden hangisinin önce kapatılacağını ve ne zaman kapatılacağını kararlaştırın. Sözleşme sona erdiğinde kanal tarafındaki bağlantıya ne olduğunu sorun: satıcı mı kapatıyor, siz mi kapatıyorsunuz, yoksa açık kalıp göndermeye devam mı ediyor. Ne siliniyor ve ne zaman; yanıtı yazılı alın.

İmzadan önce dışa aktarım dosyası göstermeyen bir satıcıyı, imzadan sonra da göstermeyecek bir satıcı olarak değerlendirin.

İki kanal yöneticisini yan yana nasıl puanlarım?#

Soruları ağırlıklı bir tabloya dönüştürün, her yanıtı satış konuşmasına değil kanıta göre puanlayın ve fiyatı karar değil tek bir satır yapın. İki teklifi karşılaştırılabilir kılan şey bu tablodur.

Ağırlıkları iki satıcıyla da konuşmadan önce belirleyin ki, ağırlıklandırma daha iyi bir sunumun etkisiyle biçimlenmesin. Her yanıtı sıfırdan ikiye kadar puanlayın: vaat için sıfır, belge için bir, kendi fiyat planlarınız üzerinde yapılan bir gösterim için iki. Kanıtı puanın yanına kaydedin ki toplantıda bulunmayan bir meslektaş satıcının neden o puanı aldığını görebilsin.

Fiyatı tek satır olarak tutun ve günlük kontrolün ve paralel dönemin maliyetiyle karşılaştırın; bunlar hangi satıcıyı seçerseniz seçin gerçek emektir. İki satıcıyla aynı senaryolu tanıtımı çalıştırın: aynı oda tipleri, aynı kısıtlar, aynı test rezervasyonu, aynı hata senaryosu. Kararı sezonda değil, durgun dönemde verin ve canlıya geçme ile kapatma tarihlerini plana yazın. Otel yazılımı tekliflerini karşılaştırmak için daha geniş bir şablon isterseniz otel yazılımı için ihtiyaç listesi ve teklif isteme dosyası yazısına bakabilirsiniz.

Şimdi ne yapmalı#

Puanlama tablosunu bu hafta, herhangi bir satıcı aramadan önce kurun ve yalnızca kendi fiyat planlarınızla yapılan senaryolu bir tanıtımın kanıtlarıyla doldurun. On soru, satıcının geçtiği ya da kaldığı bir sınav değildir; imzadan sonra her gün birlikte yaşayacağınız şeylerin listesidir ve tablo, bunlardan hangisini satın aldığınızı görmenin yoludur.