Bir bayi siparişi çoğu zaman ürün seçimiyle bitmez. Hangi fiyat listesinin geçerli olduğu, kimin onay vereceği, hangi adrese sevk yapılacağı ve stok bilgisinin ne kadar güncel olduğu da siparişin parçasıdır. Bu ayrıntılar farklı e-postalarda dolaşıyorsa satış ekibi sipariş almaktan çok kayıtları uzlaştırmaya zaman ayırabilir.
B2B bayi portalı, bu kararları müşterinin ve operasyon ekibinin birlikte takip edebileceği bir akışta toplar. Amaç yalnızca çevrim içi sepet sunmak değildir. Siparişin kimden geldiğini, hangi koşullarla değerlendirildiğini ve nerede beklediğini anlaşılır kılmaktır.
Aşağıdaki örnekler varsayımsal bir toptancı üzerinden anlatılır. Fiyat, tasarruf veya başarı oranı iddiası içermez; portal kapsamını somutlaştırmak için kullanılabilir.
Şirket, şube ve kullanıcıyı ayrı düşünün
Bir şirketin birden fazla teslimat noktası, her noktanın birden fazla satın alma kullanıcısı olabilir. Kullanıcıyla şirketi tek kayıt gibi tasarlamak, çalışan değiştiğinde sipariş geçmişini ve erişim yetkisini yönetmeyi zorlaştırır.
Örneğin merkez ofis satın alma koşullarını belirlerken bölge deposu yalnızca kendi siparişlerini oluşturabilir. Portalda şirket hesabı, teslimat noktası ve işlem yapan kişi ayrı tutulursa bu kural daha açık uygulanabilir.
Bu ayrımın ürünlerde de karşılığı vardır: Shopify'ın B2B belgelerinde şirket, şirket lokasyonu ve müşteri farklı kavramlardır; lokasyonların fiyatlama ve ödeme koşulları ayrışabilir. Bu örnek bir veri modeli yaklaşımıdır, her işletmenin aynı ürünü kullanması gerektiği anlamına gelmez. Shopify: şirketler ve müşteriler.
Yetkiyi görünen menüyle sınırlamayın
Bir bayinin diğer bayinin sipariş numarasını değiştirilmiş bağlantıyla açamaması gerekir. Her kayıt isteğinde şirket ilişkisi ve işlem yetkisi sunucuda kontrol edilmelidir. Bu yaklaşım, OWASP'ın her istekte yetkilendirme kontrolü önerisiyle uyumludur. OWASP: yetkilendirme.
Kendi işletmeniz için üç rol tanımlayarak başlayabilirsiniz: sipariş hazırlayan, onaylayan ve izleyen. Kullanıcıların işlerini yapmak için gerçekten hangi işlemlere ihtiyacı olduğunu operasyon ekibiyle doğrulayın.
Katalog ve fiyatın hangi anda geçerli olduğunu belirleyin
Toptan satışta ürün görünürlüğü, minimum sipariş miktarı, koli içi adet ve fiyat birimi önemlidir. “12 adet” ifadesi on iki ürün mü, on iki koli mi? Sepette birim açık değilse doğru hesaplanan fiyat bile yanlış siparişe dönüşebilir.
Ürün kartında satış birimi ve artış adımı gösterin. Örneğin altılı koliyle satılan bir üründe adet seçiminin altının katlarıyla ilerlemesi iş kuralı olabilir. Ancak müşteri hizmetleri bölünebilir koliye izin veriyorsa bunun yetkili bir istisna akışı bulunmalıdır.
Fiyatın hangi aşamada sabitlendiğini de yazın. Sepette görülen fiyat, sipariş gönderildiğinde değişmişse kullanıcıya değişikliği açıklayın ve gerektiğinde yeniden onay alın. Sonradan yalnızca güncel ürün fiyatına bakarak eski sipariş toplamını üretmeyin; siparişin kabul edilen fiyat bilgisini koruyun.
Sipariş durumlarını gerçek operasyonla eşleştirin
“Bekliyor” durumu tek başına yetersizdir. Bayi siparişinin yönetici onayını mı, stok ayrılmasını mı, ödeme kontrolünü mü beklediği anlaşılmalıdır.
Örnek akış şöyle kurulabilir:
- Bayi ürünleri taslak siparişe ekler.
- Portal miktar, teslimat adresi ve fiyat koşullarını kontrol eder.
- Gerekliyse bayi yöneticisi siparişi onaylar.
- Sipariş işletmenin operasyon sistemine aktarılır.
- Stok ve ticari koşullar doğrulanınca sipariş kabul edilir.
- Hazırlama ve sevkiyat bilgileri bayiye gösterilir.
Bu sıralama örnektir. Her işletmede ödeme veya stok kontrolü aynı aşamada yapılmaz. Tasarıma geçmeden önce mevcut işlemi takip edin ve gereksiz onayları kaldırıp kaldıramayacağınızı değerlendirin.
Onay değişikliği ve iptali unutmayın
Onaylanan siparişe sonradan ürün eklenebilecek mi? Eklenirse ilk onay geçerli kalacak mı? Hazırlanmaya başlanmış bir siparişin iptali kimden yetki gerektiriyor? Bu soruların yanıtı hem arayüzü hem kayıt geçmişini etkiler.
Örneğin tutarı artıran değişiklik yeniden onay gerektirirken teslimat notunun düzeltilmesi gerektirmeyebilir. Kuralı örneklerle test edin. Bayiye “işlem başarısız” yerine neyin değiştiğini ve hangi adımı atabileceğini söyleyin.
ERP bağlantısında aktarım ile kabulü ayırın
Portalın “sipariş gönderildi” demesi, ERP'nin siparişi kabul ettiği anlamına gelmeyebilir. İstek ulaşıp doğrulamadan dönmüş veya yanıt ağda kaybolmuş olabilir. Portalda aktarım durumu ile ticari sipariş durumunu ayrı tutun.
Her sipariş için sistemler arasında izlenebilir bir referans kullanın. Aynı kaydı tekrar gönderme ihtimali varsa, tekrar denemenin yeni sipariş yaratmasını önleyecek bir anlaşma kurun. ERP bunu doğal olarak desteklemiyorsa ara katmanda eşleştirme ve tekrar kontrolü gerekebilir.
Kaynak sistem ve hata sorumlusu belli olsun
Stok ERP'den, ürün açıklaması içerik sisteminden, sevkiyat taşıyıcıdan geliyorsa her alanın kaynağını belgeleyin. Portalın hangi bilgiyi değiştirebileceği ve hangisini yalnızca göstereceği açık olsun.
Aktarılamayan siparişler görünür bir iş listesine düşsün. Operasyon çalışanı hatanın nedenini, son deneme zamanını ve güvenli tekrar seçeneğini görsün. Teknik hata ayrıntılarını bayi ekranına taşımadan anlaşılır durum bilgisi sunun.
Güncelliği önemli veride zaman bilgisini gösterin. Eski stok bilgisini kesin teslim sözü gibi sunmak yerine tahmini uygunluğu, teyit gereken durumları ve alternatifleri ayırın.
İlk sürümü tek bir sipariş senaryosunda sınayın
Örnek pilot için standart fiyatla çalışan, tek teslimat noktalı ve onay akışı basit bir bayi grubu seçilebilir. Karmaşık bütün istisnaları ilk günden kapsamak yerine seçilen akışın baştan sona çalıştığını gösterin.
Pilotun başında ölçüm tanımlarını yazın: siparişin hazırlanması ne zaman başlıyor, hangi anda bitiyor, hata düzeltmesi nasıl sayılıyor? Telefonla çözülen işlemleri de kaydedin. Sadece portal içindeki tıklamaların azalması, toplam operasyon yükünün azaldığını kanıtlamaz.
İlk siparişte yardım gerektiren adımları gözleyin. Bayi fiyatı anlıyor mu, koli seçimini fark ediyor mu, eski siparişini kopyalarken stok değişikliğini görüyor mu? Sorunun eğitim eksikliği mi, belirsiz arayüz mü olduğunu ayırın.
Uygulama kontrol listesi
- Şirket, lokasyon ve kullanıcı ilişkilerini tanımlayın.
- Bayiye özel katalog ve fiyat kurallarını örnek veriyle sınayın.
- Satış birimini ve minimum miktarı ürün seçiminde gösterin.
- Onay, stok, ödeme ve sevkiyat durumlarını ayırın.
- Aynı siparişin tekrar aktarılması senaryosunu test edin.
- Hatalı ERP işlemlerine sorumlu ve takip ekranı belirleyin.
- Değişiklik, iptal ve iade akışlarını belgeleyin.
- Pilot öncesi ve sonrası aynı göstergeleri ölçün.
WebWizz ile bayi portalını planlarken örnek bir sipariş ve mevcut sistemlerinizi iletişim üzerinden paylaşabilirsiniz. Görüşmeyi gerçek bir siparişin geçtiği adımlar üzerinden yürütmek, ilk sürümün sınırlarını netleştirir.
Sık sorulan sorular
Bayi portalı için mevcut ERP'yi değiştirmek gerekir mi?
Her zaman gerekmez. Önce ERP'nin erişim yöntemleri, sipariş kuralları ve veri güncelliği incelenmelidir. Portal mevcut sistemi tamamlayabilir; desteklenmeyen bağlantılar ise ek geliştirme gerektirebilir.
Normal e-ticaret sitesine bayi girişi eklemek yeterli mi?
Basit gereksinimlerde yeterli olabilir. Şubeye göre yetki, fiyat listesi, onay, vadeli koşullar ve çoklu sevkiyat varsa bunların birlikte nasıl işleyeceği ayrıca tasarlanmalıdır.
Stok portalda anlık görünmeli mi?
İşin ihtiyacına bağlıdır. Kritik olan güncellik beklentisinin açık olmasıdır. Son güncelleme zamanı ve sipariş kabul kontrolü belirlenmeden “anlık stok” ifadesi kullanışlı bir güvence değildir.
Bayi geçmiş siparişini tek tıkla tekrar verebilir mi?
Bu seçenek tasarlanabilir; ancak eski fiyat, kapanan ürün veya değişen koli miktarı yeniden doğrulanmalıdır. Kopyalama işlemi geçmiş siparişi yeni koşullarda değerlendirme adımını atlamamalıdır.