B2B dijital katalog ve sipariş portalı: hangi aşamada hangisi gerekir?
Ürün kataloğu, teklif talebi ve müşteri sipariş portalının farklarını görün; veri, yetki ve ekip akışına göre ilk sürümünüzü belirleyin.
B2B satış yapan bir işletmede dijital katalog ile sipariş portalı farklı işleri çözebilir. Katalog, müşterinin doğru ürünü ve teknik bilgiyi bulmasına yardım eder. Teklif akışı, seçilen ürün ve ihtiyaçların satış ekibine iletilmesini sağlar. Sipariş portalı ise müşterinin hesabına, yetkilerine ve işletmenin kurallarına bağlı işlemler içerir. İlk karar, bu üç kapsamdan hangisinin bugünkü sorunu karşılayacağıdır.
Müşterinin takıldığı noktayı bulun
Ekibiniz aynı ürün belgelerini tekrar tekrar mı gönderiyor? Müşteriler ürün kodlarını karıştırıyor mu? Gelen taleplerde adet veya teknik özellik eksik mi? Yoksa asıl sorun, kesinleşen siparişin durumunu müşteriye açıklamak mı? Bu sorunları ayrı yazın. Birinin çözümü ayrıntılı katalog, diğerinin çözümü talep formu veya mevcut sistemdeki bilginin müşteriye açılması olabilir.
Satış temsilcilerinden ve operasyon ekibinden gerçek örnekler isteyin; müşteri bilgilerini kamuya açmadan sürecin adımlarını inceleyin. İlk sürüm için tek bir işin baştan sona tamamlanmasını hedefleyin. Ürünü bulma sorunu çözülmeden kapsamlı bir sipariş ekranı eklemek, temel veri eksikliğini ortadan kaldırmaz.
Katalog için tutarlı ürün verisi hazırlayın
Her ürünün değişmeyen bir kodu, anlaşılır adı ve ait olduğu kategori olmalıdır. Varyantlar, ölçü birimleri, paket bilgileri ve teknik belgeler düzenli tutulmalıdır. Ürün özellikleri yalnız PDF içinde bulunuyorsa müşterinin farklı ürünleri karşılaştırması zorlaşabilir. Gerekli özellikleri sayfada gösterip belgenin tamamını ayrıca sunmayı değerlendirin.
Ürün verisinin sahibi belli olsun. Satış ekibi açıklamayı, teknik ekip özellikleri ve başka bir sistem stok bilgisini yönetiyorsa hangi alanın nereden geldiğini yazın. Aynı bilgiyi iki yerde bağımsız güncellemek zamanla çelişki oluşturabilir. İlk veri aktarımında eksik veya yinelenen kodların nasıl ele alınacağı da planlanmalıdır.
Teklif talebiyle kesin siparişi ayırın
Müşteri birkaç ürünü seçip ihtiyacını ekibinize gönderebilir. Bu işlem, fiyatın onaylandığı veya ürünün ayrıldığı anlamına gelmeyebilir. Arayüzde talebin hangi aşamada olduğu anlaşılmalıdır. Satış ekibinin fiyat, teslim ve uygunluğu değerlendirmesi gerekiyorsa sonuç ekranında bunun bir teklif talebi olduğu açık yazılmalıdır.
Seçilen ürünlerin kodları ve adetleri taleple birlikte kaydedilmelidir. Müşterinin eklediği açıklamanın, satış ekibinin yaptığı değişikliğin ve son teklifin birbirine karışmaması gerekir. İlk sürümde bu kayıt düzeni, otomatik fiyat hesaplamadan daha öncelikli olabilir. İşletmenizde kesinleşen siparişin hangi işlemle oluştuğunu sorumlu ekiplerle ayrıca tanımlayın.
Portal gerekiyorsa müşteri rollerini netleştirin
Giriş yapılan bir portalda her müşteri aynı veriyi görmemelidir. Bir firmada talebi oluşturan kişiyle onaylayan kişi farklı olabilir. Satış temsilcisi kendi müşterilerini, operasyon ekibi ise ilgili siparişleri takip edebilir. Kim hangi kaydı görecek, oluşturacak veya değiştirecek sorularının cevabını rol tablosuyla yazın.
Müşteriye özel fiyat listesi, iskonto, ödeme koşulu veya belge görünürlüğü varsa bu kurallar kapsamı büyütür. Özellikleri yalnız isimleriyle sıralamayın; bir örnek müşteri hesabında nasıl çalışacaklarını anlatın. Şirketten ayrılan kullanıcının erişimi, yanlış firmaya bağlanan hesap ve iptal edilen işlem gibi durumları da kabul senaryolarına ekleyin.
Örnek rol tablosunu günlük iş akışıyla sınayın
Aşağıdaki tablo kurmaca bir B2B planlama örneğidir. DoktorWeb'in hazır portal özelliği veya gerçek bir müşterinin erişim düzeni olarak okunmamalıdır. Kendi işletmenizde gerekli rolleri ve kayıt sınırını ayrıca belirleyin.
| Rol | Görülebilecek kayıt | Yapılabilecek iş | Teslimde denenmesi gereken sınır |
|---|---|---|---|
| Müşteri talep hazırlayan | Yetkili olduğu firmaya ait ürün ve talepler | Ürün/adet seçip teklif talebi gönderme | Başka firmanın talebi doğrudan adresle de açılamaz |
| Müşteri onaylayan | Kendi firmasının onaya gönderilen talepleri | İşletmenin belirlediği adımda onay veya iade | Hazırlayan kişinin şirket içi onay yetkisi yoksa onaylayamaz |
| Satış temsilcisi | Sorumlu olduğu müşteri kayıtları | Teklif hazırlama ve talebin durumunu güncelleme | Yetkisi dışında kalan müşterinin fiyatı görünmez |
| Operasyon sorumlusu | İşletmenin tanımladığı kesinleşmiş siparişler | Kararlaştırılan teslim/işlem durumunu kaydetme | Teklif talebi kendiliğinden kesin siparişe dönüşmez |
Örnek bir akışı kağıt üzerinde yürütün: müşteri ORNEK-01 kodlu üründen istediği adedi seçer → teklif talebi kaydolur → satış ekibi uygunluk ve koşulları değerlendirir → müşteri kararlaştırılan yöntemle teklifi kabul eder → işletmenin onay adımı tamamlanınca sipariş oluşur. Bu ürün kodu ve akış da örnektir; stok ayrılması veya ödeme alınması gibi ek adımlar yalnız sizin sürecinizde varsa eklenmelidir.
Kabulde aynı akışı iki ayrı müşteri firmasıyla ve farklı rollerle deneyin. Teklifin beklediği aşama, yetkisiz erişim ve yinelenen gönderim sonucu anlaşılır olmalıdır. İlk kapsamı yazarken teklif karşılaştırma şablonundaki yönetim ve işlev maddelerini bu akışla doldurabilirsiniz.
Entegrasyonun veri kaynağını ve hata davranışını konuşun
Portalın stok veya sipariş bilgisi mevcut bir sistemden gelecekse önce erişim yöntemini inceleyin. Anlık bağlantı mı, belirli aralıklarla veri aktarımı mı yapılacak? Ürün kodları iki sistemde aynı mı? Güncellemeyi hangi sistem başlatacak? Bu sorular teknik tasarımı ve işletim sorumluluğunu etkiler.
Bağlantı kesildiğinde eski bilgiyi yeniymiş gibi göstermek yerine verinin durumu ve işlem sonucu anlaşılır olmalıdır. Sipariş gönderimi tekrarlandığında aynı kaydın ikinci kez oluşmaması, başarısız işlemin ilgili ekibe görünmesi ve sonucun takip edilebilmesi önemlidir. Bunları yalnız teknik ayrıntı olarak bırakmayın; teslimde gösterilecek iş senaryolarına dönüştürün.
İlk sürümü küçük ama tamamlanmış bir akışla kurun
Aşamalı ilerlemek için şu kapsamları değerlendirebilirsiniz:
- Dijital katalog: Kategori, ürün, teknik özellik, belge ve güncelleme yönetimi.
- Teklif akışı: Ürün seçimi, adet, açıklama, kayıt ve satış ekibinin takibi.
- Müşteri portalı: Hesaplar, müşteri bazlı erişim ve kararlaştırılan işlem durumları.
- Entegrasyon: Doğrulanan veri kaynağı, eşleştirme, hata ve tekrar deneme akışı.
Bu sıralama zorunlu bir ürün yol haritası değildir. Mevcut sisteminiz katalog işini zaten karşılıyorsa başka bir sorundan başlayabilirsiniz. Seçtiğiniz ilk kapsamın günlük kullanımda tamamlanmasını ölçün: müşteri doğru ürünü bulabiliyor mu, talep eksiksiz kaydoluyor mu, ekip sonucu takip edebiliyor mu?
Son olarak ürün ve müşteri verisinin bakımı, destek sorumluluğu, eğitim ve sonraki geliştirmeler için bir düzen oluşturun. Hangi tür çözüme ihtiyacınız olduğuna karar verirken kurumsal site mi, özel yazılım mı rehberimizi inceleyebilirsiniz. Ürün adedi, mevcut sistem ve ilk çözmek istediğiniz işi planlama formunda paylaşarak kurumsal web ve özel yazılım kapsamını birlikte netleştirebiliriz.
Yazının başına dön ↑