E-pin Satış Scripti Bayi Modülü Mimarisi: Büyük Bayi Ağlarının Perde Arkasında Kurduğu Katman, Cüzdan ve Limit Düzenini Bu Yazıda Çözeceksin

Çoğu kişi bayi modülünü şöyle sanır: panele bir kutu eklersin, içine yüzde 8 indirim yazarsın, bayi giriş yapar, ucuz alır, iş biter. Kâğıt üzerinde kulağa mantıklı gelir. Gerçekte ise bayilik bir indirim alanı değil, ayrı bir ticari muhasebe düzenidir. Aynı stoktan, farklı fiyatla, farklı ödeme koşuluyla, farklı risk profiliyle satış yapan ikinci bir işletmeyi kendi sisteminin içine yerleştiriyorsun. Ve o işletmenin hataları senin kasandan çıkıyor.

Bu yüzden ciddi hacme çıkan işletmelerin kullandığı e-pin satış scripti mimarisinde bayilik, ürün tablosuna eklenen bir kolon değil; cüzdan, limit, fiyat listesi, API anahtarı, yetki matrisi ve iz kaydının birlikte çalıştığı bir katmandır. Bu yazıda o katmanı parça parça açıyoruz. Sonunda kendi e-pin yazılımını denetlerken hangi soruları soracağını bileceksin.

Bayi modülünü "indirim yüzdesi" sanmak neden pahalıya patlar?

İndirim mantığıyla kurulan bayilik, ilk on bayide sorun çıkarmaz. Sıkıntı otuzuncu bayide, gece 02.00'de, aynı bayinin üç sekmeden aynı anda sipariş verdiği anda başlar. Tek bir yüzde alanı; bakiye düşümü, stok rezervasyonu, iade, kısmi teslimat ve iptal senaryolarının hiçbirini bilmez. Sonuç: bakiyesi 500 TL olan bayi 1.400 TL'lik kod çeker, sen de sabah raporunda eksi bakiye görürsün.

Doğru kurgu şu kabulle başlar: bayi bir müşteri değil, bir hesap sahibidir. Müşteri tek seferlik alır, hesap sahibi ise süreklidir; borcu, alacağı, geçmişi, limiti ve davranış geçmişi vardır. Dijital ürün satış scripti tarafında bu ayrımı yapmayan her yapı, büyüdükçe elle kapatılan açıklar üretir. Excel'e düşen mutabakat, gecelik manuel düzeltme, WhatsApp'tan "abi bakiyeyi elle ekler misin" mesajları hep bu kök hatanın belirtisidir.

Katmanlı bayilik: tek seviye mi, ağaç mı kurmalısın?

İki temel topoloji var. Birincisi düz (flat) bayilik: herkes doğrudan sana bağlı, herkesin fiyat listesi senin belirlediğin gruptan geliyor. İkincisi ağaç (hiyerarşik) bayilik: ana bayi kendi altına alt bayi açıyor, kendi marjını kendi belirliyor, sen sadece ana bayiyle muhasebe yapıyorsun.

Düz yapı basittir, hızlıdır, hata payı düşüktür ve küçük-orta ağlar için fazlasıyla yeterlidir. Ağaç yapı ise pazarlamayı bayiye devretmeni sağlar; karşılığında marj zinciri, iade akışı ve komisyon hesabı ciddi biçimde karmaşıklaşır. Kritik kural şudur: ağaç derinliğini üç seviyeyle sınırla. Dört ve üzeri derinlikte, alt uçtaki satış fiyatı senin tavsiye ettiğin fiyatın çok altına veya üstüne savrulur ve markanın fiyat algısı elinden çıkar.

Cüzdan mimarisi neden bayiliğin gerçek kalbidir?

Bayi modülünün tek kritik bileşenini seçmem gerekse tereddüt etmem: cüzdan. Çünkü bayi ağında para, siparişten önce hareket eder. Bayi bakiye yükler, sonra o bakiyeyi harcar. Dolayısıyla bakiye tablosu, senin en hassas finansal defterindir ve buradaki tutarsızlık doğrudan zarar demektir.

Sağlam bir cüzdanın üç şartı var. Birincisi satır bazlı kilit: bakiye düşümü ile sipariş oluşturma aynı atomik işlemde olmalı, ikisi arasında hiçbir boşluk bırakılmamalı. İkincisi hareket defteri: bakiye asla doğrudan güncellenmemeli, her değişim yükleme, harcama, iade, düzeltme gibi tipli bir hareket olarak yazılmalı ve güncel bakiye bu hareketlerden türetilebilmeli. Üçüncüsü ayrık blokaj: teslimatı bekleyen siparişin tutarı harcanabilir bakiyeden ayrılmalı ama henüz gelir yazılmamalı.

