Kurumsal Müşteri Hesapları ve Kullanıcı Yetkileri Nasıl Kurulur?

B2B'de Hesap Bir Kişi Değil, Ticari İlişkidir

B2C sistemlerde kullanıcı hesabı çoğu zaman doğrudan müşteriyi temsil eder. B2B'de ise satın alan taraf şirket veya cari hesaptır; sisteme giriş yapan kişiler bu hesabın kullanıcılarıdır. Bu ayrım yapılmadığında çalışan değişiklikleri, çok şubeli yapılar, onay süreçleri ve finansal yetkiler yönetilemez hale gelir.

1. Kurumsal Müşteri Ana Kaydı

• Müşteri/cari ID.
• Ticari unvan.
• Vergi/fatura bilgileri.
• Müşteri segmenti.
• Fiyat/iskonto grubu.
• Vade ve ödeme koşulu.
• Risk/kredi limiti.
• Satış temsilcisi.
• Durum.
• Şubeler ve adresler.

Bu alanların tamamı B2B platformunda ana veri olmak zorunda değildir. ERP veya muhasebe sistemi kaynak olabilir.

2. Cari Hesap ile Portal Hesabını Eşleyin

Kurumsal müşterinin web hesabı ile ERP/muhasebe cari hesabı güvenilir bir anahtar üzerinden ilişkilendirilmelidir.

3. Müşteri Durumları

• Başvuru/taslak.
• İncelemede.
• Aktif.
• Geçici blokeli.
• Siparişe kapalı.
• Pasif.
• Sonlandırılmış.

Durum yalnız giriş iznini değil sipariş, fiyat veya finansal işlem yetkisini etkileyebilir. Her durumun davranışı açıkça tanımlanmalıdır.

4. Kurumsal Müşteri Onboarding

1. Şirket başvurusu veya ERP'den müşteri oluşturma.
2. Temel şirket bilgilerinin doğrulanması.
3. Cari hesap eşleştirmesi.
4. Müşteri segmenti/fiyat grubu atanması.
5. Ödeme-vade-limit kurallarının atanması.
6. İlk şirket yöneticisinin tanımlanması.
7. Adres/şube bilgilerinin eklenmesi.
8. Giriş daveti.
9. İlk sipariş hazırlığı.

5. İlk Kullanıcı: Şirket Yöneticisi

İlk yetkili kullanıcı, şirket adına diğer kullanıcıları yönetebilecek şekilde tanımlanabilir. Ancak finansal veya kritik ticari yetkiler otomatik olarak verilmek zorunda değildir.

• Kullanıcı davet etme.
• Rol atama.
• Adres/şube erişimi.
• Sipariş görünümü.
• Onay yetkisi.
• Finansal görünüm.

6. Bir Şirket Altında Çok Kullanıcı

Tüm kullanıcıların aynı sipariş ve finans verisine erişmesi gerekmez.

7. Rol Bazlı Yetki Modeli

• Şirket yöneticisi.
• Satın alma kullanıcısı.
• Sipariş onaylayıcı.
• Finans kullanıcısı.
• Şube kullanıcısı.
• Salt görüntüleme/rapor kullanıcısı.

Rol isimlerinden önce izinleri tanımlayın; sonra izin kümelerini rollere bağlayın.

8. Yetki Matrisi

• Ürün/fiyat görüntüleme.
• Sepet oluşturma.
• Sipariş verme.
• Sipariş onaylama.
• Teklif isteme.
• Cari bakiye görüntüleme.
• Fatura/belge görüntüleme.
• Ödeme yapma.
• Kullanıcı yönetme.
• Adres yönetme.

Her izin şirket, şube veya işlem kapsamına göre sınırlandırılabilir.

9. Şube Bazlı Erişim

Çok şubeli müşteride kullanıcı yalnız bağlı olduğu şubenin siparişlerini ve adreslerini görebilir veya merkez kullanıcı tüm şubeleri yönetebilir.

10. Teslimat ve Fatura Adresleri

B2B müşterilerde birden fazla teslimat noktası yaygındır.

• Merkez fatura adresi.
• Şube teslimat adresleri.
• Depo/şantiye/proje adresleri.
• Varsayılan adres.
• Kullanıcıya izinli adresler.

Yeni adres ekleme yetkisinin kimde olduğu ayrıca tanımlanmalıdır.

11. Departman ve Masraf Merkezi

Kurumsal satın alma sürecinde siparişin departman, proje veya masraf merkeziyle ilişkilendirilmesi gerekebilir.

• Departman.
• Proje kodu.
• Masraf merkezi.
• Satın alma referansı.
• Müşteri sipariş numarası.

Bu alanlar ERP'ye aktarılacaksa kod sözlüğü iki sistem arasında uyumlu olmalıdır.

12. Sipariş Yetki Limiti

Kullanıcının sipariş oluşturma veya onaylama yetkisi tutara göre sınırlandırılabilir.

13. Çok Kademeli Onay

1. Kullanıcı sepeti sipariş talebine dönüştürür.
2. Sistem tutar/şube/departman kuralını değerlendirir.
3. İlk onaylayıcıya görev oluşturur.
4. Gerekirse ikinci onaya yönlendirir.
5. Tüm onaylar tamamlandığında ticari kontroller yeniden yapılır.
6. Sipariş kesinleşir.

