B2B Portalda Kullanıcı Rolleri ve Yetkiler Nasıl Kurgulanır?

B2B portalda kullanıcı rolleri ve yetkiler en başta netleştirilmezse sipariş verme, özel fiyat görme, iskonto onayı, tahsilat takibi ve operasyon devri aynı ekranda karışır. Sağlıklı kurgu; her kullanıcının yalnızca kendi işi için gerekli veriyi görmesi, kritik aksiyonların iz bırakması ve fiyat-sipariş-finans akışının kontrollü ilerlemesi üzerine kurulmalıdır.

Bu nedenle rol tasarımı sadece güvenlik konusu değildir; satış ekibinin hızını, bayi deneyimini ve operasyon tarafındaki hata riskini doğrudan etkileyen bir süreç tasarımıdır. Portal CRM, ödeme ve stok akışlarıyla birlikte düşünülürse hem ekip içi görünürlük hem de müşteri deneyimi daha tutarlı hale gelir.

Rol ve yetki kurgusu neden portal açılmadan netleşmeli?

B2B portal devreye alındıktan sonra yetkileri rastgele genişletmek, ileride geri almak zor olan bir alışkanlık yaratır. Başlangıçta kim hangi veriyi görecek, hangi adımı onaylayacak ve hangi işlemi sadece izleyecek soruları netleşirse hem geliştirme hem de eğitim süreci daha kontrollü ilerler.

• Teklif, sipariş ve tahsilat verileri gereksiz şekilde herkese açılmaz.
• Müşteri özel fiyatlandırma ve iskonto gibi hassas alanlarda hata riski azalır.
• Satıştan operasyona geçen işlerde kimin sorumlu olduğu daha net izlenir.
• Yeni bayi veya ekip üyesi eklendiğinde standart rol şablonları hızlıca uygulanır.

Portal tarafını tek başına düşünmek yerine, süreçlerin arka planda bir CRM sistemi kurgusu ile nasıl besleneceğini ve hangi adımların entegrasyonlar üzerinden otomatik ilerleyeceğini baştan planlamak daha sağlıklıdır.

B2B portalda temel kullanıcı rolleri nelerdir?

Her projede isimler değişebilir; ancak çoğu B2B portalda aşağıdaki rol aileleri işlevsel bir başlangıç noktası sağlar.

Bayi veya müşteri hesabı kullanıcıları

Bu kullanıcılar ürün görüntüleme, kendi fiyatlarını görme, sipariş oluşturma, sipariş geçmişini izleme ve gerektiğinde ödeme durumunu kontrol etme gibi görevlerle sınırlanmalıdır. Aynı müşteri hesabında farklı kullanıcı seviyeleri tanımlanabiliyorsa sipariş açabilen kişi ile sadece görüntüleme yapabilen kişi ayrıştırılmalıdır.

Satış temsilcisi veya müşteri yöneticisi

Satış tarafı müşteri hesabı açma, fiyat listesi atama, limit kontrolü başlatma, teklif veya siparişe not düşme ve gerektiğinde manuel müdahale yapma yetkisine sahip olabilir. Ancak satış kullanıcısının sistem ayarlarına veya tüm finans ekranlarına tam erişimi çoğu zaman gereksizdir.

Finans ve tahsilat kullanıcıları

Finans ekibi cari risk, vade, açık bakiye, ödeme onayı ve iade/tahsilat kayıtları gibi alanları görmelidir. Eğer portalda ödeme adımı bulunuyorsa bunu online ödeme sistemi akışıyla birlikte düşünmek gerekir; böylece ödeme görülebilirliği satış ekranından ayrılır ama gerekli yerlerde durum bilgisi paylaşılır.

Operasyon, stok ve sevkiyat kullanıcıları

Operasyon tarafı siparişin hazırlanması, stok kontrolü, sevkiyat durumu ve eksik ürün yönetimi gibi ekranlara ihtiyaç duyar. Bu rol tasarımı, portal verisinin stok yönetimi ve sipariş hazırlık süreçleriyle nerede birleşeceğini açık biçimde göstermelidir.

Yönetici veya onay mercii

İstisna fiyat onayı, müşteri limit aşımı, özel kampanya tanımı veya kritik kullanıcı değişiklikleri gibi konular için ayrı bir yönetici rolü gerekir. Bu rol her şeyi yapabilen genel kullanıcı olmamalı; istisna ve denetim sorumluluğu taşıyan kontrollü bir seviye olarak düşünülmelidir.

Hangi yetkiler rol bazında ayrılmalı?

Rol isimlerinden çok, hangi aksiyonların ayrıştırıldığı önemlidir. Aşağıdaki başlıklar çoğu projede net olarak ayrılmalıdır:

