Demoya roller ve işler ile başlayın
PMS seçerken kullanıcı yetkilerini yalnız bir ayarlar ekranında görmek yeterli değildir. Demoda resepsiyon, kat hizmetleri ve yönetici için üç ayrı kurgusal kullanıcı hazırlatın; her biriyle beklenen işi ve sınırı birlikte inceleyin. Amaç en çok düğmeyi kapatmak değil, çalışanın görevini yapabildiği ve görevi dışındaki bilgiye gereksiz erişmediği bir düzeni değerlendirmektir. Bu rehber güvenlik sertifikası veya kapsamlı teknik denetim yerine geçmez. Satıcıya sorulabilecek, gözlemle kaydedilebilecek bir satın alma kontrolü önerir. Hiçbir gerçek misafir kaydı, tesisin özel ticari koşulu veya erişim bilgisi örneğe girmez. Kullanıcılar ve test kayıtları yalnız demo için uydurulmuş olmalıdır.
Kaynakların gösterdiği ilke ve örnek
OWASP, yetkinin gerekli iş ile sınırlanmasını öneren en az ayrıcalık ilkesini açıklar. Oracle’ın kamuya açık dokümanı ise görevlerin rollere atanmasına ilişkin bir ürün örneği sunar. Bu iki sayfa 8 Ekim 2026 tarihinde okundu. Buradan her PMS’in aynı ayrıntıda kontrol sağladığı veya belirli bir ürünün güvenli olduğunun kanıtlandığı sonucu çıkarılmaz. Aşağıdaki demo matrisi bizim editoryal önerimizdir. Kaynaklar prensip ve örnek sağlar; ürünün gerçek davranışı satıcının gösterebildiği testle ayrıca değerlendirilmelidir. Stayax’ın belirli yetki veya oturum özelliğini sunduğu iddia edilmemektedir. Kamuya açık açıklamayı doğrulanmış bir demo sonucu yerine yazmayın.
Bir görev, bir kayıt, bir beklenen sonuç
İlk matriste her satıra rolü, yapılacak işi, ilgili kayıt kapsamını ve beklenen sonucu yazın. Örneğin kurgusal resepsiyon kullanıcısı günlük varış listesini görebilmeli; kat hizmetleri kullanıcısı kendisine verilen oda hazırlık bilgisini işleyebilmeli. Yönetici için ise demoda seçtiğiniz denetim işini tanımlayın. Bunlar bütün tesislerde aynı yetki dağılımı gerektiği anlamına gelmez. Kendi iş düzeninizde kimin neye ihtiyacı olduğunu önce belirleyin. Aynı görevin hangi tesis veya kayıtlarla sınırlı olduğunu da yazın. “Ekrana girebiliyor” notu, hangi bilgiye hangi işlemle eriştiğini anlatmaz; beklenen sonucu açık bir cümleyle tarif edin.
İzin verilen işi de sınırı da gösterin
Satıcıdan her rol hesabıyla normal demo ekranında örneği göstermesini isteyin. Bir işlemin mümkün olmadığını görmek kadar, çalışanın ihtiyaç duyduğu işi tamamlayabildiğini görmek de önemlidir. Bir düğmenin gizli olması tek başına erişim sınırının doğrulandığı anlamına gelmez; ilgili bilgi veya işlem için ürünün desteklediği demo yolunu açıklamasını isteyin. Bu kontrol saldırı denemesi, adres atlatma veya izinsiz teknik test gerektirmez. Gözlem yapılamıyorsa “doğrulanmadı” yazın ve açıklama talep edin. Eksik gösterimi otomatik başarı saymayın. Başka bir kullanıcıyla yapılan gösteriyi ilk rolün sonucu diye kaydetmeyin.
Geçici görev ve ayrılan çalışan sorularını sorun
Bir çalışanın geçici olarak başka işi üstlenmesi gerektiğinde erişimin nasıl verildiğini, kimin onayladığını ve nasıl geri alındığını sorun. Önerilen ihtiyaç, geçici görevin bitişini ve gözden geçirme sahibini açık tutmaktır; belirli bir ürün özelliği varmış gibi anlatılmamalıdır. Ayrılan çalışan senaryosunda hesabın devre dışı bırakılmasını ve zaten açık oturumun durumunu satıcının nasıl gösterebildiğini öğrenin. Bütün ürünlerin aynı davranacağını varsaymayın. Gösterilemeyen veya yalnız sözlü açıklanan davranışı ayrı kaydedin. Bu sorular gerçek çalışan hesabında denenmez; kurgusal kullanıcıyla, izinli demo sınırında ele alınır.
İhtiyacı engellemeden uygun sınırı değerlendirin
Gereğinden fazla erişim kadar, temel işi sürekli yöneticiye aktarmayı gerektiren dar bir düzen de operasyonu zorlaştırabilir. Demoda rolün gerekli işi tamamlayıp tamamlayamadığını ve istisna için kime başvuracağını görün. Bir görev engellenirse çözüm olarak herkese yönetici yetkisi vermeyi varsaymayın. Önce işin hangi adımında hangi bilgi gerektiğini açıklayın, ardından satıcıdan uygun kapsamı göstermesini isteyin. Böylece değerlendirme “izin var mı” sorusunun ötesine geçer. Bunun belirli bir güvenlik seviyesini veya verim artışını garanti ettiğini söylemeyin; amaç ihtiyaç ile gösterilen davranışı karşılaştırmaktır.
Satın alma notunu gözleme dayandırın
Her testin sonunda rol adı, beklenen davranış, gözlenen sonuç ve açık soru için kısa bir kayıt tutun. Tarih ve demo bağlamı, sonradan hangi gösterimi değerlendirdiğinizi anlamaya yardım eder. Gerçek müşteri bilgisi veya erişim anahtarı toplamak gerekmez. Sonuçları gösterildi, gösterilemedi ve açıklama bekliyor biçiminde ayırabilirsiniz. Bu durumlar resmî denetim notu değil, satın alma değerlendirmesinin şeffaf kaydıdır. Sözleşme veya ürün uygunluğu kararı verirken doğrulanmamış vaatleri tamamlanmış test gibi göstermeyin. Aynı matrisi adaylar arasında kullanarak ihtiyaçların hangi üründe nasıl gösterildiğini karşılaştırın; rol sınırını, işin tamamlanmasını ve kalan belirsizliği birlikte değerlendirin. Demo sonrası ürün sürümü veya rol tanımı değişirse ilgili satırı yeniden kontrol edin. Eski gözlemi yeni davranışın kanıtı diye taşımayın; yeniden yapılan gösterimi tarihiyle ayrı kaydedin ve önceki notu koruyun.