B2B Müşteri Portalı: Self Servis İçin Veri ve Yetki Tasarımı

Portalın ilk üç işini seçin

Başlangıçta bütün CRM ekranlarını dışarı taşımayın. Müşteri en sık hangi iş için ekibinizi arıyor: sipariş durumu, belge indirme, teklif talebi veya destek kaydı? İlk sürümü bu işlerden birkaçına odaklamak, karmaşık bir portalı boş içerikle açmaktan daha anlamlı olabilir.

Her iş için başarılı sonucun ne olduğunu yazın. “Belgeleri görebilir” yerine “kendi şirketinin ilgili siparişine ait güncel belgeyi bulup indirebilir” tanımı daha test edilebilirdir. Portalın hangi bilgiyi yalnızca gösterdiği, hangi bilgiyi değiştirmeye izin verdiği de ayrı belirtilmelidir.

Kullanıcı ile şirket ilişkisini açık kurun

Bir şirkette satın alma, muhasebe ve şube sorumluları farklı erişim ihtiyaçlarına sahip olabilir. Tek şirket hesabını herkesin paylaşması, işlem sorumluluğunu belirsizleştirir. Kullanıcıların şirket ve alt birim ilişkisini kurun; rol ve kayıt kapsamını birlikte değerlendirin.

Microsoft güvenlik rolleri dokümantasyonu kayıt erişiminin farklı kapsamlarda tanımlanabileceğini gösterir. [1] Kendi portalınızda müşterinin kendi şirketini seçebilmesi, başka şirket verisine erişim hakkı doğurmamalıdır. Şirket bağlamı sunucu tarafında doğrulanmalıdır.

Örnek: merkez ve şubeler aynı portalı kullanıyor

Varsayımsal bayinin merkez satın alma ekibi bütün şubelerin siparişlerini görürken şube çalışanı sadece kendi şubesine erişiyor. Muhasebe kullanıcısı belgeleri görebilir ama yeni sipariş veremeyebilir. Bu farklar menü tasarımından önce bir yetki tablosunda çözülmelidir.

Bu önerilen yapı her işletmeye uymayabilir. Ortak girişim veya dış danışman gibi istisnai ilişkiler varsa kullanıcıyı bir şirkete zorla sıkıştırmak yerine erişim modelini ayrıca tasarlayın.

Görünen verinin güncelliğini açıklayın

Portal ERP’den gelen durumu gösteriyorsa veri anlık olmayabilir. Kaynağın son güncelleme zamanı ve bekleyen işlemler görünür olsun. Müşteriye eski bilgi üzerinden kesin teslim veya bakiye sonucu göstermeyin. Kaynak sistem geçici olarak erişilemediğinde son bilinen veri ile belirsizlik birlikte sunulabilir.

İç durumları müşteri diline çevirin. “Senkronizasyon bekliyor” müşterinin sorusunu cevaplamaz. Hangi işin alındığı, hangi aşamanın beklediği ve gerektiğinde nasıl destek isteyebileceği açık olsun. Teknik hata kodları destek için saklanabilir ama kullanıcı mesajının tek içeriği olmamalıdır.

Self servisin başarısız olduğu yolu da tasarlayın

Kullanıcı belgeyi bulamazsa bağlamını kaybetmeden destek talebi açabilsin. İlgili sipariş referansı talebe eklenebilir; gereksiz kişisel bilgi tekrar istenmemelidir. W3C form rehberi, alanların anlaşılır etiketlenmesi ve hata durumlarının açıklanması konusunda temel ilkeler sunar. [2]

Dosya yükleme veya adres değişikliği gibi işlemlerde doğrulama, yetki ve onay ihtiyacı ayrı ele alınmalıdır. Müşterinin değişikliği kaydetmesi ile işletmenin uygulaması farklı aşamalar olabilir. Portal bu farkı “başarılı” mesajıyla gizlememelidir.

Kullanıcı devrini ve kapanışını planlayın

Müşteri şirketinden ayrılan kişinin erişimi nasıl kaldırılacak? Şirket yöneticisi yeni kullanıcı davet edebiliyor mu ve hangi yetkileri verebiliyor? Davet süresi, kabul işlemi ve yanlış kişiye gönderim senaryoları test edilmelidir.

Teslimde farklı şirketlerden sentetik kullanıcılarla veri ayrımı kontrolü yapın. Doğrudan belge adresi, arama sonucu, bildirim ve dışa aktarma yolları da aynı sınıra uymalıdır. Portalın açılması değil, doğru müşterinin doğru işi tamamlaması başarı ölçütü olsun.

Sık sorulan sorular

### İç yönetim panelini gizli menülerle müşteriye açabilir miyim? Teknik olarak mümkün görünen bu yaklaşım gereksiz veri ve yetki riskleri yaratabilir. Müşteri görevlerine özel arayüz ve sunucu tarafı erişim modeli değerlendirilmelidir.

Portal destek ekibini tamamen gereksiz kılar mı?

Hayır. İstisna ve belirsiz durumlar devam eder. Portalın amacı tekrar eden işleri kolaylaştırmak ve gerektiğinde destek ekibine doğru bağlamı taşımaktır.