• Görüntüleme yetkileri: tüm katalog mu, sadece müşteri özel ürün grubu mu?
• Fiyat yetkileri: liste fiyatı, özel fiyat, iskonto oranı veya teklif seviyesi bilgileri kimlere açık?
• Sipariş yetkileri: sepet oluşturma, sipariş gönderme, sipariş iptal talebi açma gibi aksiyonlar kimlerde?
• Onay yetkileri: limit üstü sipariş, özel iskonto veya istisna teslimat koşullarını kim onaylar?
• Finans yetkileri: bakiye, ödeme durumu, vade ve risk bilgilerini kim görür?
• Yönetim yetkileri: kullanıcı ekleme, rol değiştirme, rapor alma ve ayar düzenleme kimlerde bulunur?

En sağlıklı yöntem, yetkileri ekran bazında değil işlem bazında düşünmektir. Böylece bir kullanıcının sipariş oluşturabilmesi, fakat limit aşan siparişi gönderememesi gibi daha gerçekçi senaryolar kurulabilir.

Sipariş, fiyat ve onay akışı nasıl birlikte tasarlanır?

B2B portalda rol tasarımı tek başına yaşamaz; fiyat, sipariş ve onay akışlarıyla birlikte anlam kazanır. Bu nedenle kurguyu aşağıdaki sırayla ele almak pratik olur:

1. Fiyat görünürlüğü: müşteri hangi listeyi, hangi indirim yapısıyla görecek?
2. Sipariş oluşturma: kullanıcı sepeti doğrudan siparişe mi çevirecek, yoksa onaya mı düşecek?
3. İstisna kontrolü: minimum sipariş, vade aşımı veya özel fiyat talebi olduğunda süreç kime gidecek?
4. Ödeme ve finans eşleşmesi: sipariş sonrası ödeme, bakiye veya risk durumu hangi rolde görünür olacak?
5. Operasyon devri: onaylanan sipariş hangi ekipte hazırlanacak ve durum bilgisi portala nasıl geri akacak?

Bu yapı, yalnızca portal ekranı olarak değil; arka planda çalışan CRM, stok ve otomasyon katmanlarıyla birlikte düşünülmelidir. Özellikle tekrar eden sipariş, durum bildirimi ve görev devri adımlarında otomasyon çözümleri ciddi operasyon kolaylığı sağlar.

Rol matrisi hazırlarken hangi hatalardan kaçınılmalı?

• Tek kullanıcıya çok fazla yetki verme: hızlı olsun diye tüm hakları tek rolde toplamak, denetimi zayıflatır.
• Müşteri hesabını tek kişi sanma: birçok B2B müşteride satın alma, muhasebe ve yönetici rolleri ayrıdır.
• İstisnaları sonradan düşünme: özel fiyat, limit aşımı, iptal veya iade gibi durumlar baştan tasarlanmalıdır.
• ERP/CRM veri sahipliğini belirsiz bırakma: hangi bilginin ana kaynağı hangi sistem olacak netleşmezse portal üzerinde çakışma yaşanır.
• Log ve iz kaydı tutmama: kritik rol değişiklikleri ve onay aksiyonları görünür olmalıdır.

Rol matrisi hazırlarken tablo mantığıyla ilerlemek en pratik yaklaşımdır: satırlarda aksiyonlar, sütunlarda roller bulunur; her kesişimde görüntüleme, düzenleme, onaylama veya yasak durumu net işaretlenir.

Projeyi yayına almadan önce hangi kontrol listesi tamamlanmalı?

• Her müşteri hesabı için örnek kullanıcı senaryoları test edildi mi?
• Özel fiyat, vade ve limit kuralları doğru kullanıcıya görünüyor mu?
• Sipariş onayı gerektiğinde sistem doğru kişiye görev atıyor mu?
• Stok ve sipariş durumu operasyon ekranlarıyla uyumlu mu?
• Kritik alan değişiklikleri loglanıyor mu?
• Satış, finans ve operasyon ekipleri aynı terimleri kullanıyor mu?

Bu kontrol listesini proje başlangıcında netleştirmek, daha sonra portalı CRM, ödeme ve operasyon süreçleriyle genişletmeyi kolaylaştırır. Eğer B2B portalınızı rol bazlı, izlenebilir ve entegrasyona açık bir yapıda kurmak istiyorsanız entegrasyonlar sayfamız üzerinden süreci birlikte planlayabilirsiniz.

Sık sorulan sorular

B2B portalda her müşteri için ayrı rol seti gerekir mi?

Her müşteri için tamamen sıfırdan rol tanımlamak gerekmez. Çoğu projede standart rol şablonları hazırlanır; ardından sadece hesap özelindeki fiyat, limit veya onay istisnaları eklenir.

Rol ve yetki kurgusu ERP veya CRM seçiminden önce yapılmalı mı?

Evet. Sistem seçimi öncesinde temel süreçler netleşirse hangi entegrasyon alanlarının kritik olduğu daha kolay görünür. Böylece portal, CRM ve ERP arasında veri sahipliği daha doğru kurgulanır.

Teklif süreci olmayan B2B yapılarda da onay akışı gerekir mi?

Çoğu zaman evet. Teklif bulunmasa bile minimum sipariş, vade, özel indirim veya limit aşımı gibi durumlar için istisna onayı gerekir. Bu nedenle onay mantığı sadece teklif süreçlerine bırakılmamalıdır.