
Güzel ekran yerine doğru eşleşmeyi görün
Kanal yöneticisi demosunda oda adlarının yan yana görünmesiyle yetinmeyin. Aynı rezervasyonun doğru oda türü, kişi sayısı, hizmet kapsamı ve iptal koşuluyla anlaşılır biçimde gösterildiğini kurgusal bir senaryoda sınayın. Bu rehber genel PMS seçim sorularını tekrar etmek yerine tek bir kabul kararına odaklanır: işletmenin sattığı ürün ile kanalda sunulan ürün aynı mı? Belirli bir sağlayıcının bütün bu adımları sunduğunu veya Stayax’ın bir entegrasyon yeteneğini iddia etmiyoruz. Demosu yapılan ürünün gerçekten gösterdiği davranışı, vaat edilen davranıştan ayrı kaydedin.
Oda adı, oda türü ve tarife farklı sorulardır
Bir odanın görünen adı kolay hatırlanabilir; fakat adı tek başına yatak düzenini, kabul edilen kişi sayısını veya satılan hizmetleri anlatmayabilir. Tarife ise aynı oda için farklı yemek veya iptal koşulu sunabilir. Bu ayrımları demo öncesi küçük bir tanım listesinde toplayın. “Standart” gibi genel bir adın yanında hangi yatak ve hangi hizmet kapsamının beklendiğini yazın. Amaç yeni bir teknik sözlük üretmek değil, ekip ile sağlayıcının aynı örneği değerlendirmesidir. Benzer isimler karşılaştırmayı kolaylaştırabilir; doğruluğu tek başına kanıtlamaz.
Resmî kaynakların gösterdiği iki ayrım
Booking.com’un açık rehberi, toplam envanter ile misafirin arama koşullarında rezervasyon yapabildiği müsaitliği ayırır. Expedia Group’un resmî açıklaması ise iptal koşullarının zaman pencereleri ve saat dilimiyle ilişkisini gösterir. Biz bu ayrımları demo sorularına çeviriyoruz; teknik alanları veya bir ürünün iç çalışma yöntemini anlatmıyoruz. Ekranda oda bulunması belirli bir kişi sayısı ve tarihle satışa uygunluk anlamına gelmeyebilir. “Esnek” etiketi de misafirin hangi tarihe kadar hangi koşulla değişiklik yapabildiğini tek başına açıklamaz.
Tamamen kurgusal bir örnek hazırlayın
Demo için iki hayali oda türü seçin: iki tek yataklı oda ve çift yataklı oda. Her ikisi için işletmenin varsayımsal kişi sınırını açıkça yazın. Ardından yalnız oda içeren bir tarife ile kahvaltı içeren başka bir tarife ve farklı iptal koşulları tanımlayın. Bunlar gerçek tesise ait bilgiler veya bir sağlayıcının özel ticari şartları değildir. Örneğin beklenen eşleşmesini gösteren boş bir kontrol kağıdı hazırlayın. Sağlayıcıdan gerçek müşteri kaydı kullanmadan bu tanımları üründe nasıl göstereceğini ve sınırları nasıl açıklayacağını isteyin.
Aynı örneği küçük değişikliklerle tekrar görün
Önce oda, tarih, kişi sayısı ve tarifenin beklenen anlamını kontrol edin. Sonra aynı kurgusal durumda yalnız bir şeyi değiştirin: kişi sayısı, tarih veya hizmet kapsamı. Böylece farklı bir sonuç çıktığında hangi değişiklikle bağlantılı olduğunu anlayabilirsiniz. Tarih değişikliğinin iptal koşuluna etkisini de ayrıca sorun; bir koşulun farklı tarifeye sessizce taşınmasını kabul etmeyin. Gösterim bir demo ortamında olmalıdır. Gerçek rezervasyonu değiştirerek veya canlı satışı kapatarak bir yazılım seçimi testi yapılması bu rehberin önerisi değildir.
Yanlış eşleşme için de bir senaryo sorun
Yalnız doğru örneğin çalışmasını görmek yeterli olmayabilir. Hayali iki tek yataklı ürün çift yataklı oda gibi gösterilirse kullanıcı bunu nerede fark eder? Kişi sayısı tanımlanan sınırı aştığında hangi anlaşılır uyarı görünür? Bir işlem tamamlanmadığında ekran başarı gibi mi görünür, yoksa bekleyen durum açık mı kalır? Bunlar ürünün gösterilmesi istenen kullanıcı davranışlarıdır; bir iç algoritma tarifi değildir. Sağlayıcıdan göremediğiniz bir adımı çalışıyor saymayın. Sınırı veya eksikliği açık anlatması, sessiz bir varsayımdan daha değerlidir.
Kabul kağıdını birlikte doldurun
Her kontrol için beklenen anlamı, demoda görülen sonucu ve açık kalan soruyu ayrı yazın. “Oda eşleşmesi gösterildi” çok geniş bir nottur; “yatak düzeni, kişi sınırı ve kahvaltı kapsamı aynı kaldı” daha değerlendirilebilir bir sonuçtur. Başarılı saymak için hangi koşulların görünmesi gerektiğini toplantıdan önce belirleyin. Sonradan zor çıkan bir adımı kapsamdan sessizce çıkarmayın. Ekipte oda tanımlarını bilen kişi ile günlük operasyonu yürüten kişi aynı kağıda bakabilsin. Bu kayıt gerçek misafir verisi, erişim bilgisi veya özel ticari oran gerektirmez.
Desteği ve kapsamı gösterimden ayrı değerlendirin
Bir eşleşmenin demoda yapılması bütün satış kanallarında, bütün tarife türlerinde ve bütün işlem durumlarında aynı desteğin bulunduğunu kanıtlamaz. Desteklenen kapsamı, istisnaları ve değişiklik sorumluluğunu açıkça sorun. Kurulum sırasında oda tanımı değişirse kim doğrulayacak, eski koşul nerede düzeltilecek ve kabul kontrolü ne zaman tekrar yapılacak? Bu soruların cevabı ürüne ve işletmenin kullanımına göre değişebilir. Bir logo listesi veya genel “bağlıyoruz” ifadesi, kendi senaryonuzun çalıştığına dair kanıt yerine geçmez. Görülmeyen davranışı satın alma kararında belirsiz olarak tutun.
Görüşmeden çıkacak somut sonuç
Demo sonunda tek bir evet veya hayır yerine doğrulanan kapsamı ve kalan soruları alın. Bir sonraki adım test ortamında eksik örneği görmek, tanım listesini düzeltmek veya mevcut kapsamın ihtiyacı karşılamadığına karar vermek olabilir. Geçiş planı ancak kabul koşulları netleşince ayrıca değerlendirilir. Kontrol listesi: oda ve yatak anlamı aynı mı, kişi sınırı açık mı, hizmet ve iptal koşulu doğru tarifeye bağlı mı, hata kullanıcıya görünüyor mu ve destek kapsamı yazılı mı? Bu rehber seçim kriteri sunar; belirli bir ürünün onaylandığı veya hatasız çalışacağı sonucunu vermez.