Çoğu satıcı bayiliğe geçerken tek bir şey yapar: ürünlere bir "bayi fiyatı" sütunu ekler, kullanıcıya rol atar, işi bitmiş sayar. Sonra ilk sorun gelir. Bir bayi, perakende vitrinde kendi alış fiyatının altında bir kampanya görür ve seni arar. İkinci sorun daha sinsidir: perakende bir müşteri, stokta kalan son yirmi kodu saniyeler içinde satın alır ve aynı dakikada bir bayinin toplu siparişi stoksuz kalır. İki ekonomiyi aynı havuzdan beslediğinde bu kaçınılmazdır.
B2B ve B2C aynı ürünü satar ama tamamen farklı iki iş modelidir. Biri hacim, vade ve öngörülebilirlik üzerine kuruludur; diğeri dürtü, hız ve kampanya üzerine. Bunları tek bir dijital ürün satış scripti üzerinde yürütmek mümkündür, hatta doğru kurulduğunda güçlü bir avantajdır. Ama bunun için e-pin scripti tarafında bazı kararların en baştan doğru verilmesi gerekir. Bu yazı tam olarak o kararları anlatıyor.
Aynı ürünü iki farklı ekonomiye satıyorsun, farkında mısın?
Perakende müşterin tek kod alır, hemen ödeme yapar, teslimatı saniyeler içinde bekler ve bir daha ne zaman geleceği belirsizdir. Bayin ise beş yüz kod alır, belki hafta sonu öder, teslimatı kendi sistemine aktarır ve her ay aynı ritimle döner. Birincisinde pazarlama maliyeti yüksek, işlem başına kâr yüksektir. İkincisinde pazarlama maliyeti neredeyse sıfır, işlem başına kâr düşüktür.
Bu fark tek bir şeyi zorunlu kılar: iki tarafın da birbirinin fiyatını görmemesi. Bayi, perakende fiyatını görmeli, çünkü kendi kârını hesaplayacak. Ama perakende müşteri bayi fiyatını asla görmemelidir; hatta bayi fiyatının varlığını bile hissetmemelidir. Giriş yapılmadan görülemeyen fiyat, kaynak kodunda da bulunmamalıdır. Çoğu basit kurulumda fiyat gizlenir ama sunucudan yine gönderilir; tarayıcı konsolunu açan herkes görür.
Tek vitrin mi, iki vitrin mi? Yanlış cevap sana pahalıya patlar
İki yaklaşım vardır. Birincisi ayrı alt alan adı: bayi girişini tamamen ayrı bir arayüzde toplarsın. İkincisi tek vitrin, rol bazlı görünüm: aynı sayfada kullanıcı giriş yaptığında fiyatlar ve seçenekler değişir. İkinci seçenek yönetimi kolaylaştırır ama sızıntı riski yüksektir; kategori sayfası, arama sonuçları, sitemap, ürün beslemesi gibi onlarca noktada bayi fiyatının kaçmadığından emin olman gerekir.
Pratikte en sağlam kurgu melezdir: vitrin ortaktır, ancak bayi paneli ayrı bir alan olarak çalışır. Bayi giriş yaptığında kendi paneline yönlenir; orada toplu sipariş ekranı, cari ekstresi, API anahtarları ve toplu teslimat dosyaları bulunur. Perakende vitrinde bayiye özel hiçbir şey render edilmez. Bu ayrım, ileride bayi sayısı arttığında arayüzü de sadeleştirir; bayinin görsel kampanyalara değil, hıza ve stok görünürlüğüne ihtiyacı vardır.
| Konu | B2C tarafı | B2B tarafı | Çakışma riski |
|---|---|---|---|
| Fiyatlama | Kampanyalı, dinamik | Sözleşmeli, kademeli | Yüksek |
| Ödeme | Anlık kart / cüzdan | Cari hesap, vade, havale | Orta |
| Stok | İlk gelen alır | Rezervasyon gerekir | Yüksek |
| Teslimat | Ekranda tek kod | Toplu dosya veya API | Düşük |
| Destek | Canlı sohbet, sık soru | Atanmış temsilci | Düşük |
| İade | Tüketici mevzuatı | Sözleşme hükümleri | Orta |
Bayi fiyatı bir kademe değil, bir sözleşmedir
Yaygın hata, bayi fiyatını tek bir yüzde indirim olarak tanımlamaktır. Gerçek hayatta bayi fiyatı ürün grubuna göre değişir: bazı ürünlerde tedarikçi marjın zaten dardır, orada yüzde on indirim veremezsin. Doğru model, ürün grubu bazlı kademeli fiyat listeleri kurmaktır. Bir bayi "Gümüş" listesine bağlanır, o listede her grup için ayrı oran tanımlıdır ve özel anlaşma yaptığın bir bayi için tekil ürün istisnası girebilirsin.
Kademeler aylık hacme göre otomatik yükselmelidir. Bayi bu ay hedefi geçtiyse gelecek ay bir üst listeye çıkar; düştüğünde ise hemen değil, bir ay tolerans tanıyarak iner. Bu küçük detay bayi ilişkisinde büyük fark yaratır, çünkü kötü bir aydan sonra cezalandırılmak bayiyi rakibe iter. İyi bir e-pin satış yazılımı bu kuralları koda gömmez, yönetim panelinde ayarlanabilir hale getirir.
Bayilerin sistemi terk etme sebepleri
- Stok bulamama ve rezervasyon yokluğu 40%
- Perakende kampanyasının fiyatı ezmesi 30%
- Cari ve ekstre karışıklığı 20%
- API ve entegrasyon eksikliği 10%
Stok havuzunu kim önce yer? Rezervasyon mantığı
En ciddi çakışma stokta yaşanır. Bayine "ayın onunda beş yüz adet alacağım" dedirttiysen ve o gün stok perakende tarafından tükenmişse, bayi bir daha sana güvenmez. Çözüm, stok havuzunu ikiye bölmek değil; rezervasyon ve eşik mantığı kurmaktır. Belirlediğin bir eşiğin altına düşen stok, otomatik olarak sadece bayi siparişlerine açılır. Perakende vitrin o üründe "stokta yok" gösterir.
İkinci katman, bayi için süreli rezervasyondur. Bayi toplu sipariş oluşturduğunda kodlar belirli bir süre boyunca kilitlenir; ödeme gelmezse otomatik serbest bırakılır. Kilitleme süresi bayinin kademesine göre değişebilir; üst kademedeki bayiye kırk sekiz saat verirken yeni bayiye iki saat vermek makul bir politikadır. Bu mekanizmanın çalışma biçimini özellikler sayfasında ayrıntılı görebilirsin.
Bayiler çoğu zaman birkaç kuruş için değil, stok güvenilirliği ve teslimat hızı için kalır. Kesintisiz stok sunan bir tedarikçi, daha ucuz ama güvenilmez olandan her zaman öndedir.
API erişimi: B2B'nin gerçek ürünü panelin değil, uç noktan
Ciddi bir bayi senin panelinden manuel sipariş vermek istemez; kendi sitesine entegre olmak ister. Müşterisi ondan satın aldığında senin uç noktana istek gider, kod anında döner, teslimat tamamlanır. Bu yapıyı kuran satıcı, bayisinin operasyonunun içine yerleşmiş olur ve o bayi bir daha kolay kolay ayrılmaz, çünkü ayrılmak entegrasyonu baştan yazmak demektir.
API tarafında üç şey şarttır: bayi başına ayrı anahtar, oran sınırı ve idempotency. Sonuncusu en çok ihmal edilendir. Bayinin sistemi ağ hatası yüzünden aynı siparişi iki kez gönderdiğinde, aynı işlem kimliğiyle gelen ikinci istek yeni kod düşmemeli, ilk siparişin sonucunu döndürmelidir. Bu koruma yoksa çift teslimat ve zarar kaçınılmazdır. Ayrıca test ortamı sunmak, entegrasyon süresini günlerden saatlere indirir.
Cari, limit ve vade: B2C'de olmayan üç kalem
Perakendede ödeme olmadan teslimat olmaz, konu kapanır. B2B'de ise iş cari hesapla yürür. Bayine bir limit tanımlarsın, o limit dolana kadar sipariş verir, hafta sonunda kapatır. Bu sistemin sağlıklı işlemesi için üç şey gerekir: limit aşımında otomatik durdurma, gecikmede otomatik uyarı ve her an indirilebilir bir ekstre. Ekstre olmadan yapılan her cari görüşmesi tartışmaya dönüşür.
Limit, bayinin geçmiş ödeme davranışına göre otomatik ayarlanabilmelidir. Altı ay boyunca zamanında ödeyen bayinin limiti kademeli artmalı, iki kez geciken bayininki düşmelidir. Bu kararı insan iradesine bırakırsan ya fazla cömert davranıp risk alırsın ya da fazla katı davranıp bayi kaybedersin. Paket bazında hangi B2B modüllerinin geldiğini fiyat bölümünden karşılaştırabilirsin.
| Kontrol | Ne engeller | Öncelik |
|---|---|---|
| Bayi fiyatı sunucu tarafında gizleniyor mu? | Perakende müşterinin maliyeti görmesi | Kritik |
| Stok eşiğinde B2B önceliği var mı? | Bayinin toplu siparişte stoksuz kalması | Kritik |
| Rezervasyon süresi kademeye göre mi? | Boş rezervasyonla stok kilitlenmesi | Yüksek |
| API idempotency anahtarı zorunlu mu? | Tekrarlayan istekte çift teslimat | Kritik |
| Cari limit aşımı otomatik duruyor mu? | Tahsil edilemeyen bakiye birikmesi | Kritik |
| Bayi ekstresi anlık indirilebiliyor mu? | Mutabakat tartışmaları | Yüksek |
| Kampanya B2B fiyatını ezebiliyor mu? | Bayi güveninin kaybı | Kritik |
| Test API ortamı var mı? | Uzayan entegrasyon süreçleri | Orta |
İki ekonomiyi tek panelde, çakışmadan yürüt
Pinova; rol bazlı fiyat listeleri, stok rezervasyonu, cari limit ve bayi API'sini tek yapıda sunar. Perakende hızını kaybetmeden bayilik ağını büyütmek için tasarlandı.
B2B ve B2C için iki ayrı kurulum yapmalı mıyım?
Gerekmez ve önerilmez. İki ayrı kurulum, stok senkronizasyonu sorununu doğurur ve aynı kodu iki yerde satma riski yaratır. Tek veri tabanı, ayrı arayüz yaklaşımı hem güvenli hem yönetilebilirdir.
Perakende kampanyası bayi fiyatının altına düşerse ne olur?
Sistem bunu bir kural olarak engellemelidir. Kampanya fiyatı, en düşük bayi listesinin altına inemeyecek şekilde sınırlanır; inmesi gerekiyorsa bayi listeleri de otomatik güncellenir. Aksi halde bayi, senden değil senin vitrinden alışveriş yapmaya başlar.
Bayiye ne zaman API erişimi vermeliyim?
Aylık sipariş adedi manuel yönetilemez hale geldiğinde, tipik olarak günde onlarca işlemi aşınca. Erken vermek de sakıncalı değildir; asıl önemli olan oran sınırı ve anahtar yönetiminin baştan doğru kurulmasıdır.
Cari limiti neye göre belirlemeliyim?
Başlangıçta bayinin ilk üç ayda peşin yaptığı ortalama aylık alımın yarısı makul bir başlangıçtır. Sonrasında ödeme düzenine göre kademeli olarak artırılır. Limit kararını duygu ile değil, ödeme geçmişi verisiyle vermek gerekir.
B2B ve B2C'yi birlikte yürütmek, iki işi aynı anda yapmak değil; aynı stok havuzunu iki farklı sözleşmeyle paylaştırmaktır. Fiyat gizliliği, stok rezervasyonu, cari disiplini ve API güvenliği dört ayak gibidir, biri eksikse masa devrilir. Bu dört ayağın hazır kurulmuş halini test etmek istersen canlı demo üzerinden hem bayi panelini hem perakende vitrini açıp aradaki farkı kendi gözünle görebilirsin.