B2B Bayi Sipariş Portalı: Fiyat, Stok ve Onay Akışı Nasıl Kurulur?

Bayileriniz siparişi telefon, e-posta ve mesajla gönderiyor; satış ekibiniz ürün kodlarını tek tek sisteme mi aktarıyor? B2B bayi sipariş portalı, yetkili alıcıların kendi koşullarına uygun ürünleri görüp sipariş oluşturmasını sağlayabilir. Bu rehber, portalın kapsamını katalogdan sevkiyata kadar hangi iş kurallarıyla belirlemeniz gerektiğini anlatır.

Bayi portalı hangi işi kolaylaştırmalı?

Bir yedek parça toptancısını düşünün. Bayi ürün kodunu mesajla gönderiyor, satış temsilcisi fiyatı kontrol ediyor, stok için depoyu arıyor ve siparişi yeniden yazıyor. Portal tasarımına başlamadan önce bu adımların hangisinin standart, hangisinin insan kararı gerektirdiğini belirleyin.

İlk hedef, bayinin doğru ürünü bulup geçerli koşullarla talep oluşturması olabilir. Sistem bütün pazarlık ve istisnaları ilk günden otomatik çözmek zorunda değildir. Özel işlem gerektiren talebin doğru temsilciye aktarılması da planlanabilir bir akıştır.

“Bayi giriş ekranı” tek başına kapsam tanımlamaz. Hangi müşteri hangi fiyatı görecek, hangi depodan uygunluk bilgisi alacak ve sipariş ne zaman kesinleşecek? Bu soruların yanıtı portalın iş modelini oluşturur.

Ürün kataloğunda hangi bilgiler gerekli?

Bayi ürünü isimle değil, kod veya teknik özellik üzerinden arıyor olabilir. Mevcut müşterilerinizin arama biçimini inceleyin. Kategori, uyumlu model, ölçü ve ambalaj gibi alanları buna göre tasarlayın; gereksiz sütunlarla katalogu ağırlaştırmayın.

Ürün kodu bütün sistemlerde aynı anlamı taşımalıdır. Aynı ürünün depoda farklı, portalda farklı kodla bulunması eşleştirme sorunları yaratabilir. Birden fazla kod zorunluysa aralarındaki ilişki açıkça tutulmalıdır.

• Kimlik: Ürün kodu ve anlaşılır isim.
• Seçim bilgisi: Varyant, ölçü, model veya teknik özellik.
• Sipariş birimi: Adet, koli, paket veya ilgili ölçü birimi.
• Koşullar: Görünen fiyatın ve uygunluk bilgisinin kapsamı.
• Yardım: Gerektiğinde temsilciye sorulacak ürün sorusu.

Görsel ve açıklamaların güncelliği için sorumlu belirleyin. Ürün verisinin kaynağı mevcut kurumsal sistemse portalda yapılan değişikliğin oraya dönüp dönmeyeceğini de kararlaştırın. Aynı alanı iki sistemde bağımsız güncellemek tutarsızlık yaratabilir.

Bayiye özel fiyat ve erişim nasıl planlanır?

Bütün bayilerin aynı koşullarla çalışmadığı işletmelerde fiyat listesi, iskonto grubu veya sözleşmeli ürün kapsamı bulunabilir. Önce mevcut satış kurallarını yazın. Çalışanın her seferinde yorumladığı belirsiz bir kuralı doğrudan yazılıma aktarmayın.

Örneğin belirli grubun belirli ürünleri görmesi, bir bayinin birden fazla alıcı hesabı kullanması veya satın alma yöneticisinin siparişi onaylaması gerekebilir. Kullanıcı hesabı ile bağlı şirket kaydını ayırın. Bayi çalışanı ayrıldığında şirketin sipariş geçmişini kaybetmeden erişim kapatılabilmelidir.

Sunucunun erişimi denetlemesi gerekir; yalnızca ekranda fiyatı gizlemek yeterli değildir. Bu ilke OWASP'ın yetkilendirme rehberinde de ele alınır; erişim 28 Ekim 2026. Teklifinize başka bayinin siparişine erişmeyi deneme gibi kabul senaryoları ekleyin.

Görünen stok, kesin sipariş anlamına gelir mi?