Bu üç şartı sağlayan bir e-pin satış yazılımı, altı ay sonra "bakiye neden tutmuyor" sorusunu hiç sormaz. Sağlamayan yapıda ise her ayın sonunda elle düzeltme hareketi girmek rutine döner; o rutin de zamanla kötü niyetli personel için açık kapı olur.

API erişimi olmadan bayi modülü neden yarım kalır?

Bayilerin bir kısmı senin panelinden elle sipariş verir. Ama cirosunun büyük bölümünü getiren bayiler kendi sitelerini işletir ve senden programatik erişim ister. API'si olmayan bir bayi modülü, tam da en çok kazandıran bayi tipini dışarıda bırakır.

Doğru API tasarımının omurgası dört uç noktadır: ürün ve fiyat listesi sorgusu, bakiye sorgusu, sipariş oluşturma ve sipariş durumu sorgusu. Bu dördünde de idempotency şarttır; yani bayinin aynı istek kimliğiyle gönderdiği ikinci çağrı ikinci sipariş açmamalı, birincinin sonucunu döndürmelidir. Ağ kopmaları nedeniyle bayi sistemleri isteği sıkça yeniden dener ve bu koruma olmadan çift teslimat kaçınılmazdır.

İkinci mesele hız limiti. Bayi başına saniyelik istek sınırı ve IP kısıtı tanımlamıyorsan, tek bir hatalı döngü tüm sistemi yavaşlatır. Üçüncüsü webhook: sipariş tamamlandığında bayiye bildirim gönderen bir yapı, senin destek yükünü belirgin biçimde düşürür.

Yetki ve limit matrisi: bayiye neyi göstermemelisin?

Bayi paneli, yönetici panelinin kırpılmış hali olmamalı. Sıfırdan, yalnızca bayinin ihtiyaç duyduğu alanları içerecek şekilde tasarlanmalı. Görmemesi gerekenler nettir: alış maliyetin, tedarikçi adları, diğer bayilerin fiyatları, toplam stok derinliği ve son müşteri verileri. Özellikle stok derinliği kritik: bayi elinde 4.000 kod olduğunu görürse pazarlık tonu değişir, 12 kod olduğunu görürse panik alım yapar.

Limit tarafında ise üç ayar seti tutmalısın: günlük harcama üst sınırı, tek siparişte maksimum adet ve ürün bazlı yasak listesi. Bu ayarlar bayi grubundan miras alınmalı ama bayi özelinde ezilebilmeli. Şüpheli bir hareket gördüğünde bayiyi silmek yerine dondurabilmek, mimarinin olgunluk göstergesidir.

Mutabakat ve iz kaydı: ayın sonunda kim kime ne borçlu?

Bayi ağı büyüdükçe en çok zaman alan iş satış değil, mutabakattır. Bunu mimariye gömmezsen her ay üç gününü tabloları karşılaştırmaya harcarsın. Çözüm, dönemsel ekstre üretimidir: seçilen tarih aralığında açılış bakiyesi, yüklemeler, harcamalar, iadeler, düzeltmeler ve kapanış bakiyesi tek sayfada, indirilebilir biçimde çıkmalı. Bayi bu ekstreyi kendi panelinden alabildiği anda destek talebinin üçte biri buharlaşır.

İz kaydı ise güven meselesidir. Kim hangi bayinin limitini ne zaman değiştirdi, hangi yönetici elle bakiye ekledi, hangi fiyat listesi hangi saatte güncellendi. Bu kayıtlar değiştirilemez biçimde tutulmalı. Anlaşmazlık çıktığında tartışmayı bitiren şey hafıza değil, zaman damgalı kayıttır.

Kurulum öncesi mimari kontrol listesi

Aşağıdaki tabloyu kendi sistemini denetlerken kullan. Her satırda "var" demek yetmez; ilgili senaryoyu bizzat deneyip sonucu görmek gerekir.

Bayi mimarisi, sonradan eklenen bir özellik olarak değil kurulurken düşünülen bir omurga olarak iş görür. Yukarıdaki kontrol listesini eline al, kendi sistemini dürüstçe puanla ve eksik kalan kritik satırları bir sonraki geliştirme turuna yaz. Hazır bir omurga üzerinden başlamak istersen canlı demo üzerinden bayi panelini kendi gözünle gezebilir, fiyat seçeneklerini karşılaştırabilirsin.