Onay beklerken fiyat, stok veya limit değişebileceği için kesinleşme öncesi yeniden doğrulama gerekir.

14. Onay Kuralı Örnekleri

• Tutar > 50.000 TL → müdür.
• Tutar > 250.000 TL → müdür + finans.
• Belirli kategori → teknik onay.
• Yeni teslimat adresi → şirket yöneticisi.
• Limit aşımı → satıcı tarafı finans onayı.

Kural motorunda çakışan koşulların sırası ve birlikte uygulanma biçimi tanımlanmalıdır.

15. Sipariş Talebi ile Kesin Siparişi Ayırın

Şirket içi onay bekleyen sepet henüz satıcıya verilmiş kesin sipariş olmayabilir. Talep, onay ve sipariş durumlarını ayrı modellemek raporlama ve stok davranışını netleştirir.

16. Kullanıcı Daveti

1. Şirket yöneticisi e-posta/kullanıcı bilgisini girer.
2. Rol ve şube seçer.
3. Sistem süreli davet üretir.
4. Kullanıcı kimliğini doğrular ve hesabını oluşturur.
5. Atanan yetkilerle şirkete bağlanır.

Daveti yanlış kişiye göndermenin etkisini azaltmak için süre, tek kullanımlık token ve gerektiğinde yönetici iptali kullanılmalıdır.

17. Kullanıcı Ayrıldığında

Çalışan şirketten ayrıldığında şirket hesabı ve ticari geçmiş silinmemelidir.

1. Kullanıcı erişimini kapat.
2. Aktif oturumları sonlandır.
3. Bekleyen onay görevlerini devret.
4. Kritik işlem geçmişini koru.
5. Yeni sorumlu gerekiyorsa ata.

18. Hesap Ele Geçirme Riskleri

B2B hesapları yüksek tutarlı sipariş, adres ve finans bilgisi içerdiğinden güvenlik etkisi yüksektir.

• Güçlü parola.
• Çok faktörlü doğrulama değerlendirilebilir.
• Yeni cihaz/olağandışı giriş sinyalleri.
• Kritik işlemde yeniden doğrulama.
• Oturum yönetimi.
• Audit log.

19. Kritik İşlemler

• Yeni şirket yöneticisi atama.
• Kullanıcı rolünü yükseltme.
• Yeni teslimat adresi ekleme.
• Ödeme/hakediş bilgisi değiştirme varsa.
• Yüksek tutarlı sipariş onayı.
• Cari/finansal belge erişimi.

Bu işlemlerde ek doğrulama veya ikinci onay risk profiline göre uygulanabilir.

20. Audit Log

• Kim giriş yaptı?
• Kim kullanıcı ekledi?
• Rolü kim değiştirdi?
• Siparişi kim oluşturdu?
• Kim onayladı/reddetti?
• Adres ne zaman değişti?
• Hangi ticari bilgi hangi kaynaktan güncellendi?

Audit kaydı destek, güvenlik ve kurumsal müşteri uyuşmazlıklarında olay zincirini açıklayabilmelidir.

21. ERP'den Gelen Müşteri Verisi

Müşteri ana verisi ERP'den geliyorsa portalda hangi alanların düzenlenebilir olduğu sınırlandırılmalıdır.

22. Veri Senkronizasyonu

• ERP → portal: cari, limit, fiyat grubu, bakiye.
• Portal → ERP: web siparişi, yeni teslimat bilgisi iş modeline göre.
• Çift yönlü: yalnız açık sahiplik kuralıyla.

Senkronizasyon hatası kullanıcıya yanlış fiyat veya limit gösterebileceği için izlenebilir olmalıdır.

23. Müşteri Hesabı KPI'ları

• Davet → aktif kullanıcı oranı.
• Aktif şirket oranı.
• Şirket başına aktif kullanıcı.
• Onay süresi.
• Yetki kaynaklı destek talebi.
• İlk dijital siparişe kadar süre.
• Pasifleşen müşteri hesabı.

24. Kabul Testleri

1. Şube kullanıcısı başka şubenin siparişini göremiyor.
2. Satın alma kullanıcısı finans belgesine yetkisiz erişemiyor.
3. Onay eşiği doğru kişiye görev oluşturuyor.
4. Kullanıcı ayrıldığında eski oturum çalışmıyor.
5. ERP cari eşlemesi doğru şirkete bağlı.
6. Rol değişikliği audit log'a yazılıyor.
7. Onay beklerken değişen fiyat kesinleşmede yeniden doğrulanıyor.

Uygulama: Kurumsal Hesap ve Yetki Matrisi

1. Şirket ana kayıt alanlarını yazın.
2. ERP cari eşleştirme anahtarını belirleyin.
3. Müşteri durumlarını tanımlayın.
4. Kullanıcı rollerini oluşturun.
5. Her rol için izinleri işaretleyin.
6. Şube erişim kurallarını yazın.
7. Sipariş onay eşiklerini belirleyin.
8. Kritik işlemleri listeleyin.
9. Offboarding akışını yazın.
10. Audit gerektiren olayları belirleyin.
11. Yedi kabul testini kendi yapınıza uyarlayın.

Kurumsal müşterinin kim olduğunu ve kimlerin hangi yetkiyle işlem yapacağını kurduk. Sonraki derste bu müşteriye hangi ürünün hangi fiyat ve iskonto kuralıyla gösterileceğini tasarlayacağız.