Muğla'da turizm işletmelerinin rezervasyon sistemi seçimi

Muğla'da bir otelin rezervasyon sistemi seçimi, çoğu zaman yazılım kararı gibi başlar ve birkaç ay sonra kanal yönetimi kararına dönüşür. Bodrum'da on iki odalı bir butik otelle Fethiye'de altmış odalı bir tesisin ihtiyacı aynı kelimelerle anlatılıyor ama aynı sistemle karşılanmıyor. Bu yazı tek bir soruya bakıyor: bir turizm işletmesi rezervasyon sistemi seçerken hangi sırayla karar vermeli?

Karar yazılımla değil, satış kanallarıyla başlıyor

Sahada en sık görülen hata, önce bir program beğenip sonra "acaba Booking'e bağlanıyor mu" diye sormak. Doğru sıra tersi. Önce işletmenin odalarını nereden sattığı yazılır: kendi sitesi, çevrim içi seyahat acenteleri, tur operatörü kontenjanı, telefonla gelen doğrudan rezervasyon, acente sözleşmeleri. Muğla kıyısında bu dağılım tesisten tesise ciddi biçimde değişiyor; bir yerde satışın büyük bölümü operatör kontenjanından geliyor, hemen yanındaki tesiste neredeyse tamamı çevrim içi kanallardan.

Bu dağılım, seçilecek sistemin ağırlık merkezini belirliyor. Satışın çoğu çevrim içi kanallardan geliyorsa asıl ihtiyaç kanal yöneticisidir, ön büro programı değil. Satış ağırlıklı olarak operatör kontenjanıysa, kontenjan ve alokasyon takibi zayıf bir sistem, arayüzü ne kadar modern olursa olsun işi görmüyor.

Üç ayrı katman, tek bir fatura gibi satılıyor

Turizm yazılımında üç farklı işlev var ve satıcılar bunları çoğu zaman tek pakette anlatıyor:

Ön büro (PMS) tarafı odayı, konuğu, folyoyu, giriş-çıkışı tutar. Kanal yöneticisi müsaitlik ve fiyatı dış kanallara dağıtır, gelen rezervasyonu geri alır. Motor tarafı ise tesisin kendi sitesinden doğrudan rezervasyon alınmasını sağlar.

Bir işletme üçünü de tek satıcıdan alabilir ya da ayrı ayrı alıp birbirine bağlayabilir. Tek satıcı seçeneği kurulumda hızlı, sorun çıktığında adres tektir. Ayrı ayrı alma seçeneği daha esnek ama iki sistemin arasındaki bağlantı koptuğunda kimin sorumlu olduğu tartışması başlar. Ege'de küçük ve orta tesislerde ikinci seçeneğin genellikle bir "sistemi kuran kişi"ye bağımlılık ürettiği görülüyor; o kişi işten ayrıldığında bağlantının nasıl kurulduğunu kimse bilmiyor.

Overbooking riski, demo ekranında görünmeyen şey

Kanal yöneticisi değerlendirilirken bakılması gereken asıl şey arayüz değil, senkronizasyon davranışı. İki soru ayırt edici oluyor:

Bir kanaldan rezervasyon geldiğinde diğer kanallardaki müsaitlik ne kadar sürede düşüyor? Saniyeler mi, dakikalar mı? Bu süre, yüksek sezonda son odanın iki kanaldan aynı anda satılıp satılmayacağını belirliyor.

Bağlantı koptuğunda sistem ne yapıyor? Sessizce beklemesi en kötü seçenek. İyi sistemler kopukluğu ekranda gösterir ve senkronize edilemeyen değişikliklerin listesini tutar. Demo sırasında bu ekranı görmek isteyin; satıcı "öyle bir şey olmuyor" diyorsa, olduğunda ne olacağını da bilmiyorsunuz demektir.

Üçüncü bir nokta, kanal yöneticisinin hangi kanallarla resmi entegrasyonu olduğu. Ege'de çalışan tesislerin bir kısmı Rusya, Almanya ve Birleşik Krallık pazarına ayrı kanallardan satıyor; listede sadece büyük iki üç isim varsa bu tesisler için sistem eksik kalıyor.

Sezonluk açılan tesisler için yıllık lisans meselesi

Muğla'nın önemli bir bölümü sekiz ay çalışıp dört ay kapanıyor. Buna rağmen yazılım sözleşmelerinin çoğu on iki ay üzerinden yapılıyor. Kapalı dönemde ödenen bedel, sistemin gerçekten kullanılmadığı aylara denk geliyor.

Burada sorulacak soru sadece "indirim var mı" değil. Sezon dışında hesabın dondurulup dondurulamayacağı, dondurulan dönemde verilerin saklanıp saklanmadığı, yeniden açılışta ek kurulum ücreti çıkıp çıkmadığı sözleşmede yazılı olmalı. Sözlü verilen sezon esnekliği, satış temsilcisi değiştiğinde kayboluyor.

Ön muhasebe ve resmi belge tarafı ayrı bir konu

Rezervasyon sistemi konaklama satışını yönetir; faturalandırma, ön muhasebe ve resmi belge tarafı ayrı bir yazılım alanı. Bazı sistemler kendi içinde fatura üretir, bazıları mali müşavirin kullandığı programa aktarım dosyası verir, bazıları hiçbirini yapmaz ve veriler elle giriliyor.

Konaklama vergisi, e-belge zorunluluk eşikleri ve bunların kapsamı yıldan yıla tebliğle değişiyor. Burada oran ya da eşik rakamı vermiyoruz; işletmenizin hangi yükümlülüğün kapsamına girdiğini güncel GİB duyurusundan ve mali müşavirinizden doğrulayın. Yazılım satıcısının "her şey yasal olarak hazır" beyanı, sizin yükümlülüğünüzü ortadan kaldırmıyor.

Veri kimin, çıkış nasıl olacak

Rezervasyon sistemi değiştirmek, konuk geçmişi ve geleceğe dönük rezervasyonlar nedeniyle diğer yazılım geçişlerinden daha zor. Sözleşmeye bakılırken tek bir maddeye bakmak yeterli: sistemden ayrılırken hangi verinin hangi biçimde alınabildiği.

Geçmiş konaklamalar, konuk iletişim bilgileri, gelecek tarihli rezervasyonlar ve fiyat planları makine okunur bir dosya olarak alınabiliyorsa geçiş mümkündür. "PDF rapor veririz" cevabı, pratikte veriyi alamayacağınız anlamına geliyor.

Ne yapmalı

Sırayla üç şey: önce son on iki ayın rezervasyonlarını kanala göre dağıtıp yüzdeleri çıkarın, çünkü seçim bu tabloya göre yapılıyor. Sonra iki ya da üç satıcıdan demo isteyin, ama demoyu kendi verinizle ve senkronizasyon kopukluğu senaryosuyla test edin. Son olarak sözleşmede sezon dondurma ve veri çıkışı maddelerini yazılı hale getirin.

Bu üç adımı atmadan yapılan seçim, genellikle ikinci sezonda yeniden yapılıyor.