Rol bazlı erişim kontrolü (RBAC), bir kişinin ne yapabileceğine kişinin değil, rolün karar vermesi demektir. Bir sosyal medya ekibi için yirmi role değil, altı role ihtiyacın var: içerik üretici, editör, onaylayan, yayıncı, analist, admin. Her kişiyi belirli müşteri hesaplarıyla sınırla ki kimse kendine ait olmayan işi görmesin; sonra kimin neyi onayladığının kaydını tut.
Ajanslar genelde iki uçtan birine düşer. Ya herkes tek bir girişi paylaşır ya da her gönderi kurucunun onayını bekler. İkisi de bir öğleden sonrada çözülür.
TLDR: Müşteri bazında sınırlanan altı rol, onaylar kapıda, her imza kayıt altında. Kişiye özel istisnalar, tüm modeli sürdürülemez yapan şeydir.
Neredeyse her ekibi kapsayan altı rol
| Rol | Yapabilir | Yapamaz |
|---|---|---|
| İçerik üretici | Gönderi taslağı hazırlar, görsel yükler | Yayınlar, hesap bağlar |
| Editör | Kapsamdaki taslakları düzenler, onaya sunar | Kendi işini onaylar |
| Onaylayan | Taslakları onaylar, reddeder, yorum yapar | Bağlı hesapları düzenler |
| Yayıncı | Onaylanmış gönderileri planlar ve yayınlar | Onaylar, kullanıcı ekler |
| Analist | Analizleri okur, raporları dışa aktarır | İçeriğe dokunur |
| Admin | Hesap bağlar, kullanıcıları ve rolleri yönetir | Hiçbir şey, o yüzden iki kişide tut |
İki kural bu yapının çürümesini engeller. Kimse kendi işini onaylamaz ve admin tam olarak iki kişide kalır; böylece her zaman bir yedek olur, asla bir komite olmaz.
Kişiye özel izinlere diren. "Sarah, ama perşembe günleri de yayın yapabilir" dediğin an, altı ay sonra kimsenin denetleyemeyeceği bir yapı kurmuşsun demektir. İstisnayı geçici bir rol değişikliğiyle çöz, sonra eski haline getir.
Kapsam: ajansların yanlış yaptığı kısım
Tek başına bir rol yeterli değildir. A Müşterisindeki bir içerik üretici, B Müşterisini görememeli. İşte bu kapsamdır ve bir ajans tek paylaşılan girişi aştığında ilk kırılan şey budur.
Kapsamı üç eksende düşün:
- Müşteri veya marka. Kesin sınır. Freelancer'lar tam olarak bir tane alır.
- Kanal. Biri Instagram ve TikTok'a sahip olabilir ama LinkedIn şirket sayfasına dokunamaz.
- Aşama. Taslak erişimi asla yayın erişimi anlamına gelmez.
Bu gerçek bir ayrım olmalı, filtre değil. Bir freelancer hesap seçiciyi değiştirip başka bir müşterinin inbox'ına düşebiliyorsa, elinde izolasyon değil, varsayılan bir görünüm var demektir. Çalışma alanları, Mydrop'un bu çizgiyi çekme şekli: her müşteri kendi üyeleri, takvimi ve bağlı hesaplarıyla ayrı bir alandır.
Müşteri tarafındaki paydaşlar farklı bir sorundur. Çoğu aslında kullanıcı olmamalı. Giriş gerektirmeyen müşteri portalı, onların koltuk, şifre veya proje bittikten sonra sonsuza dek yöneteceğin bir izin seviyesi olmadan kendi içeriklerini inceleyip onaylamasını sağlar.
Onaylar kapıdır, kıdem merdiveni değil
İzinler kimin harekete geçebileceğine karar verir. Onaylar ne zaman geçeceğine. İkisini ayrı tut, yoksa sadece cuma günü bir gönderiyi açmak için insanları admin yapmaya başlarsın.
Yönlendirmeyi unvana göre değil, riske göre yap:
| İçerik | İnceleyenler |
|---|---|
| Şablonlu, tekrar eden gönderiler | Bir editör |
| Yeni kampanya veya yeni bir iddia | Müşteri veya marka lideri |
| Regüle, yasal veya kriz içeriği | Belirlenmiş hukuk inceleyicisi, alternatifi yok |
İlk iki satıra bir yedek onaylayan ekle ki tatil yayını durdurmasın. Üçüncü satır gerçekten bloklamalı. Onay iş akışları, imzalar düşene kadar gönderiyi bekletir; böylece "onaylandı" ve "yayınlandı", elle eşleştirdiğin iki liste değil, tek bir kayıt olur.
Denetim günlüğünün kaydetmesi gerekenler
"Bunu kim değiştirdi?" sorusu her zaman en kötü anda gelir ve yalnızca mevcut durumu saklayan bir günlük bu soruyu cevaplayamaz.
Her işlem için beş şeyi kaydet:
- Kim yaptı, adıyla bir kişi olarak, asla paylaşılan bir hesap değil.
- O an hangi role sahipti. İnsanlar rol değiştirir ve rolü okuma anında çözen bir günlük, geçmişi sessizce yeniden yazar.
- Ne değişti, önceki sürüm hâlâ okunabilir şekilde.
- Ne zaman, saat dilimiyle birlikte.
- Hangi onay altında yayınlandı.
İki pratik kural. Onay kayıtlarını operasyonel günlüklerden daha uzun sakla, çünkü insanların gerçekten istediği şey onaydır. Ve bunları müşteri ve tarih aralığına göre aranabilir yap, çünkü her denetim talebi bu şekilde gelir.
Satıcıları karşılaştırmak kolay: her birinden üç ay önceki belirli bir gönderinin onay geçmişini açmasını iste. Demoda ya vardır ya yoktur.
Satın almadan önce kontrol edilecekler
Gerçek bir izin modelini basit bir ayarlar sayfasından ayıran özellikler:
- Müşteri bazında tanımlanabilen roller, kullanıcı başına tek bir global rol değil.
- Hesap seçiciye dayanan izolasyon, gerçek bir freelancer girişiyle test edilmiş.
- Belirlenmiş inceleyicilerle onay yönlendirmesi ve tanımlı bir yedek.
- Tek bir gönderi için dışa aktarılabilir onay geçmişi.
- Koltuk gerektirmeyen inceleyici erişimi, böylece müşteri onayı lisans maliyeti çıkarmaz.
- SSO ve dizin sağlama, eğer kullanıcı listen IT'nin elindeyse. Çoğu sosyal araç bunu kurumsal planlara saklar, o yüzden sözleşme aşamasında değil, ilk görüşmede sor.
Planable ve Sprout Social, tanımlı rollerle çok adımlı onayları yönetiyor. Mydrop ise müşteri bazlı çalışma alanlarını, rolleri, taslağın üzerindeki yorumları, onay kapılarını ve giriş gerektirmeyen inceleme bağlantısını tek sistemde topluyor; ajansların çoğu zaman iki ayrı araçtan birleştirdiği kombinasyon bu. Etrafındaki operasyonel kurulumun geri kalanı için sosyal medya ajansları sayfası daha geniş resmi kapsıyor.
Bu hafta kur
Üç adım, bu sırayla:
- Bugün yayın yapabilen herkesi listele. Eski freelancer'ları ve paylaşılan girişi de dahil et. Liste her zaman herkesin beklediğinden uzun çıkar.
- Her birine tek bir rol ve tek bir müşteri kapsamı ver. İlk geçişte istisna yok.
- Müşteri paydaşlarını inceleme bağlantılarına taşı ve kullanıcı hesaplarını sil.
Takvime 90 günlük bir hatırlatıcı koy ve birinci adımı tekrar çalıştır; çünkü bayat erişim, her seferinde geri dönen hatadır. Ücretsiz başlayabilir ve bir sonraki kampanya başlamadan rollerle müşteri çalışma alanlarını hazır hale getirebilirsin.















































Google incelemesi
Trustpilot incelemesi