Çoğu bayi sistemi kuran işletme sahibi, panelde ne kadar çok veri gösterirse o kadar güven kazanacağını sanır. Mantık kulağa doğru gelir: bayi stoğu görsün, tedarik durumunu bilsin, siparişin nereden geldiğini izlesin, böylece sana durmadan mesaj atmasın. Uygulamada olan tam tersidir. Panelde gösterdiğin her ek alan, bayinin senin iş modelini tersine mühendislikle çözmesi için bir ipucudur. Üç ay sonra o bayi ya senin tedarikçine doğrudan ulaşmış olur ya da senin marjını tam olarak bilerek fiyat pazarlığına oturur.
Bu yazıda süslemeye girmeyeceğim: bayi panelinde hangi verinin neden tehlikeli olduğunu, hangi alanın hangi davranışı tetiklediğini ve doğru kurulmuş bir e-pin scriptinin bu alanları rol bazında nasıl kapattığını anlatacağım. Buradaki hiçbir madde teorik değil; hepsi bayilik yapan işletmelerin gerçek kayıp kalemlerinden çıkmış. Kullandığın e-pin satış yazılımı bu ayrımları yapamıyorsa, panel bir yönetim aracı değil, rakibine hazırladığın bir istihbarat raporudur.
Bayin Gerçek Stok Sayını Neden Asla Görmemeli?
Panelde "Stok: 1.842 adet" yazdığın anda bayine iki bilgi vermiş olursun: elinde ne kadar mal var ve bunu ne hızda tükettiğin. Zeki bir bayi bu sayıyı her gün not alır, haftalık düşüş hızını çıkarır ve senin tedarik döngünü öğrenir. Stok 200'ün altına düştüğünde fiyat baskısı yapmaya başlar, çünkü alternatifi olmadığını bilir. Doğru yaklaşım sayı yerine durum göstermektir: "Stokta", "Son adetler", "Tükendi". Bayi satış yapabilmek için bundan fazlasına ihtiyaç duymaz. Ciddi bir dijital ürün satış scripti stok alanını rol bazında maskeler; bayi rolü sayısal değeri değil eşik etiketini görür, yönetici rolü gerçek adedi görür. Bu tek değişiklik, pazarlık masasındaki gücü tamamen sende tutar.
Maliyet ve Kâr Marjı Alanları Panelde Ne Arıyor?
Bu, en sık yapılan ve en pahalı hata. Çoğu hazır epin yazılım kurulumunda ürün kartı tek şablondan üretilir; yönetici için yazılmış "alış fiyatı", "kâr", "kâr yüzdesi" alanları bayi görünümünde de dururul ya da API cevabında gizlice taşınır. Ekranda görünmese bile tarayıcı konsolunda JSON içinde duruyorsa, sızmış demektir. Bayi senin 100 TL'lik ürünü 74 TL'ye aldığını öğrendiğinde iki şey yapar: ya tedarikçini arar ya da ondan aşağı fiyat ister. Panelde bayinin görmesi gereken tek fiyat kendi alış fiyatıdır; onun da yanında sadece önerilen satış fiyatı durabilir. Maliyet, tedarikçi ödeme vadesi ve marj oranı yönetici katmanında kalır.
| Veri alanı | Bayi görürse ne olur? | Doğru görünüm | Risk |
|---|---|---|---|
| Gerçek stok adedi | Tedarik döngünü çözer, darboğazda pazarlık yapar | Stokta / Son adetler / Tükendi | Yüksek |
| Ürün maliyeti | Marjını bilir, tedarikçiye yönelir | Yalnızca kendi alış fiyatı | Kritik |
| Tedarikçi adı / kaynak etiketi | Aracıyı atlar, doğrudan temas kurar | Tamamen gizli | Kritik |
| Diğer bayilerin fiyatı | Kademeli fiyatını sorgular, güven kaybı | Sadece kendi kademesi | Yüksek |
| Toplam sistem cirosu | Ölçeğini öğrenir, komisyon pazarlığı açar | Sadece kendi cirosu | Orta |
| Son müşteri iletişim bilgisi | Müşteriye doğrudan ulaşır, KVKK riski | Maskelenmiş (ör. 05** *** 12 34) | Kritik |
| Ham API yanıtı / uç nokta adresi | Entegrasyon mimarini kopyalar | Sunucu tarafında kalır | Yüksek |
| Kullanılmamış kod havuzu | Kod sayısını ve değerini görür | Sadece satın aldığı kodlar | Kritik |
Tedarikçi İzini Silmediğin Sürece Aracı Konumun Geçicidir
Bayilik iş modelinin tamamı bilgi asimetrisine dayanır. Sen kaynağı biliyorsun, bayi bilmiyor; bu yüzden senden alıyor. Panelde "kaynak", "sağlayıcı", "entegrasyon" gibi bir kolon varsa veya sipariş detayında dış servisin işlem numarası ham haliyle duruyorsa, o asimetriyi kendi elinle yok ediyorsun. Tedarikçinin işlem referansı çoğu zaman kendi marka önekini taşır; bayi o öneki bir kez aratır ve zincir çözülür. Bunun çözümü referansı kendi sistemine ait iç bir numarayla eşleştirmek, dış referansı yalnızca yönetici log'unda tutmaktır. Sağlam bir e-pin satış scripti bunu otomatik yapar: bayinin gördüğü her kayıt senin numaralandırma düzeninle üretilir, dış dünyaya dair hiçbir iz taşımaz.
Diğer Bayilerin Verisi Sızdığında Ne Kaybedersin?
Kademeli fiyatlandırma yapıyorsan, bayi listesinin veya başka bir bayinin fiyatının görünmesi sistemi anında bozar. Küçük bayi büyük bayinin fiyatını gördüğünde "ben neden pahalıya alıyorum" sorusunu sorar ve ciro taahhüdüne dayalı kademe mantığın tartışmaya açılır. Daha sinsi bir sızıntı biçimi de var: sıralama listeleri, "en çok satan bayi" tabloları, ortak bildirim panoları. Kimlik göstermeyen bir tablo bile satış hacmi bandını açık eder. Panelde bayiler arası hiçbir veri temas noktası bırakmamak gerekir; performans karşılaştırması istiyorsan yüzdelik dilim göstermekle yetin, rakam ve isim verme.
Bayi kaynaklı veri sızıntılarının dağılımı
- Tedarikçi / kaynak izi 45%
- Maliyet ve marj alanları 25%
- Stok ve kod havuzu 20%
- Son müşteri verisi 10%
Son Müşteri Verisi: Hem Ticari Hem Hukuki Bomba
Bayinin kendi müşterisinin verisini görmesi normaldir. Fakat çok katmanlı yapıda üst bayinin alt bayinin müşterisini görmesi hem ticari hem hukuki bir sorundur. Ticari tarafı basit: üst bayi o müşteriye doğrudan satmaya başlar. Hukuki tarafı daha ağır; işlediğin kişisel veriyi zincirin her halkasına açmak veri minimizasyonu ilkesine aykırıdır ve bir şikâyet halinde savunulabilir bir gerekçen olmaz. Panelde telefon ve e-posta alanlarını maskeli tutmak, tam veriye erişimi yalnızca sipariş itirazı akışına bağlı geçici bir izinle vermek doğru kurulumdur. İyi bir dijital ürün satış yazılımı bu geçici erişimleri log'lar; kim, ne zaman, hangi kaydı açtı bellidir.
Ekranda Göstermemek Yetmez: Sızıntının Asıl Yeri API Katmanı
Burada çoğu kişinin gözden kaçırdığı asıl mesele var. CSS ile gizlemek, alanı display:none yapmak veya şablondan silmek güvenlik değildir. Veri ağ trafiğinde geliyorsa, tarayıcı geliştirici araçlarını açan herkes onu okur. Aynısı ihracat dosyaları için de geçerli: Excel çıktısı çoğu kurulumda tüm kolonları taşır, PDF fişinde tedarikçi referansı kalır, e-posta bildirim şablonunda maliyet alanı görünür. Yetkiyi sunucu tarafında, sorgu seviyesinde kurmak zorundasın; bayi rolünün sorgusu maliyeti hiç seçmemeli. Pinova'nın rol mimarisi tam bu mantıkla çalışır: her rol için ayrı veri seti tanımlanır, gizli alan sorguya hiç girmediği için sızacak bir yer kalmaz.
Bayi hesabıyla giriş yap, bir ürün sayfasında tarayıcı geliştirici araçlarını aç ve ağ sekmesindeki yanıtı oku. Ekranda görünmeyen ama yanıtta duran her alan sızmış veri sayılır. Aynı testi Excel çıktısı ve sipariş fişi için de yap.
| Kontrol | Nasıl doğrularsın? | Beklenen sonuç |
|---|---|---|
| Maliyet alanı API yanıtında var mı? | Bayi hesabıyla ağ sekmesi incelemesi | Alan hiç dönmemeli |
| Stok sayısal mı, etiket mi? | Ürün listesi görünümü | Etiket (Stokta / Son adetler) |
| Dış referans numarası görünüyor mu? | Sipariş detayı ve PDF fişi | Yalnızca iç numaralandırma |
| Excel çıktısı hangi kolonları taşıyor? | Bayi rolüyle dışa aktarma | Panelde görünen kolonlar kadar |
| Müşteri telefonu maskeli mi? | Sipariş kaydı görünümü | Kısmi maskeleme |
| Alt bayi müşterisi üst bayiye açık mı? | Çok katmanlı test hesabı | Kapalı olmalı |
| Erişim log'u tutuluyor mu? | Yönetici denetim kaydı | Kullanıcı, zaman, kayıt |
| Bayiler arası veri teması var mı? | Sıralama ve bildirim ekranları | Hiçbir temas olmamalı |
Peki Bayinin Görmesi Gereken Nedir?
Veri kısmak, bayiyi kör etmek anlamına gelmez. Bayinin işini yapabilmesi için gerekenler nettir: kendi bakiyesi ve hareket dökümü, kendi alış fiyatı ve önerilen satış fiyatı, ürünün satılabilir olup olmadığı, kendi siparişlerinin durumu, kendi iade ve itiraz kayıtları, kendi komisyon hesabı ve kendi API anahtarı. Bu yedi kalem iyi tasarlanmış bir panelde bayiyi tamamen bağımsız kılar ve sana gelen destek mesajlarını ciddi biçimde azaltır. Fazlası bilgi değil, kaldıraçtır ve o kaldıraç senin elinde kalmalı. Panelin nasıl bölümlendiğini görmek istersen özellikler bölümüne bakabilir, kademeli yapıyı fiyatlandırma sayfasından inceleyebilirsin.
Panelini rol bazında kapatmaya hazır mısın?
Pinova, bayi ve alt bayi rollerini sorgu seviyesinde ayırır; maliyet, tedarikçi izi ve kod havuzu bayi katmanına hiç inmez.
Bayiye stok sayısını hiç göstermemek satışı düşürür mü?
Hayır. Bayinin satış kararı için ihtiyacı olan bilgi ürünün satılabilir olup olmadığıdır. "Stokta" ve "Son adetler" etiketleri bu kararı tamamen karşılar, hatta son adetler etiketi aciliyet yaratarak satışı hızlandırır.
Alanı şablondan silmek yeterli bir koruma mı?
Değil. Veri ağ yanıtında, Excel çıktısında veya e-posta şablonunda dolaşmaya devam ediyorsa sızmıştır. Yetkilendirmenin sunucu tarafında, veriyi hiç çekmeyecek biçimde kurulması gerekir.
Üst bayi alt bayinin müşterisini görebilmeli mi?
Görmemeli. Hem alt bayinin müşterisine doğrudan satış riski doğar hem de gereksiz kişisel veri paylaşımı yapılmış olur. İtiraz süreçleri için geçici ve log'lanan erişim yeterlidir.
Kaç yetki katmanı olması gerekir?
Pratikte dört katman işi çözer: yönetici, operasyon personeli, bayi ve alt bayi. Her katmanın kendi veri seti olmalı; katmanlar arası miras yerine açık tanım kullanılmalı.
Panel güvenliği bir eklenti değil, mimari karardır; sonradan yamayla kapatılan her alan geride bir iz bırakır. Kendi bayi yapını kurarken hangi verinin hangi role gittiğini bir tabloya dökmek, ilk günden itibaren sana yıllarca pazarlık gücü kazandırır. Rol bazlı görünümlerin gerçek bir kurulumda nasıl davrandığını kendi gözünle test etmek istersen canlı demo üzerinden bayi hesabıyla gezin ve yukarıdaki beş dakikalık sızıntı testini birebir uygula; hangi alanın hangi katmanda durduğunu tek oturumda göreceksin.