Çoğu e-pin işletmecisi ekibini büyütürken yetkiyi hiç düşünmez. İlk destek elemanı gelir, panele bir hesap açılır ve pratik olsun diye tam yetki verilir. İkinci kişi gelir, aynı şey tekrarlanır. Altı ay sonra panelde beş kişi vardır ve beşi de kod listesini görebilir, fiyat değiştirebilir, ödeme ayarına dokunabilir, bakiye düzeltmesi yapabilir.
Kimse kötü niyetli değildir; sorun tam da bu yüzden görünmez kalır. Ta ki biri yanlışlıkla toplu fiyat güncelleyene, biri bir kod listesini dışarı aktarana veya işten ayrılan biri hesabı kapatılmadan gidene kadar. Sağlam bir e-pin scripti bu riski teknik olarak değil, yapısal olarak çözer: rol ve yetki matrisi. Aşağıda hangi rolleri tanımlayacağını, hangi yetkileri kimden esirgeyeceğini ve matrisin kâğıtta değil panelde nasıl yaşayacağını anlatıyorum.
Rol ile Yetki Aynı Şey Değildir, Farkı Nedir?
Rol bir kişiyi tanımlar: destek, muhasebe, içerik, bayi yöneticisi. Yetki ise tek bir eylemi tanımlar: siparişi iade et, kod görüntüle, fiyat değiştir, çekim onayla. Sistem tasarımında hata, bu ikisini birleştirip "destek rolü" adında devasa bir paket yaratmaktan çıkar. Doğru yaklaşım, yetkileri atomik tutup rolleri bu yetkilerin seçilmiş kombinasyonu olarak kurmaktır.
Bu ayrım sana esneklik verir. Yarın destek ekibindeki tek bir kişiye iade yetkisi vermek istediğinde yeni bir rol uydurmazsın; mevcut role tek yetki eklersin ya da o kişiye özel istisna tanımlarsın. Ölçeklenen her dijital ürün satış scripti bu modeli kullanır, çünkü rol sayısı arttıkça sabit paketler yönetilemez hâle gelir.
Hangi Rolleri Tanımlamalısın?
Küçük ve orta ölçekli bir e-pin operasyonunda beş rol neredeyse her senaryoyu karşılar. Daha fazlasını tanımlamak yönetimi zorlaştırır, daha azı ise yetki sızmasına yol açar. Aşağıdaki matris, pratikte defalarca sınanmış bir başlangıç noktasıdır; kendi akışına göre tek tük hücre değiştirebilirsin ama iskeleti koru.
| Yetki | Yönetici | Operasyon | Destek | Muhasebe | İçerik |
|---|---|---|---|---|---|
| Kod stoğu yükleme | Var | Var | Yok | Yok | Yok |
| Satılmamış kodu görüntüleme | Var | Kısıtlı | Yok | Yok | Yok |
| Sipariş iadesi | Var | Var | Limitli | Yok | Yok |
| Fiyat ve kâr marjı | Var | Öneri | Yok | Görüntüleme | Yok |
| Bayi bakiye düzeltme | Var | Yok | Yok | Onaylı | Yok |
| Çekim talebi onayı | Var | Yok | Yok | Var | Yok |
| Ödeme sağlayıcı ayarı | Var | Yok | Yok | Yok | Yok |
| Kullanıcı ve rol yönetimi | Var | Yok | Yok | Yok | Yok |
| Ürün açıklaması ve görsel | Var | Var | Yok | Yok | Var |
| Denetim kaydı okuma | Var | Yok | Yok | Kendi alanı | Yok |
Kod Görüntüleme Yetkisi Neden Ayrı Tutulmalı?
Bir e-pin operasyonunda en değerli veri, satılmamış kodların kendisidir. Bu veriye erişen herkes teorik olarak nakit erişimine sahiptir. Bu yüzden kod görüntüleme yetkisi asla genel bir rolün içine gömülmemeli, ayrı ve gerekçeli verilmelidir.
Pratik çözüm, destek personeline kodun tamamını değil maskelenmiş hâlini göstermektir. Müşteriyle konuşurken son dört hane yeterlidir; tam kodu görmesi gereken durumlarda ise görüntüleme talebi kayıt altına alınmalı ve amiri tarafından görülebilmelidir. Böylece destek işini yapar, sen de kimin hangi kodu ne zaman gördüğünü bilirsin. Pinova bu maskeleme ve gerekçeli erişim mantığını varsayılan olarak sunar; ayrıntısı özellikler sayfasında.
Panel Kaynaklı Zararın Sebep Dağılımı
- Yetkisi fazla personelin hatası 42%
- Kapatılmayan eski hesaplar 26%
- Paylaşılan ortak yönetici hesabı 19%
- Kasıtlı kötüye kullanım 13%
İki Kişi Kuralını Nereye Koymalısın?
Bazı işlemler tek imzayla yapılmamalıdır. Bayi bakiyesine manuel ekleme, toplu fiyat güncellemesi ve çekim onayı bu sınıfa girer. İki kişi kuralı, işlemi başlatan ile onaylayanı ayırır; tek bir kişinin hatası ya da niyeti tek başına sonuç doğuramaz.
Bu kural yavaşlatıcı gibi görünür ama doğru yere konduğunda günde birkaç dakikadan fazla maliyeti yoktur. Kritik olmayan işlemlere uygularsan ekip bunu atlatmanın yolunu arar ve sistem işlevsizleşir. Bu yüzden listeyi kısa tut: parayla doğrudan ilişkili ve geri alınamaz işlemler.
Denetim Kaydı Olmadan Matris Neden Anlamsızdır?
Yetki matrisi neyin yapılabileceğini söyler, denetim kaydı ise neyin yapıldığını. İkisi birlikte çalışır. Matris olup kayıt yoksa, kural ihlalini asla tespit edemezsin; kayıt olup matris yoksa, ihlali görürsün ama engelleyemezsin.
Kayıt tutarken yalnızca "kullanıcı X güncelledi" demek yetmez. Öncesi ve sonrası değerini sakla. Fiyat 100'den 10'a düştüğünde bunu saniyeler içinde görmen gerekir; sadece "fiyat güncellendi" satırı sana hiçbir şey anlatmaz. İyi bir e-pin satış yazılımı kritik alanlarda eski ve yeni değeri yan yana tutar, filtrelenebilir kılar ve dışa aktarmana izin verir.
"admin" adında herkesin kullandığı tek hesap varsa denetim kaydın hukuken ve pratik olarak değersizdir. Her kişiye kendi hesabını aç, ortak hesabın parolasını değiştir ve kimseye verme.
Matrisi Uygularken Neyi Kontrol Etmelisin?
Yetki yapısı kurulduktan sonra kendiliğinden doğru kalmaz; ekip değişir, roller kayar, istisnalar birikir. Aşağıdaki denetim listesini üç ayda bir baştan sona geçir. Tamamı yarım saat sürer ve yıllarca sorun yaşamanı engeller.
| Kontrol | Yöntem | Beklenen sonuç | Periyot |
|---|---|---|---|
| Aktif hesap sayımı | Kullanıcı listesi ile ekip listesi karşılaştırılır | Birebir eşleşir, fazlalık yok | Aylık |
| Tam yetkili hesap | Yönetici rolündekiler sayılır | En fazla bir kişi | Aylık |
| Ayrılan personel | İK çıkış kaydı ile panel karşılaştırılır | Hesap aynı gün kapatılmış | Her ayrılışta |
| İstisna yetkiler | Role aykırı verilmiş izinler listelenir | Gerekçesi yazılı, süreli | 3 aylık |
| Kod görüntüleme kaydı | Son 30 günün erişimleri incelenir | Her erişimin bir talebi var | Aylık |
| İki kişi kuralı | Onay gerektiren işlem denenir | Tek kişiyle tamamlanamıyor | 3 aylık |
| Rol değişiklik kaydı | Kim kime yetki vermiş bakılır | Tamamı günlükte görünür | 3 aylık |
Rol yapısını sıfırdan kurmakla uğraşma
Yetki matrisi, maskelenmiş kod görüntüleme, iki kişi onayı ve değer bazlı denetim kaydı Pinova'da hazır tanımlı gelir. Ekibini büyütürken güvenliği geride bırakmazsın. Fiyatlandırmayı gör ve kurulumu başlat.
Tek kişilik işletmeyim, rol ayrımına gerek var mı?
Şimdilik iki hesap yeter: günlük işler için sınırlı yetkili bir hesap, yalnızca kritik işlemler için tam yetkili bir hesap. Böylece günlük kullanımda oluşacak bir ele geçirme tüm sistemi açmaz.
Destek ekibim kodu göremezse müşteriye nasıl yardım eder?
Maskelenmiş görünüm çoğu vakayı çözer; son dört hane eşleştirme için yeterlidir. Tam kod gerektiğinde gerekçeli tek seferlik erişim verilir ve bu erişim kayda geçer.
Yetki matrisini kim onaylamalı?
Matris işletme sahibinin kararıdır, teknik ekibin değil. Teknik taraf yalnızca uygular. Her hücreyi "bu kişi bunu yapamazsa iş durur mu" sorusuyla test ederek doldur.
Çok fazla rol tanımlarsam ne olur?
Yönetilemez hâle gelir ve insanlar pratiklik için birbirinin hesabını kullanmaya başlar. Bu da tüm yapıyı çökertir. Beş çekirdek rolde kal, ihtiyaç oldukça tekil yetki istisnası ekle.
Yetki matrisi bir güvenlik önlemi olduğu kadar bir yönetim aracıdır: kimin neyden sorumlu olduğunu netleştirir, tartışmaları bitirir ve ekip büyürken kaosu engeller. Bugün beş kişiyken kurduğun yapı, on beş kişiye çıktığında seni kurtaracak olan şeydir. Rollerin gerçek bir panelde nasıl göründüğünü ve yetki hücrelerini nasıl işaretleyeceğini denemek için canlı demo hesabını aç, ardından kurulum seçeneklerini değerlendir.