Portal stok bilgisini belli aralıklarla alıyorsa ekrandaki miktar merkezdeki en son değişikliği içermeyebilir. Sipariş anında yeniden kontrol gerekip gerekmediğini belirleyin. Müşteriye gösterilen bilgi ile işletmenin taahhüdü aynı şeymiş gibi davranmayın.

Stok rezervasyonu ile sevkiyatı ayrı olaylar olarak düşünün. Bayinin sepetine eklediği ürünün gerçekten ayrılıp ayrılmadığı açık olmalıdır. Aksi hâlde farklı bayiler aynı uygunluk bilgisine dayanarak çelişen beklentiler oluşturabilir.

Sipariş onayı hangi aşamada verilmeli?

Bazı işletmelerde her sipariş satış ekibinin kontrolünden geçer. Bazılarında yalnızca belirli koşulu aşan işlemler için onay gerekir. Kuralları siparişin toplamı, ürün türü veya müşteri durumu gibi somut bilgilerle tanımlayın.

Onay bekleyen sipariş değiştirilebiliyorsa eski onayın ne olacağını belirleyin. Ürün veya miktar değiştiğinde yeniden değerlendirme gerekebilir. Panelde siparişin hangi sürümünün incelendiği anlaşılmalıdır.

Bayinin ek bilgi vermesi gerekiyorsa bekleme nedeni açıkça gösterilsin. Sadece “işlemde” yazan ekran, müşterinin tekrar temsilciyi aramasına yol açabilir. İstenen bilgi ve sonraki adım görünür olduğunda portal daha işlevli hâle gelir.

Mevcut sistemle hangi veriler paylaşılmalı?

Ürün, fiyat, stok, müşteri ve sipariş verilerini ayrı ayrı ele alın. Her veri için asıl kaynağı, aktarım yönünü ve güncelleme koşulunu yazın. “ERP bağlantısı dahil” gibi genel ifade yerine veri eşleştirme tablosu isteyin.

Bağlantı kesildiğinde siparişin portalda mı, merkezde mi oluştuğu görülebilmelidir. Tekrar gönderim aynı siparişi çoğaltmamalı; başarısız aktarımlar yetkili kişinin inceleyebileceği listede bulunmalıdır. Hata takibi entegrasyonun sonradan eklenecek ayrıntısı değildir.

Hazır portal mı, özel geliştirme mi?

Önce mevcut kurumsal sisteminizin sunduğu bayi portalını ve hazır ürünleri inceleyin. Kendi ürünlerinizle, müşteri grubunuzla ve sipariş senaryonuzla demo isteyin. Katalog sayfasının açılması, özel fiyat veya kısmi sevkiyat ihtiyacının karşılandığını göstermez.

Özel geliştirme, doğrulanmış kurallar hazır seçeneklerle karşılanamadığında değerlendirilebilir. Değişiklik sıklığı, entegrasyon erişimi ve bakım düzeni de karara dahil olmalıdır. Hazır altyapı ve özel yazılım karşılaştırmasındaki kapsam yaklaşımını burada da kullanabilirsiniz.

Müşterilerinizin yalnızca masaüstü kullandığını varsaymayın. Depoda veya mağazada telefondan tekrar sipariş oluşturmak gerekebilir. Mobil akışı ürün bulma, miktar girme ve siparişi kontrol etme görevleriyle deneyin.

İlk sürümün bütçesi ve pilotu nasıl hazırlanır?

İlk sürüme sınırlı ürün grubu, belirli bayi grubu ve temel sipariş akışı alınabilir. Gelişmiş kampanya, kapsamlı finans ekranları ve yeni dağıtım modellerini gerekirse ayrı aşamada değerlendirin. İlk kapsamın hangi işi tamamladığı belli olsun.

Varsayımsal 35-55 kişi-gün iş ve varsayımsal 6.000 TL kişi-gün bedeliyle 210.000-330.000 TL geliştirme hesabı oluşur. Bu tutarlar piyasa fiyatı veya Navdion teklifi değildir. KDV, lisans, veri temizliği, altyapı ve kapsam dışı bağlantılar ayrıca değerlendirilmelidir.

