Bayi sipariş sistemi — siparişler hâlâ telefonla mı geliyor?

Bayi sipariş sistemi, bayilerinizin ve toptan müşterilerinizin kendilerine özel fiyat ve anlık stok bilgisiyle siparişlerini kendilerinin girdiği, satış ekibinin telefon ve WhatsApp'tan gelen siparişi elle kaydetmesini ortadan kaldıran bir B2B sipariş portalıdır. Hazır paket ya da özel yazılım olarak kurulur; ikisinde de başarı, portalın mevcut ERP ya da muhasebe programınızdan stok ve fiyatı okuyabilmesine bağlıdır. Karar vermeden önce üç şeyi netleştirin: aylık sipariş sayınız, stok verinizin doğruluğu ve mevcut programınızın dışarıya veri açıp açmadığı.

Telefonla sipariş almanın gerçek maliyeti

Bayi ve toptan satış yapan işletmelerin çoğunda sipariş akışı hâlâ aynı: bayi telefon açıyor ya da WhatsApp’tan yazıyor, satış temsilcisi not alıyor, sonra bunu sisteme giriyor.

Bu akışın maliyeti sanıldığı gibi hata değil. Hata da oluyor ama asıl kalem zaman.

Her sipariş için not alma, teyit etme, sisteme girme ve stok kontrolü birkaç dakika sürüyor. Günde yirmi sipariş alan bir işletmede bu, bir kişinin gününün önemli bir kısmı demek. O kişi bu süre boyunca satış yapmıyor, kayıt yapıyor.

İkinci kalem daha sinsi: bayi beklerken sipariş küçülüyor. Stokta var mı sorusunun cevabı hemen gelmediğinde bayi listesini kısaltıyor ya da bir sonraki sefere bırakıyor.

Bayi sipariş sistemi nedir, ne değildir?

Adı değişiyor — bayi portalı, B2B sipariş portalı, toptan sipariş sistemi — ama iş aynı: tanımlı bir bayinin giriş yapıp kendi fiyatıyla, anlık stoğa bakarak sipariş oluşturduğu ve o siparişin doğrudan sizin sisteminize düştüğü bir uygulama. Ne olduğunu anlamanın en kısa yolu ne olmadığını saymak; bu ayrım baştan yapılmazsa yanlış ürün alınıyor.

E-ticaret sitesi değil. E-ticarette fiyat herkese aynı, müşteri tanımsız, ödeme peşin. Bayi portalında üçü de farklı: fiyat bayiye özel, müşteri tanımlı, ödeme genellikle cari hesap üzerinden.

Katalog değil. PDF katalog veya ürün listesi, sipariş almayan bir vitrin. Portalın işi göstermek değil, siparişi kayıt altına almak.

Sadece bir form değil. Web sitesine konan “sipariş formu”, e-postayla gelen siparişin biraz düzenlisi. Portal, stok ve fiyatı gerçek zamanlı gösterdiği ölçüde portal.

Tablodaki beşinci satır sık gözden kaçıyor. Bayi akşam saatinde ya da hafta sonu sipariş vermek istediğinde telefon çalışmıyor; portal çalışıyor.

En somut kazanç, mevcut bayinin daha sık sipariş vermesi

Portal kurma gerekçesi genellikle “yeni bayi kazanmak” diye kuruluyor. Sahada gördüğümüz kazanç bu değil.

Asıl değişiklik mevcut bayilerde oluyor: stok ve fiyatı anlık gören bayi tereddüt etmiyor. Sipariş sıklığı artıyor ve sepet büyüyor.

Sebebi basit. Telefonla sipariş vermek bir “iş”; bayi bunu biriktirip haftada bir yapıyor. Portal açıkken sipariş vermek bir iş değil; ihtiyaç doğduğunda giriliyor.

Örnek senaryo — İvedik’te 60 bayisiyle telefon ve WhatsApp üzerinden çalışan bir yedek parça toptancısı düşünün. İki satış temsilcisi günün önemli kısmını sipariş kaydına ayırıyor. Portal devreye girdiğinde beklenen şey temsilcilerin işsiz kalması değil; sipariş kaydından kurtulan zamanın bayi ziyaretine ve yeni bayi geliştirmeye kaymasıdır. Portalın gerekçesi personel azaltmak değil, aynı personelin satış yapmasıdır.

