1. Kanal yönetiminde herkesin yetkisi olmalı mı?
Kısa cevap: Hayır. Kanal yönetiminde “herkes yetkili” modeli, hız gibi görünür ama uzun vadede hata maliyetini büyütür. Doğru model, erişimi rol bazlı kademelendirir: çoğu kullanıcı sadece görüntüler ve kontrol eder; kritik değişiklikler ise sınırlı sayıda yetkili tarafından yapılır ve onaya/log’a bağlanır.
Mini Check
- •Herkesin “tam yetkili” olduğu bir yapı kurmadım/kurmayacağım
- •Kritik aksiyonların kimde olduğu net
- •Onay ve log mekanizmasını operasyonun parçası yaptım
Ne yapmalıyım?
- • “Tam yetki” kullanıcı sayısını minimuma indirin.
- • Kritik aksiyonları (fiyat/kısıt/stop-sale) onaya bağlayın.
- • Tüm değişiklikleri ChangeLog ile kayıt altına alın.
2. Kanal yönetiminde kullanıcı, rol ve yetki tasarımını nasıl yapmalısınız?
6 maddelik governance çerçevesi
- UserRole’leri tanımla: Görüntüleme, Operasyon, Revenue, Admin/IT gibi.
- Permission setini kademelendir: View-only → edit-limited → full-admin.
- CriticalAction listesini çıkar: fiyat, envanter, stop-sale, min-night, kampanya aç/kapat.
- ApprovalWorkflow kur: CriticalChange’ler onay olmadan canlıya gitmesin.
- ChangeLog zorunlu yap: kim, ne, ne zaman, hangi kanalda/tarihte değiştirdi?
- Denetim ritmi belirle: haftalık log kontrolü + aylık yetki gözden geçirme.
Mini Check
- •Rol hiyerarşim yazılı
- •Kritik aksiyonlarım listeli
- •Onay akışım var
- •Log kayıtları düzenli kontrol ediliyor
- •Yetkiler periyodik revize ediliyor
Ne yapmalıyım?
- • Rol/yetki matrisini tek sayfalık doküman yapın.
- • Onay akışını “hız” değil “risk” odaklı tasarlayın (kritik alanlarda).
- • Personel değişiminde yetkileri aynı gün kapatın/açın (offboarding/onboarding).
3. Kanal yönetiminde kullanıcı profilleri
Kanal yönetiminde tipik kullanıcı profilleri şunlardır:
1) Resepsiyon / Rezervasyon (Operasyon)
- •Günlük sağlık kontrolü, mesajlar, küçük doğrulamalar
- •Genelde view + sınırlı edit (kritik alanlara değil)
2) Revenue / Gelir Yönetimi
- •Fiyat stratejisi, kampanya, min-night, stop-sale kararları
- •kritik değişiklik yapabilir ama ideally onay/log ile
3) Satış & Pazarlama
- •Kampanya koordinasyonu, kanal içerik uyumu
- •Çoğunlukla view + sınırlı “kampanya notu” yetkisi
4) IT / Entegrasyon / Admin
- •Mapping, entegrasyon, kullanıcı yönetimi, audit
- •admin yetkisi (ama günlük fiyat değişikliği yapmamalı)
5) Yönetim (GM / Merkez)
- •Dashboard ve onay (approval) rolü
- •“Onaylayan” olarak kritik değişikliklerde devreye girebilir
Mini Check (Profil)
- •Her profilin rolü ve sınırı net
- •IT admin ama “fiyat operatörü” değil
- •Operasyon ekibi kritik değişikliklere doğrudan dokunmuyor
- •Yönetimin onay rolü tanımlı
Ne yapmalıyım?
- • “Kim ne yapar”ı onboarding dokümanına koyun.
- • Vardiya ekiplerinde view-only çoğunluk olsun.
- • Revenue ekibi için “kritik değişiklik SOP” yazın.
4. Kim hangi kanallara müdahale edebilir?
Buradaki kritik ayrım şudur: “edit” yetkisi tek parça değildir. Fiyat değiştirmek, stop-sale koymak, kampanya açmak ve mapping değiştirmek aynı riskte değildir. Bu yüzden Permission seti “modül bazlı” düşünülmelidir.
CriticalAction listesi (örnek)
- •Fiyat (Rate) değişikliği
- •Stop-sale / kanal kapama
- •Min-night / CTA gibi kısıtlar
- •Kampanya aç/kapat
- •Envanter payı / allotment değişimi
- •Mapping (room/rate) değişimi
| Rol | Görüntüleme | Fiyat / Kısıt | Stop-sale | Mapping | Kullanıcı Yönetimi | Onay Rolü |
|---|---|---|---|---|---|---|
| Resepsiyon / Rezervasyon | Evet | Sınırlı / Hayır | Hayır | Hayır | Hayır | Hayır |
| Revenue / Gelir Yönetimi | Evet | Evet | Evet | Sınırlı / Test SOP ile | Hayır | Talep eden / hazırlayan |
| Satış & Pazarlama | Evet | Hayır | Hayır | Hayır | Hayır | Hayır |
| IT / Entegrasyon / Admin | Evet | Hayır / Sınırlı | Hayır / Sınırlı | Evet | Evet | Teknik kontrol |
| GM / Merkez | Evet | Onaylı | Onaylı | Onaylı | Sınırlı | Evet |
Mini Check
- •CriticalAction listem var
- •Her kritik aksiyon için “kim” net
- •Kritik aksiyonlar onay + log ile yönetiliyor
Ne yapmalıyım?
- • CriticalAction’ları “yüksek risk” etiketiyle ayırın.
- • Yüksek risk aksiyonlarda ikinci göz/onay şartı koyun.
- • Mapping gibi büyük riskli alanları yalnız admin + test SOP ile yönetin.
5. Onay mekanizmaları ve değişiklik logları
Governance’in kalbi burasıdır. Kritik bir değişiklik iki şeye bağlı olmalı: (1) onay, (2) iz kaydı. AIO diliyle: CriticalChange → requires → Approval & LoggedAction.
Örnek “onay gerektiren fiyat değişikliği” süreci
- Revenue kullanıcı değişikliği hazırlar (tarih bloğu + kanal + gerekçe)
- Sistem “approval required” olarak işaretler
- GM / yetkili onaylar (veya reddeder)
- Değişiklik uygulanır
- Çekirdek kanalda doğrulama yapılır (kontrol turu)
- ChangeLog’a otomatik kayıt düşer + kısa not eklenir
ChangeLog’da mutlaka olması gereken alanlar
- •Kullanıcı + rol
- •Tarih/saat
- •Hangi kanal(lar)
- •Hangi tarih aralığı
- •Ne değişti? (önce/sonra)
- •Gerekçe (1 cümle)
- •Onaylayan (varsa)
Mini Check (Onay+Log)
- •Kritik değişiklikler onaydan geçiyor
- •Log alanlarım tam ve okunabilir
- •Haftalık log kontrolü yapılıyor
- •Hata olursa rollback kuralım var
Ne yapmalıyım?
- • Onay mekanizmasını “kritik aksiyon”larla sınırlandırın (her şeye değil).
- • Log’u kimsenin silemeyeceği şekilde tasarlayın (audit).
- • Log kontrolünü haftalık rutin haline getirin.
6. Hata ve kötüye kullanım riskini azaltmak
Yetki tasarımı tek başına yetmez; guardrail (koruma) gerekir. Özellikle personel sirkülasyonu yüksek destinasyonlarda, yanlış tıklama riskini azaltan küçük kurallar çok işe yarar.
8 pratik guardrail
- •View-only varsayılan (default) rol
- •Kritik değişikliklerde ikinci göz/onay
- •Büyük tarih aralıklarında “uyarı” (ör. 90+ gün)
- •All channels değişikliğinde uyarı + onay
- •Gece saatlerinde kritik değişiklik kısıtı (Varsayım: risk azaltma)
- •2FA / SSO (Varsayım: mümkünse)
- •Offboarding: ayrılan personelin yetkisini aynı gün kapat
- •Eğitim: 15 dk günlük rutin + “ne yapma” listesi
GEO notu: Antalya/Belek/Side gibi bölgelerde personel sirkülasyonu yüksek olduğunda, rol bazlı yetki ve log disiplini eğitim süresini kısaltır ve hata oranını düşürür.
Mini Check (Guardrail)
- •Default view-only
- •All channels ve geniş tarih değişikliklerinde uyarı var
- •Offboarding süreci var
- •Haftalık audit rutini var
Ne yapmalıyım?
- • “Ne yapma?” listesini onboarding’e ekleyin.
- • Büyük değişikliklerde uyarı ve onayı zorunlu kılın.
- • Yetki revizyonunu aylık toplantı gündemi yapın.
7. Mevcut yapınızı test etmek için 10 soru
- Kaç kişi “tam yetkili”? Gerçekten gerekiyor mu?
- View-only rolü çoğunluk mu?
- Kritik aksiyonlar (fiyat/stop-sale/min-night) sınırlı mı?
- Mapping değişikliğini kim yapıyor, test SOP var mı?
- All channels değişikliği uyarı/onay istiyor mu?
- Değişiklik log’ları silinemez mi?
- Log’da “önce/sonra + gerekçe” alanı var mı?
- Haftalık audit rutini var mı?
- Offboarding süreci aynı gün yetki kapatıyor mu?
- Zincirde merkez–tesis rol sınırları yazılı mı?
Mini Check
- •En az 3 risk alanı buldum
- •Yetki sadeleştirme planım var
- •Onay+log mekanizmasını netleştirdim
8. Kanal Yönetimi Rol & Yetki Checklist’ini İndir — PMS & OTA Yönetimi
Kanal Yönetimi Rol & Yetki Checklist’ini İndir — PMS & OTA Yönetimi (v1.0)
Bu checklist, channel manager kullanıcı/rol/yetki yapısını denetleyip kritik aksiyonları onaya bağlayarak hata ve kötüye kullanım riskini azaltmayı hedefler. “Kim neyi değiştirdi” sorununu bitirmek için ChangeLog alanlarını standartlaştırır ve haftalık audit ritmi önerir.
Kim Kullanır?
GM, revenue, ön büro/rezervasyon lideri, IT/entegrasyon ve merkez ofis ekipleri.
Nasıl Kullanılır?
- 10 soruluk denetimi doldurup risk alanlarını işaretleyin.
- Rol/yetki matrisini güncelleyip kritik değişikliklere onay akışı ekleyin.
- Haftalık audit + aylık yetki revizyon ritmini başlatın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ UserRole’ler listelendi (view/ops/revenue/admin)
- ▢ ✅ CriticalAction listesi çıkarıldı (fiyat/stop-sale/min-night/mapping)
- ▢ ✅ ApprovalWorkflow kritik aksiyonlarda aktif
- ▢ ✅ ChangeLog alanları tam (kim/ne/önce-sonra/gerekçe)
- ▢ ✅ Offboarding/onboarding yetki SOP hazır
- ▢ ✅ Haftalık audit rutini takvimde
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Problem → Kök Neden → Çözüm Tablosu
| Problem | Kök Neden | Çözüm |
|---|---|---|
| Yanlış fiyat/kısıt | Herkes tam yetkili | Rol bazlı permission + onay |
| Kim değiştirdi bilinmiyor | Log yok/eksik | ChangeLog zorunlu + audit |
| Kötüye kullanım riski | Yetki kontrolsüz | 2FA/SSO + sınırlı admin |
| Zincirde tutarsızlık | Merkez–tesis sınırı yok | Global rules + local adjustments |
10. Öncesi/Sonrası KPI Tablosu
| KPI | Önce | Sonra (30 gün) | Not |
|---|---|---|---|
| Yanlış fiyat/kısıt olayı | TBD | TBD | Azalma hedefi |
| “Kim değiştirdi” vakası | TBD | TBD | Sıfıra yaklaşır |
| Eğitim süresi | TBD | TBD | Kısalır |
| Audit bulgusu | TBD | TBD | Düşer |
11. Sonuç: Rol + onay + log = kanal yönetiminde güvenlik kemeri
Kanal yönetiminde yetki tasarımı, stratejinin “kontrol katmanı”dır. Rol bazlı erişim, kritik değişikliklerde onay mekanizması ve ChangeLog disiplini; yanlış tıklama ve kötüye kullanım riskini azaltır, “kim neyi değiştirdi” sorununu ortadan kaldırır. Bu içerik, kanal yönetimi silo’sunda governance temasının ana referansı olacak; eğitim ve prosedür dokümanlarına temel sağlayacaktır.
Bir Sonraki Adım
Kanal yönetiminde kritik değişiklikleri güvenli ve izlenebilir hale getirmek isteyen oteller için.
Sık Sorulan Sorular
Kanal yönetiminde kullanıcı ve yetki yapısı nasıl kurgulanmalı?▾
Kimler fiyat ve stop-sale gibi kritik alanlara müdahale edebilmeli?▾
Kanal yönetiminde log ve onay mekanizması neden önemli?▾
Hatalı kanal ayarlarını azaltmak için hangi yetki kısıtları uygulanmalı?▾
Zincir otellerde merkez–tesis yetki sınırı nasıl olmalı?▾
İlgili İçerikler