Pilot için örnek olarak seçilmiş birkaç bayiyle iki haftalık kullanım dönemi planlayabilirsiniz. Bu süre standart değildir; sipariş sıklığına göre değişir. Hangi sipariş kanalının asıl kaynak olduğunu belirtin ve eski kanallardan gelen taleplerin iki kez işlenmesini önleyin.

Portalın çalıştığını hangi senaryolar gösterir?

Doğru fiyatla sipariş, yetkisiz ürüne erişim, stok değişikliği, iptal, kısmi sevkiyat ve bağlantı hatasını deneyin. Bayi ile işletme panelinin aynı durumu gösterip göstermediğini kontrol edin. Teknik başarı mesajı, operasyonun tamamlandığı anlamına gelmeyebilir.

Ölçümde yalnızca giriş yapan bayi sayısına bakmayın. Tamamlanamayan siparişler, tekrar bilgi isteyen temsilciler ve elle düzeltilen kayıtları izleyin. Sorunların hangi adımda ortaya çıktığını görmek, sonraki geliştirme kararlarını destekler.

İşletmenin hazırlığını e-ticaret başlangıç rehberindeki ürün ve operasyon kontrolüyle birlikte değerlendirin. B2B akışın tüketici mağazasından farklı ihtiyaçlarını ayrıca belgeleyin.

Tekrar sipariş özelliğinde hangi ayrıntılar önemli?

Bayi önceki siparişini açıp aynı ürünleri yeniden almak isteyebilir. Eski kaydı olduğu gibi kopyalamak yerine güncel ürün durumu, fiyat ve uygunluk yeniden kontrol edilmelidir. Önceki siparişte bulunan bir ürün artık satışta olmayabilir veya ambalajı değişmiş olabilir.

Değişen kalemleri alıcıya açıkça gösterin. Ürün bulunamadığında sessizce sepetten çıkarmak, eksik siparişin fark edilmemesine neden olabilir. Alternatif önerilecekse bunun işletmenizin onayladığı ilişkiye dayanması ve alıcının kararını gerektirmesi değerlendirilmelidir.

Bayinin satın alma yetkilisi değiştiğinde eski siparişlere erişim kapsamı da kontrol edilmelidir. Şirket geçmişinin korunması ile her çalışanın bütün işlemleri görmesi ayrı kararlardır. Hesap yönetimini yalnızca bir giriş şifresi olarak tasarlamayın.

Bayileri yeni kanala nasıl alıştırırsınız?

İlk kullanımda uzun bir eğitim sunumu yerine gerçek sipariş görevini deneyin. Bayi ürününü bulsun, miktarı belirlesin, koşulları kontrol etsin ve talebi tamamlasın. Takıldığı adımları temsilci yardımıyla hemen geçmek yerine nedenini not edin.

Satış ekibinin de portalın sınırlarını bilmesi gerekir. Hangi durumda sipariş kesinleştiği, hangi durumda kontrol beklediği ve müşteri değişiklik istediğinde ne yapılacağı ortak biçimde anlatılmalıdır. Temsilcilerin farklı açıklama vermesi, doğru çalışan sistemi bile anlaşılmaz hâle getirebilir.

Pilot sırasında portal dışında verilen siparişlerin nasıl kaydedileceğini kararlaştırın. Aynı talebin hem mesajdan hem portaldan gelmesi mümkündür. Tek kayıt üzerinden ilerlemek ve kaynağı göstermek, operasyonun hangi işin gerçek olduğunu anlamasına yardımcı olur.

İlk iyileştirmeleri en sık görülen engellere göre seçin. Çok sayıda bayi ürün koduyla arıyorsa arama kolaylığı, nadiren kullanılan bir vitrin düzeninden önce gelebilir. Kapsam kararlarını kendi kullanım gözleminizle destekleyin.

Sonuç: Bayinin siparişini uçtan uca düşünün

Katalog, fiyat, stok, onay ve sevkiyatı aynı kapsam içinde değerlendirin. Hazır seçenekleri gerçek siparişlerle deneyin, gerektiğinde özel çözümü sınırlı pilotla doğrulayın. Navdion ile bayi portalı ihtiyaçlarınızı netleştirmek için ücretsiz proje analizi talep edebilirsiniz.