Başarıyı belirleyen tek şey verinin güncelliği

Portal projelerinde en çok yatırım yapılan yer arayüz oluyor. Oysa benimsenmeyi belirleyen şey arayüz değil.

Stok bilgisi yanlışsa portal terk ediliyor. Bayi bir kez “var” yazan üründen sipariş verip “yok” cevabı aldığında portala güveni bitiyor ve telefona dönüyor. Bir daha geri getirmek çok zor.

Bu yüzden portal kurulmadan önce cevaplanması gereken soru şu: stok bilgisi mevcut sisteminizde ne kadar doğru?

Cevap “çok doğru değil” ise portal ikinci iş. Birinci iş stok doğruluğu — bunu depoda sayım neden tutmuyor yazısında ayrıca ele aldık.

Dikkat — Portal, arkasındaki verinin kalitesini yükseltmiyor; yalnızca görünür kılıyor. Dağınık bir stok kaydı portala bağlandığında dağınıklık bayiye de görünür hâle geliyor.

Mevcut ERP veya muhasebe programıyla nasıl entegre olur?

Portalın ayrı bir ada olarak kurulması, çözdüğünden fazla sorun üretiyor: iki yerde ürün tanımı, iki yerde stok, iki yerde fiyat.

Bu yüzden ilk teknik soru şu olmalı: mevcut programınız dışarıya veri açıyor mu?

Açıyorsa portal onun üzerine kuruluyor; stok ve fiyat tek yerden okunuyor. Açmıyorsa iki seçenek kalıyor: ara bir aktarım kurgusu ya da mevcut sistemi değiştirmek. İkisi de maliyet ve karar bunun farkında verilmeli.

Pratikte entegrasyon üç biçimden biriyle kuruluyor:

1. Hazır bağlantı noktası (API). Programın kendi arayüzü üzerinden stok, fiyat ve cari bilgisi anlık okunuyor, sipariş anlık yazılıyor. En sağlıklı yol; Logo, Mikro, Netsis gibi yaygın programların güncel sürümlerinin çoğu bir arayüz sunuyor ama kapsamı sürüme ve lisans paketine göre değişiyor. İlk iş, programınızın hangi sürümünde ne açıldığını yazılı sormak.
2. Zamanlanmış dosya aktarımı. Program belirli aralıklarla stok ve fiyat dosyası üretiyor, portal okuyor; siparişler de aynı yoldan geri gidiyor. Anlık değil ama çoğu bayi ağı için saatlik güncelleme yeterli. Eski sürümlerde çoğunlukla tek seçenek bu.
3. Doğrudan veritabanı okuma. Portal programın veritabanından okuyor. Hızlı kurulur ama program güncellendiğinde kırılma riski taşır; yalnızca üretici onay veriyorsa tercih edilmeli.

Hangisi olursa olsun üç şey sözleşmede yazılı olmalı: hangi alanlar hangi yönde akıyor, kaç dakikada bir güncelleniyor ve bağlantı koptuğunda bayi ne görüyor. Bu, hazır paket seçerken sorulacak soruların da en üstünde duruyor; üretim takip programı nasıl seçilir yazısında aynı noktaya değindik.

Hazır paket mi, özel yazılım mı?

İki yol da çalışıyor; hangisinin size uyduğunu belirleyen şey bayi sayısı değil, fiyat kurallarınızın ve mevcut programınızın ne kadar standart olduğu.

Pratik bir sıra: fiyat listeniz tek ve programınız desteklenenler listesindeyse hazır paketle başlayın; ilk altı ayda paketin izin vermediği üç şey birikirse özel yazılıma geçiş o zaman gerekçeli olur. Fiyat kurallarınız bayi grubuna, miktara ve vadeye göre katmanlıysa hazır paket genellikle ilk ay tıkanıyor; bu durumda baştan özel yazılım geliştirme daha ucuza çıkıyor.

Bayi sipariş sistemi fiyatları neye göre değişir?

