Bir otel PMS'inde herkesin her işlemi yapabilmesi ilk anda işleri hızlandırıyor gibi görünebilir. Ancak fiyatın değiştirilmesi, ödeme iadesi, geçmiş tarihli kaydın düzeltilmesi veya gün sonunun geri alınması gibi işlemlerde kimin ne yaptığını ayırmak; hem hata araştırmasını hem de vardiya devrini kolaylaştırır. İyi yetkilendirme, ekibi gereksiz ekranlardan uzaklaştırırken kritik kararları doğru kişiye ve görünür bir kayda bağlar.

Bu yazıda öğrenecekleriniz
  • Yetki, unvana göre değil; kullanıcının gün içinde tamamlaması gereken işlere göre tanımlanmalıdır.
  • Fiyat, tahsilat, iade ve geçmişe dönük düzeltme gibi yüksek etkili işlemlerde ikinci onay veya ek gerekçe kullanılabilir.
  • İşlem geçmişi; kullanıcı, zaman, eski değer, yeni değer ve mümkünse gerekçeyi birlikte göstermelidir.

PMS yetkilendirmesi neden operasyon konusudur?

Yetkilendirme yalnızca teknik ekibin kurduğu bir güvenlik ayarı değildir. Resepsiyondaki yeni bir kullanıcının oda ataması yapabilmesi gerekirken, aynı kullanıcının geçmiş tarihli fiyatı değiştirmesi veya ödeme iadesi başlatması her zaman gerekli olmayabilir. Görev ile yetki arasındaki bu ayrım, işlemleri yavaşlatmak için değil; kararın bağlamını korumak için yapılır.

Açık rol tanımları ayrıca vardiya sırasında sorulan soruları azaltır. Kullanıcı işlem yapamadığında hangi yöneticiye başvuracağını, yönetici de hangi işlemin neden beklediğini bilir. Böylece ortak şifre, başkasının hesabıyla giriş veya sözlü onayla kayıt değiştirme gibi izlenmesi zor alışkanlıkların önüne geçmek daha kolaylaşır.

  • Operasyon hızı: kullanıcı yalnız ihtiyaç duyduğu ekran ve işlemleri görür.
  • Sorumluluk netliği: kritik işlemin sahibi ve onaylayan kişi ayrılır.
  • İnceleme kolaylığı: beklenmeyen bir değişikliğin kaynağı işlem geçmişinden bulunur.

Rol yerine görevleri haritalayın

Başlangıç noktası hazır rol adları değil, otelinizde gerçekten yapılan işlemler olmalıdır. Bir vardiya resepsiyon görevlisi rezervasyon açar, giriş-çıkış yapar, oda atar ve yetkisi varsa tahsilat alır. Rezervasyon sorumlusu fiyat ve kontenjanı düzenleyebilir. Yönetici ise istisna kararlarını onaylar. Aynı kişi küçük bir otelde birden fazla görevi yürütebilir; yine de yetki setlerini görev bazında tanımlamak, büyüdüğünüzde düzeni korur.

Her görev için ‘görüntüleme’, ‘oluşturma’, ‘değiştirme’, ‘iptal etme’ ve ‘onaylama’ yetkilerini ayrı düşünün. Örneğin rezervasyonu görüntülemek ile geçmişe dönük konaklama fiyatını değiştirmek aynı risk düzeyinde değildir. Bu ayrım, çok geniş bir yönetici rolü açmak yerine ihtiyaç kadar erişim vermenizi sağlar.

  • Ön büro: rezervasyon, giriş-çıkış, oda atama ve tanımlı tahsilat işlemleri
  • Rezervasyon veya satış: fiyat planı, kontenjan, grup ve kanal eşleştirmeleri
  • Muhasebe: folyo inceleme, mutabakat ve tanımlı finansal düzeltmeler
  • Yönetici: istisna onayı, rol atama ve kritik kayıtların gözden geçirilmesi

Hangi işlemler ek kontrol gerektirir?

Her değişikliği ikinci kişiye onaylatmak, yoğun resepsiyonda darboğaz yaratır. Bunun yerine misafir deneyimini, geliri veya raporların geçmişini anlamlı biçimde etkileyen işlemleri ayırın. Örneğin konaklama başladıktan sonra fiyatı değiştirmek, iade oluşturmak, kapatılmış folyoyu yeniden açmak ya da gece auditini geri almak ek gerekçe ve uygun bir onay gerektirebilir.

Kuralın kendisi kadar istisnanın yolu da açık olmalıdır. Sistem işlemi engelliyorsa kullanıcı ekranda nedenini ve hangi role başvuracağını görmelidir. Onay veren kişi, yalnızca bir düğmeye basmak yerine değişikliğin etkisini, gerekçesini ve varsa bağlı kaydı inceleyebilmelidir.

  • Geçmiş tarihli fiyat veya vergi düzeltmesi
  • Tahsilat iptali, iade ya da folyo bakiyesini etkileyen işlem
  • Konaklama başladıktan sonra tarih, oda veya kişi sayısı değişikliği
  • Kapatılmış iş gününü veya tamamlanmış night audit sonucunu etkileyen işlem
  • Kullanıcı rolü, erişim alanı ve yetki seviyesinin değiştirilmesi

İşlem geçmişinde ne görünmeli?

