Demoda dört farklı soruya cevap arayın
PMS kat hizmetleri demosunda yalnız renk değiştiren oda kutularına bakmayın. Aynı senaryoda şu dört soruyu ayrı cevaplatın: odada konaklayan var mı, temizlik yapıldı mı, gerekli kontrol tamamlandı mı ve açık arıza kullanım kararını etkiliyor mu? Rezervasyon doluluğu fiziksel hazırlığın, temizlik bitişi de bakım sorununun cevabı değildir. Cloudbeds’in takvim rehberi doluluk ve temizlik durumunu ayrı alanlarda gösterir. Bu ayrımın aday yazılımda nasıl uygulandığını, resepsiyonun hangi bilgiyi gördüğünü ve sonucu kimin onayladığını kendi örneklerinizle sınayın. Ekrandaki etiketlerin tesisinizin çalışma tanımlarıyla uyuşmasını kontrol edin; satış temsilcisinin kullandığı “hazır” sözcüğünü ortak tanım olmadan kabul etmeyin.
Kurgusal odalar ve rollerle senaryoyu kurun
Satıcıdan gerçek müşteri verisi olmadan bir test ortamı hazırlamasını isteyin. Kurgusal senaryoda bir oda boş ve kirli, ikinci oda dolu ve temizlik talebi bekliyor, üçüncü oda temizlenmiş fakat kontrol bekliyor olsun. Resepsiyon, kat görevlisi, kontrol sorumlusu ve bakım sorumlusu rollerini ayrı oturumlarda gösterin; küçük işletmede aynı kişi birden fazla rolü üstlense bile kararların anlamı ayrı kalsın. Başlangıç durumlarının ekran görüntüsünü veya kısa test notunu alın. Hangi ayar, yetki ya da ek modülün etkin olduğu da yazılsın. Aynı senaryoyu bütün adaylara verin ve sunum kolaylığına göre oda durumlarını değiştirmelerine izin vermeyin. Testin amacı güzel bir takvim görmek değil, ekiplerin aynı oda üzerinde çelişen karar vermemesini değerlendirmektir.
Temizlik tamamlandıktan sonra oda kontrolünü sınayın
İlk testte kat görevlisi boş ve kirli odayı temizlenmiş olarak işaretlesin. Resepsiyon oturumuna dönüp ekranda neyin değiştiğini kontrol edin: görev kapanmış mı, temizlik durumu değişmiş mi, oda kontrolü hâlâ bekliyor mu? Cloudbeds’in oda koşulları rehberi temizliği kontrolden ve envanter uygunluğundan ayırır. Aday PMS’de aynı ayrımı gösteren adımların varlığını sınayın; aynı sözcüklerin aynı anlamı taşıdığını varsaymayın. İşletmeniz oda kontrolünü gerekli görüyorsa onay adımını tamamlamadan “misafire verilebilir” sonucuna gitmeyin. Yetkisiz rol bu onayı denediğinde ne olacağını da gösterin. Bir görev tamamlandı bildirimi ile odanın son durumu uyuşmadığında hangi kayıt esas alınacak? Bu soru yazılı cevap almalıdır. Tek bir düğmenin bütün sonuçları doğru ürettiğini söylemek yerine iş akışını başlangıçtan sona yeniden oynatın.
Arıza kaydı ile satış blokajını ayrı test edin
İkinci testte temizlenmiş odaya kurgusal bir su sızıntısı arıza kaydı açın. Bildirimin sahibi, önceliği, sonraki adımı ve kontrol sonucu görünür olsun. Bakım görevi açılmasının odayı otomatik olarak satışa kapattığını varsaymayın; bu etki aday sistemde ayrıca gösterilmelidir. Mews’in durum raporu bakım bloklarının envanter etkisini ayrıca açıklar. Satıcıdan kendi ürünündeki bakım notu, kullanım kısıtı ve satış blokajının anlamını açıklamasını isteyin. Seçilen tarih aralığında hem oda ekranını hem envanter sonucunu inceleyin. Ardından görevi kapatın: blokaj kalkıyor mu, oda yeniden kontrol bekliyor mu, kaldırma yetkisi kimde? Her adımı varsayım yerine ekranda gösterilen sonuçla kaydedin. Arızayı gidermek ile odanın yeniden kullanıma uygun olduğunu onaylamak için tesisinizde farklı sorumlular varsa demo da bu ayrımı korumalıdır.
İstisnaları ve bilgi gecikmesini görünür kılın
Üçüncü test, normal akışı bozan durumları kapsasın. Dolu oda için rahatsız etmeyin talebi seçildiğinde temizlik işi siliniyor mu, bekliyor mu, yoksa farklı bir takip oluşturuluyor mu? Bir oda başka personele atandığında eski görevlinin ekranı ne gösteriyor? Mobil bağlantı kesilip değişiklik daha sonra iletildiğinde resepsiyon son bilgiyi nasıl ayırt ediyor? Hatalı durum seçimini düzeltmeyi de deneyin. Düzeltmenin önceki bilgiyi görünmez yapıp yapmadığını ve açıklama gerektirip gerektirmediğini gözleyin. Kullanıcıya güncel bilgi için hangi ekranı esas alacağı açıkça anlatılmalı. Küçük tesiste özellik sayısını artırmak yerine, gerçekten yaşanabilecek istisnalarda açık işin ve karar sorumlusunun kaybolmamasına öncelik verin.
Sonucu ölçülebilir kabul adımlarıyla kaydedin
Demo tutanağını yalnız “başarılı” ya da “başarısız” diye doldurmayın. Her adım için başlangıç durumu, yapan rol, işlem, beklenen sonuç, gösterilen sonuç ve açık soruyu kaydedin. Örneğin kurgusal kabul ölçütü şu olabilir: temizlik tamamlandığında resepsiyon değişikliği görür, kontrol beklediğini ayırt eder ve açık bakım işi varsa bunu ayrıca görür. Başarısız adımı test notuyla geri verin; satıcı bir ayar değiştirirse başlangıçtan yeniden deneyin. Karşılaştırma için aynı koşulları koruyun. Demo sırasında bulunmayan yeteneği yol haritasındaki bir vaatle tamamlanmış saymayın. Çalışan akış, ek yapılandırma isteyen akış ve gösterilemeyen akış ayrı notlanmalı. Böylece satın alma toplantısındaki karar, tek bir sunum izlenimi yerine tekrar üretilebilir test sonucu üzerinden alınır.
Satın alma kararını gösterilen kanıta bağlayın
Karar öncesi kat hizmetleri, resepsiyon ve bakım temsilcisi aynı tutanağı gözden geçirsin. Gösterilen özelliğin seçilen pakette bulunup bulunmadığını, hangi yetki ve modüllere bağlı olduğunu, eğitimde kimlere anlatılacağını ve başlangıç ayarlarını satıcıdan yazılı isteyin. Kaynak dokümanların sürümüne ve kontrol tarihine de bakın; ürünler zamanla değişebilir. Bu rehberin dayanakları 14 Ekim 2026 tarihinde açılmış kamuya açık dokümanlardır. Satıcılar arasında karar verirken kritik adımları gösteremeyen çözüm için ek doğrulama planlayın. Uygun seçim, tesisinizde odanın dolu, temiz, kontrol edilmiş ve bakım açısından uygun olma hâllerini ekiplerin anlayabildiği seçimdir. Gerçek kullanım başlamadan kurgusal kabul senaryosunu tekrar çalıştırın ve kalan soruları sorumlusuyla kapatın.