Burada rakam vermiyoruz; aynı "bayi portalı" başlığı altında birbirinden on kat farklı projeler var ve kaynaksız bir aralık yanıltır. Teklifleri karşılaştırılabilir kılan şey, fiyatı oluşturan kalemleri ayrı ayrı görmek:

• Entegrasyon derinliği. En büyük kalem. Hazır bağlantı noktası olan bir programla çalışmak ile dosya aktarımı kurmak arasında belirgin fark var.
• Fiyat kuralı karmaşıklığı. Tek liste mi, bayi grubuna göre liste mi, miktar ve vade iskontosu mu, kampanya kuralları mı?
• Ürün ve varyant sayısı. Bin ürün ile elli bin ürün, arama ve listeleme tarafında farklı kurgu istiyor.
• Onay ve istisna akışları. Kredi limiti, kapalı cari, stok yetersizliği gibi durumlarda kimin onay vereceği.
• Fatura tarafı. e-Fatura ve e-İrsaliye entegrasyonu baştan dahil mi?
• Mobil uygulama. Mobil uyumlu site yeterliyse maliyet düşüyor; ayrı uygulama kalemi ikiye katlayabiliyor.
• Bakım ve barındırma. Yıllık bakım, sunucu ve yedekleme çoğu teklifte ayrı satır.

Teklif alırken bu yedi kalemi tek tek yazdırın; toplamı tek satırda veren teklif karşılaştırılamıyor. Kapsamı kendiniz kabaca ölçmek isterseniz web sitesi fiyat hesaplayıcı aracı, portal ve entegrasyon kalemlerini seçtiğinizde hangi başlıkların maliyeti büyüttüğünü gösteriyor; yazılım tarafında nasıl çalıştığımız yazılım geliştirme sayfasında.

Fatura ve irsaliye tarafı

Portal sipariş alıyorsa bir sonraki adım fatura. Bu noktada mevzuat devreye giriyor.

e-Fatura ve e-İrsaliye uygulamalarının kapsamı ciro eşiklerine ve sektöre göre belirleniyor; bazı sektörlerde ciro şartı hiç aranmıyor. Kapsam ve tarihler değiştiği için burada rakam yazmıyoruz — güncel metin Gelir İdaresi Başkanlığı’nın e-Belge portalında, e-Fatura tarafı ise ayrı bir başlıkta yayımlanıyor.

Portal projesine başlarken kapsamınızı netleştirmek, sonradan yapılacak bir entegrasyon işini baştan planlamanızı sağlıyor. Sonradan eklemek her zaman daha pahalı.

Kapsamı dar tutmanın yolu

Portal projeleri kapsam büyümesine çok açık. “Madem yapıyoruz, şunu da ekleyelim” listesi hızla uzuyor: bayi performans raporu, kampanya yönetimi, puan sistemi, mobil uygulama.

Birinci aşamada yalnızca dört şey olmalı:

1. Bayi girişi — kim olduğunu bilen bir giriş.
2. Ürün listesi ve bayiye özel fiyat — anlık stok bilgisiyle.
3. Sipariş oluşturma — geçmiş siparişi tekrarlama dahil.
4. Sipariş durumu — bayi kendi siparişinin nerede olduğunu görebilsin.

Dördüncü madde en çok atlanan ama telefon trafiğini en çok azaltan madde. “Siparişim ne durumda?” sorusu, sipariş vermekten daha fazla telefon üretiyor.

İpucu — Portalı önce üç beş bayiyle açın, hepsiyle değil. En çok sipariş veren ve size en yakın bayilerle başlamak, ilk hataları küçük ölçekte yakalamanızı sağlıyor.

Bayilerin benimsemesi için ne yapılmalı

Yeni sistemin kullanılmaması, portal projelerinin en yaygın başarısızlık biçimi. Üç şey işe yarıyor.

Telefonu bir anda kapatmayın. Paralel dönem gerekiyor; ama paralel dönemin bir bitiş tarihi olmalı, yoksa hiç bitmiyor.

Geçmiş siparişi tek tıkla tekrarlatın. Bayilerin çoğu benzer siparişler veriyor. Bu tek özellik, portalın telefondan hızlı olmasını sağlayan şey.

