Epin Satış Panelinde Stok Tahsis Kurallarını Yanlış Kurarsan Bayin Kasanı Boşaltır: Perakende Müşterini Neden Sürekli Stoksuz Bırakıyorsun?

Bayilik açtığın ilk ay her şey harika görünür. Sipariş adedi katlanır, ciro grafiği yukarı bakar, tedarikçiye verdiğin rakamlar büyür. İkinci ayda ise garip bir şikayet başlar: perakende müşterin en çok satan ürününü sepete atıyor ve "stokta yok" yazısıyla karşılaşıyor. Oysa sabah 400 adet yüklemişsindir. Cevap basittir; tek bir bayin, tek bir API isteğiyle o 400 adedin 380'ini on saniyede çekmiştir.

Çoğu işletme sahibi bunu bir talep sorunu sanır ve daha çok stok almaya çalışır. Halbuki sorun miktarda değil, tahsis kuralındadır. Bayi ile perakende aynı havuzdan, aynı öncelikle ve aynı hızda besleniyorsa kaybeden her zaman perakende olur; çünkü perakende müşteri tek tek alır, bayi ise toptan süpürür. Bu yazıda bir e-pin satış scripti üzerinde tahsis kurallarının nasıl kurgulanacağını, hangi oranların gerçek hayatta işlediğini ve kâr marjını korurken bayiyi de küstürmeyen dengeyi anlatıyorum.

Tek havuz neden matematiksel olarak perakendeyi öldürür?

Tek havuz mantığında stok, isteyen ilk kişiye verilir. Bu ilk bakışta adil görünür ama iki müşteri tipinin davranışı taban tabana zıttır. Perakende müşteri günün her saatine yayılmış, tek adetlik siparişler verir. Bayi ise genellikle sabah tedarik saatinde, tek seferde üç haneli adetler çeker. Yani havuz, günün ilk saatinde boşalır ve geri kalan on sekiz saat boyunca perakende vitrinin fiilen kapalı olur.

Buradaki asıl kayıp ciro değil, alışkanlıktır. Perakende müşteri senden alamadığı için başka yere gider ve orada hesap açar. Bir sonraki sefer önce oraya bakar. Bayi kanalı yüksek hacim getirir ama marjı düşüktür; perakende düşük hacim getirir ama marjı yüksektir ve kalıcıdır. İyi kurulmuş bir epin yazılım yapısı bu iki kanalı birbirinin kaynağını yiyemeyeceği şekilde ayırır.

Üç katmanlı havuz modeli tam olarak nasıl çalışır?

Uygulamada en sağlıklı sonucu veren yapı üç katmandır. Birinci katman perakende rezervidir; toplam stoğun sabit bir yüzdesi bayilere hiçbir koşulda açılmaz. İkinci katman ortak havuzdur; her iki kanal buradan beslenir ve gerçek rekabet burada yaşanır. Üçüncü katman ise bayi tahsisidir; belirli bayilere sözleşmeye bağlı adetler ayrılır, bu adetler perakendeye açılmaz.

Bu model, bir dijital ürün satış scripti içinde stok satırına eklenen tek bir kanal etiketiyle kurulabilir. Kod yüklenirken hangi katmana ait olduğu belirlenir, satış anında da sipariş kanalı ile etiket eşleşmiyorsa o kod hiç aday listesine girmez. Karmaşık görünse de mantık tek cümledir: kod, doğduğu katmanın müşterisine gider.

Bayiye limit koymak ilişkiyi bozar mı?

Tam tersi. Limitsiz bayi, senin stoğunu kendi deposu gibi kullanır ve satamadığı kodu elinde tutarak sermayeni bloke eder. Net kurallar koyduğunda bayi de planlama yapabilir hale gelir. Pratikte işe yarayan üç limit vardır: tek seferlik maksimum adet, günlük toplam adet ve ürün bazlı tavan. Bu üçü birlikte uygulandığında tek bir bayinin popüler ürünü süpürmesi imkansız hale gelir.

Limitleri sabit tutmak da şart değil. Ödeme geçmişi düzgün, iade oranı düşük bayilerin limiti otomatik yükseltilebilir. Bu, bayiyi cezalandırmadan yönlendiren bir mekanizmadır ve iyi bir e-pin satış yazılımı bunu kural motoruyla otomatik yapar; sen her sabah elle limit güncellemezsin.

Fiyat farkı tahsisle nasıl birleşir?

Bayi fiyatı doğal olarak perakendenin altındadır. Sorun, aynı kodun iki farklı fiyattan satılabilir olmasıdır; bu da arbitraj kapısı açar. Bayi ucuza alır, kendi sitesinde senin perakende fiyatının biraz altına koyar ve seni kendi stoğunla dövmeye başlar. Tahsis kuralları bu noktada sadece stok değil, fiyat disiplini aracına da dönüşür.

Çözüm, bayi kademelerini adet taahhüdüne bağlamak ve düşük kademeye popüler ürünlerde dar limit tanımlamaktır. Ayrıca bayi kademesi yükseldikçe ayrılan tahsisin artması, bayiyi daha çok satmaya değil, daha düzenli almaya teşvik eder. Kademe yapısını nasıl kurgulayacağını özellikler bölümündeki bayi modülü açıklamalarında daha ayrıntılı bulabilirsin.

API ile satan bayi için ayrı kural gerekir mi?

Kesinlikle gerekir. Panelden alışveriş yapan bayi insan hızındadır; API ile bağlanan bayi makine hızındadır. Aynı limit ikisine de uygulanırsa API tarafı her zaman önde olur. Bu yüzden API kanalı için ayrı bir hız sınırı, ayrı bir eşzamanlı istek tavanı ve ayrı bir günlük kota tanımlanmalıdır.

Bir başka önemli detay, rezervasyon süresidir. API üzerinden gelen bir sipariş ödeme tamamlanmadan stoğu kilitliyorsa ve o kilit çok uzun sürüyorsa, ödemesiz denemeler stoğu dakikalarca esir tutar. Kilit süresini altmış saniyeyle sınırlamak ve serbest bırakılan kodu havuza geri döndürmek, tek başına stok görünürlüğünü ciddi biçimde düzeltir.

Kurallarını test etmeden canlıya alma

Tahsis mantığı yazıda kolay görünür, canlıda sürprizlidir. Aşağıdaki kontrol listesini bir test ürünü üzerinde uygulayıp her satırı doğrulamadan yeni kuralları yayına alma. Her maddede beklenen davranışı gördüğünde model güvenlidir.

Bayi kanalı büyütür, perakende kanalı kalıcı kılar; ikisini aynı havuza mahkum ettiğin gün birini kaybedersin. Katmanlı stok, kanal bazlı limit ve otomatik kademe yapısının gerçek bir panelde nasıl göründüğünü görmek istersen canlı demo üzerinden bir test ürünü oluştur, bayi hesabıyla toplu çekim dene ve perakende vitrininin hâlâ satışa açık kaldığını kendin doğrula.