İşlem geçmişi, yalnızca ‘güncellendi’ yazan kısa bir kayıt olduğunda soru cevaplamaz. Anlaşılır bir geçmiş, hangi kullanıcının hangi tarihte hangi kaydı değiştirdiğini; mümkün olduğunda eski ve yeni değeri de gösterir. Fiyat değişikliğinde tutar ve para birimi, oda değişikliğinde eski ve yeni oda, ödeme düzeltmesinde ise etkilediği folyo açıkça görünmelidir.

Gerekçe alanı özellikle istisna işlemlerinde faydalıdır. ‘Misafir uzatma talebi’ veya ‘mükerrer tahsilatın düzeltilmesi’ gibi kısa, somut bir not sonraki vardiyanın bağlamı anlamasını sağlar. Bu not, kişisel veya gereksiz ayrıntılarla doldurulmamalı; yalnız operasyon ve muhasebe için gerekli bilgiyi içermelidir.

  • İşlemi yapan kullanıcı ve işlem zamanı
  • Etkilenen rezervasyon, folyo, oda veya ayar kaydı
  • Eski değer, yeni değer ve işlem türü
  • Varsa onaylayan kullanıcı, onay zamanı ve kısa gerekçe

Vardiya değişiminde erişimi nasıl yönetin?

Vardiya devrinde en sağlıklı yaklaşım, herkesin kendi hesabıyla çalışmasıdır. Ortak hesap kullanıldığında işlem geçmişi gerçek kişiyi değil, genel bir etiketi gösterir; araştırma ve eğitim fırsatı kaybolur. Kullanıcı değişikliği ya da geçici görev desteği gerektiğinde ilgili rolün kimde, ne zaman aktif olduğu da bilinir olmalıdır.

Yeni çalışan, stajyer veya geçici personel için sınırlı bir başlangıç yetkisi tanımlayın. İlk günlerde yalnız görüntüleme, rezervasyon hazırlığı veya yönetici onaylı işlem gibi kademeli erişim; hem eğitimi destekler hem de gereksiz düzeltme riskini azaltır. Görev değiştiğinde eski erişimleri gözden geçirmek de yeni yetki vermek kadar önemlidir.

RoomFollow ile yetki ve kayıt düzenini görünür kılmak

PMS'te yetki yönetiminin hedefi, ekibi sürekli denetlemek değil; doğru işlemin doğru bağlamda yapılmasını kolaylaştırmaktır. RoomFollow'da kullanıcı rolleri, rezervasyon ve folyo işlemleri ile operasyon kayıtları aynı çalışma alanında izlendiğinde, otel hangi kararların yönetici onayı gerektirdiğini kendi prosedürüne göre daha açık tanımlayabilir.

Yazılımın ayarları ancak otelin yazılı çalışma biçimi kadar nettir. Görev tanımlarını, finansal yetki sınırlarını ve istisna onaylarını düzenli aralıklarla gözden geçirin; değişen ekip yapısına göre rollerin hâlâ ihtiyacı karşıladığını doğrulayın.

PMS yetkilendirme kontrol listesi

Bu listeyi tesisinizin büyüklüğüne, departman yapısına ve kullandığınız ödeme akışına uyarlayın. Amaç uzun bir erişim tablosu oluşturmak değil; kritik işlemlerde karar ve kayıt sorumluluğunu görünür hale getirmektir.

  • Günlük görevler, ekranlar ve işlem türleri departman bazında çıkarıldı.
  • Görüntüleme, oluşturma, değiştirme, iptal ve onay yetkileri ayrı belirlendi.
  • Fiyat, tahsilat, iade ve geçmişe dönük düzeltmeler için istisna kuralı tanımlandı.
  • Kritik işlemlerde kullanıcı, zaman, eski-yeni değer ve gerekçe kaydı doğrulandı.
  • Her personelin kendi hesabını kullandığı ve geçici erişimlerin bitişinin takip edildiği kontrol edildi.
  • Rol değişikliği, işten ayrılma veya vardiya desteğinde erişim gözden geçirme sorumlusu atandı.
  • Yetki matrisi ve örnek işlem kayıtları belirli aralıklarla yönetici tarafından incelendi.
Kısa cevaplar

Sık sorulan sorular

PMS'te herkesin yönetici yetkisi olması neden sorun yaratır?

Geniş yetki, kullanıcının günlük işi için gerekmeyen kritik değişiklikleri yapabilmesine yol açabilir. Görev bazlı roller, işlemleri kimin tamamlayacağını ve istisnalarda kimin karar vereceğini daha görünür hale getirir.

İşlem geçmişi hangi durumda özellikle önemlidir?

Fiyat, ödeme, iade, oda değişikliği veya geçmişe dönük düzeltme gibi birden fazla ekibi etkileyen işlemlerde önemlidir. Kullanıcı, zaman, değişen değer ve gerekçe birlikte görüldüğünde kayıt daha kolay anlaşılır.

Küçük bir otelde de rol ayrımı gerekir mi?

Evet. Aynı kişi birden çok görevi yapıyor olsa bile, günlük resepsiyon işlemleriyle yönetsel istisna kararlarını ayırmak faydalıdır. Personel sayısı arttığında bu yapı daha az değişiklikle büyütülebilir.