İlk siparişte birlikte girin. Bayiyi arayıp telefonda beraber bir sipariş oluşturmak, gönderilen kullanım kılavuzundan çok daha etkili.

Aynı benimseme sorunu iç kullanıcılarda da yaşanıyor; oradaki yöntemleri programı aldık ama kimse kullanmıyor yazısında yazdık.

Mobil kullanım — bayi masada değil sahada

Bayi siparişlerinin önemli kısmı bilgisayar başında değil, yolda ya da müşteri yanında veriliyor. Bu, portalın telefonda çalışması gerektiği anlamına geliyor.

Burada iki ayrı karar var ve karıştırılıyor: mobil uyumlu site ile mobil uygulama aynı şey değil.

Mobil uyumlu bir portal, telefonun tarayıcısında çalışıyor; kurulum gerektirmiyor, güncelleme derdi yok. Çoğu bayi ağı için yeterli.

Mobil uygulama ise kurulum ve mağaza süreçleri getiriyor. Karşılığında iki şey veriyor: bildirim gönderebilme ve çevrimdışı çalışabilme. Bu ikisine gerçekten ihtiyaç yoksa uygulama, portalın maliyetini ikiye katlıyor.

Sıralama pratikte şu: önce mobil uyumlu portal, kullanım oturduktan sonra gerekiyorsa uygulama.

Portal işe yaradı mı — nasıl ölçülür?

Portal projelerinin çoğunda ölçüm hiç kurulmuyor ve altı ay sonra "işe yaradı mı" sorusunun cevabı kanaate kalıyor. Ölçülecek dört şey var ve dördü de portalın kendi verisinden çıkıyor.

Portal üzerinden gelen sipariş oranı. Toplam siparişin yüzde kaçı portalden geliyor? İlk hedef ölçüsü bu.

Sipariş sıklığı. Aynı bayi portalden önce ayda kaç, sonra kaç sipariş veriyor?

Ortalama sipariş büyüklüğü. Portal sepetleri büyütüyor mu, küçültüyor mu?

Telefon trafiği. Satış ekibine gelen "sipariş" ve "siparişim nerede" aramaları azaldı mı?

Dördüncüsü en çok konuşulan ama en az ölçülen kalem. Portal öncesinde bir hafta boyunca gelen aramaları saymak, sonrasında karşılaştırma yapabilmenin tek yolu.

Örnek senaryo — Diyelim ki bir işletme portalı açıyor ve üç ay sonra "bayiler kullanmıyor" diyor. Portal verisine bakıldığında siparişlerin yaklaşık üçte birinin portalden geldiği görülüyor. Kullanılmıyor değil; beklenti hiç konuşulmadığı için "az" sayılıyor. Ölçüm baştan kurulsa üçte bir, ilk çeyrek için başarılı bir sonuç olarak okunurdu.

Bayi tarafında sık yapılan üç hata

Fiyatı gizlemek. "Fiyatı temsilci söylesin" mantığıyla kurulan portal, portal olmaktan çıkıyor. Bayi fiyatı görmüyorsa yine telefon açıyor.

Sipariş onayını yavaşlatmak. Her siparişi elle onaya bağlamak, portalın hız avantajını yok ediyor. Onay gerekiyorsa yalnızca istisnalara uygulanmalı: limit aşımı, kapalı cari, stok yetersizliği.

Ürün bilgisini eksik bırakmak. Kod ve isimden ibaret bir listede bayi aradığını bulamıyor. Görsel, ölçü ve temel özellik olmadan portal bir stok listesi olarak kalıyor.

Sonuç — Bayi portalının değeri teknolojisinde değil, sipariş vermeyi telefondan kolay hâle getirmesinde. Bu tek ölçütü karşılamayan portal, ne kadar kapsamlı olursa olsun kullanılmıyor.

Portal ve sipariş sistemlerini web sitesi geliştirme ve özel yazılım geliştirme kapsamında kuruyoruz; uçtan uca satış tarafı için e-ticaret sitesi kurma sayfasına bakabilirsiniz. Kümenin genel çerçevesi fabrikalar için yazılım yazısında.