B2B Bayi Sipariş Programı ve Portalı

Telefon ve WhatsApp siparişinin asıl bedeli

Mesajla sipariş almak ilk bakışta bedavadır. Bedeli başka yerde ödenir: satış ekibinin zamanı sipariş satırı yazmaya ve fiyat sormaya gider. Bayiyle konuşmak, yeni bayi bulmak ya da tahsilatı takip etmek sıraya girer.

İkinci bedel doğruluktur. “Geçen seferkinden on koli daha” diye yazan bayinin geçen seferki siparişi bulunur, kod bir kişinin hafızasından çıkarılır, fiyat eski listeden bakılır. Hata faturadan ya da sevkiyattan sonra fark edilirse konu artık bir satır düzeltmesi değil, iade ve ticari tartışmadır.

Üçüncüsü görünürlüktür. Bayi bakiyesini, siparişinin nerede olduğunu ve ürünün gelip gelmediğini öğrenmek için aramak zorundadır. Muhasebe, satış ve depo aynı soruyu gün içinde defalarca cevaplar. Mesai bittiğinde de bayi bir şey öğrenemez.

• Sipariş bilgisi telefon, mesaj, e-posta ve Excel dosyası arasında dağılır; tek bir kayıt listesi yoktur
• Bir satış sorumlusu izne çıktığında hangi bayinin neyi beklediği belirsiz kalır
• Özel fiyat ya da iskonto sözü kişide kalır; sonradan kim neye söz verdi sorusu çıkar
• Riskli cariye verilen sipariş, ancak sevkiyat hazırlanırken muhasebeden dönebilir
• Bayi başına sipariş sıklığı ve ürün dağılımı gibi satış bilgisi hiçbir yerde birikmez

Bayiye özel fiyat ve iskonto: önce kural yazılır

B2B portal projesinin en sık hafife alınan kısmı fiyattır. Çoğu işletmede fiyat tek bir listeden çıkmaz. Liste, bayi grubu, ürün grubu, miktar, vade ve o bayiye yıllar önce verilmiş bir söz birlikte sonucu belirler. Bu kuralın bir kısmı programdadır, bir kısmı Excel’de, bir kısmı da satış müdürünün aklındadır.

Portal yazılmadan önce bu kuralları tek tek çıkarmak gerekir. Yazıya dökülemeyen kural koda da dökülemez. Keşifte küçük bir sınama yeterlidir: son dönemden farklı bayilere kesilmiş birkaç siparişi alın, yazılan kuralla aynı tutar çıkıyor mu bakın. Çıkmıyorsa eksik kural var demektir.

İkinci karar kaynağın nerede duracağıdır. Kural programda tutulabiliyorsa portal oradan okur. Tutulamıyorsa portal içinde bir kural tablosu kurulabilir. Aynı kuralı iki yerde yaşatmak ise zamanla farklı fiyatlar üretir ve bayiyle tartışmayı geri getirir.

Bakiye ve risk limitini görmek bayinin de işine gelir

Bakiyenin portalda görünmesi önce muhasebenin telefonunu rahatlatır. Bayi açık tutarı, vadesi geçen kısmı ve hesap hareketlerini sormadan görür. Mutabakat konuşması da aynı rakam üzerinden başlar.

Risk limiti daha hassastır. Limiti aşan siparişin ne olacağı yazılım kararı değil, ticari karardır. Sert engel bayiyi kızdırabilir, hiç engel olmaması portalı anlamsız kılar. Çoğu durumda ara çözüm uygundur: sipariş girilir ama doğrudan işlenmez, sorumlunun önüne düşer.

Limitin hesabı da konuşulmalıdır. Yalnızca cari bakiye mi sayılır, yoksa açık sipariş, vadesi gelmemiş çek ve senet de eklenir mi? Programınızın bu alanları nasıl tuttuğu kurulumda teyit edilir. Portal, muhasebenin kullandığı hesabın aynısını kullanmalıdır. Aksi halde ekrandaki rakam muhasebeyle çelişir.

Sipariş onayı: her sipariş aynı kapıdan geçmez

Her siparişi tek tek onaylatmak eski darboğazı ekrana taşır. Hiçbirini onaylatmamak da riskli siparişi depoya kadar götürür. Doğrusu, onayı yalnızca istisnaya bağlamaktır. Standart fiyat, yeterli limit ve yeterli stok varsa sipariş kendi yolunda ilerleyebilir.

Onaya düşen sipariş kaybolmamalıdır. Sorumlunun ekranında sebebi ile birlikte görünür, belirlenen süre içinde işlem görmezse bir üst kişiye hatırlatma gider. Bayi de “onay bekliyor” durumunu görür; sipariş verdim mi vermedim mi diye aramaz.

• Onay sebepleri yazılı liste halinde tutulur: limit aşımı, özel fiyat talebi, asgari tutar altı, stok yetersizliği, yeni bayinin ilk siparişi
• Satış sorumlusu siparişi düzeltebiliyorsa yaptığı değişiklik kayıt altına alınır ve bayiye gösterilir
• Reddedilen siparişte gerekçe zorunludur; bayi sebebini ekrandan okur
• Bayi tarafında da onay olabilir: büyük bir bayide siparişi çalışan girer, yetkili kişi onaylayıp gönderir
• Sipariş işlendikten sonra iptal kuralı baştan yazılır; depoya inmiş siparişin iptali farklı bir süreçtir
• Her adımın kimin tarafından ve ne zaman yapıldığı saklanır; itirazda aranan cevap buradan çıkar

Stok gösterimi: neyi, ne kadar açık göstereceksiniz?

Stoğu olduğu gibi göstermek her işletmeye uymaz. Bazı firmalar rakibin ya da bayinin elindeki adedi bilmesini istemez. Bazıları kıt ürünü belirli bayilere ayırır. Teknik bir ayar gibi görünen bu soru, aslında dağıtım politikasıdır.

Portalın göstereceği rakam da raftaki adet değildir. Açık siparişlerde bağlanmış miktar ve depo ayrımı hesaba girer. Programdaki bakiye doğru değilse portal yanlış bilgiyi daha çok kişiye daha hızlı duyurur. Bu yüzden stok güvenilir değilse önce o sorun ele alınır. Barkodlu stok takibi bu sırada portalın ön şartı olabilir.

Kampanya, duyuru ve mobil kullanım

Kampanyanın satış müdürünün telefonundan yayıldığı düzende hangi bayinin neyi bildiği belirsizdir. Portalda kampanya bir kuraldır: hangi ürün, hangi bayi grubu, hangi tarih aralığı, hangi koşul. Bayi yalnızca kendisine açık olanı görür. Sepette koşul sağlandığında indirim kendiliğinden yansır, sağlanmadığında “şu kadar daha eklerseniz” bilgisi çıkabilir.

Kampanya bitince kuralın da bitmesi gerekir. Program tarafındaki kampanya kartlarıyla portalın aynı kaynağı kullanması bu yüzden önemlidir. Kural iki yerde tutuluyorsa hangisinin esas olduğu baştan belirlenir. Kampanya hesabının faturada aynı biçimde çıkması, projenin en dikkatli sınanacak noktalarından biridir.

Duyuruların yasal bir boyutu da vardır. 6563 sayılı Kanun’un 6. maddesi esnaf ve tacirlere önceden onay alınmadan ticari elektronik ileti gönderilmesine izin verir, ama alıcı reddederse gönderim durur. Yönetmelik bu adreslerin gönderimden önce İleti Yönetim Sistemi’ne kaydedilmesini ve ret kontrolünü ister. Bayi çalışanına giden iletinin hangi kapsama girdiği de ayrıca değerlendirilir. Portal içindeki duyuru alanı ise bu trafiğin bir kısmını kendi ekranında tutar.

Sipariş ERP’ye nasıl yazılır? Resmî arayüzden, başka yoldan değil

Portal programın yerine geçmez. Fatura, irsaliye ve e-Dönüşüm süreci mevcut düzeninizde kalır; biz GİB özel entegratörü değiliz. Portal ürün, fiyat, cari ve stok bilgisini okur, onaylanan siparişi programa iletir.

Burada yön ayrımı nettir. Okuma, salt okunur bir kullanıcıyla veritabanından, rapordan ya da API’den yapılabilir. Yazma ise istisnasız programın resmî arayüzünden yapılır. Tabloya doğrudan satır eklemek programın kendi kontrollerini atlar ve bozulan kaydın izi çoğu zaman ay sonuna kadar görünmez. Bu talep gelse de karşılamıyoruz.

Araya bir kuyruk koymak da gerekir. Program güncellenirken ya da kapalıyken sipariş kaybolmaz, sırada bekler. Her siparişin tekil bir kimliği olur, ağ kesilip istek yinelense bile ikinci kayıt açılmaz. Program kaydı reddederse sebebi sorumluya düşer. Biz hiçbir üreticinin bayisi veya ortağı değiliz; arayüz erişimi ve lisans adımları yetkili bayinizle birlikte yürütülür.

Hazır B2B ürünü ne zaman yeter?

Birçok işletme için cevap hazır üründür ve bunu keşif görüşmesinde de söyleriz. Logo’nun sitesinde 2026 itibarıyla Logo Cloud Sales Platform yer alıyor; ürün sayfasına göre bayi portalı, bayiye özel fiyat ve ödeme koşulu, bakiye ve risk görüntüleme kapsamda. Bağımsız firmaların da Logo, Netsis, Mikro gibi programlar için bağlayıcı sunan bayi portalı ürünleri var. Güncel kapsam ve sürüm uyumu ürün sahibinden ya da yetkili bayinizden teyit edilir.

Karar için özellik listesini karşılaştırmak yetmez. Kendi siparişinizle sınayın: en karmaşık fiyatlı bayinizi, en sık yaşanan onay durumunu ve kampanyanızı üründe deneyin. Hepsi ayarla çözülüyorsa özel yazılıma para harcamak mantıksızdır.

Özel geliştirme de her şeyi baştan yazmak anlamına gelmez. Tek bir boşluk için, örneğin hazır ürünün karşılamadığı bir fiyat kuralı ya da ek bir onay adımı için, küçük bir kapsamla başlanabilir. Fabrikaya özel yazılımda olduğu gibi burada da kaynak koduna erişim, bakım ve lisans modeli projeye göre değişir ve sözleşmeye yazılır.