Epin Satış Scripti Bayi Başvuru ve Onay Akışı: Kötü Bayiyi Sisteme Girmeden Eleyen 7 Durumlu Sessiz Filtreyi Adım Adım Kuruyoruz

Çoğu işletme sahibi bayi başvurusunu bir fırsat olarak okur: form doldu, demek ki ciro geliyor. Oysa saha gerçeği tersine yakındır. Gelen başvuruların önemli bir kısmı ya fiyat öğrenmeye çalışan rakip, ya tek seferlik toptan alım yapıp kaybolacak bir aracı, ya da geri ödeme itirazı (chargeback) geçmişi olan riskli bir hesaptır. Bayi ağını büyütmenin sırrı çok başvuru almak değil; yanlış başvuruyu içeri almamaktır.

İyi tasarlanmış bir epin satış scripti bu elemeyi senin yerine, sen uyurken yapar. Başvuru formundan onaya, belge doğrulamadan ilk siparişe kadar süreç durum makinesi gibi işler; her adımda kim ne yaptı kayıt altındadır. Bu yazıda o akışı yedi duruma ayırıp tek tek kuruyoruz. Sonunda kendi dijital ürün satış yazılımında hangi kapının eksik olduğunu göreceksin.

Başvuru formu bir kapı mı, filtre mi olmalı?

Yaygın hata, formu mümkün olduğunca kısa tutmaktır. "Sürtünmeyi azalt" mantığı e-ticarette doğrudur ama bayilikte tam tersi işler. Bayi başvurusu bilinçli bir emek gerektirmeli; çünkü emek harcamaya razı olan kişi zaten ciddi olandır. İki dakikada dolan form sana yüz başvuru getirir, bunların doksanı boşa çıkar.

Buna karşılık formu uzatmak da tek başına çözüm değil. Önemli olan ayırt edici soruları sormaktır. Bunlar üç tanedir: halihazırda nereden satış yapıyorsun (site, sosyal hesap, fiziki dükkân), aylık tahmini alım hacmin nedir, hangi ürün gruplarıyla ilgileniyorsun. Bu üç yanıt, başvurunun ciddiyetini yüzde yetmiş doğrulukla ele verir. Boş bırakılan veya "hepsi" yazılan hacim alanı, güçlü bir uyarı işaretidir.

Teknik tarafta formun üç koruması olmalı: aynı IP'den tekrarlı gönderim engeli, e-posta doğrulama bağlantısı ve tek kullanımlık e-posta servislerine karşı alan adı kara listesi. Bu üç koruma, otomatik bot başvurularının neredeyse tamamını sessizce keser.

Belge doğrulama: vergi levhası mı, kimlik mi yeterli?

Bu soruya tek cevap yok; bayi tipine göre kademeli belge istemek en sağlıklısıdır. Küçük hacimli, sadece kendi sosyal hesabından satış yapan bireysel bayiden vergi levhası istemek başvuruyu öldürür. Aylık yüksek hacim talep eden, faturalı çalışmak isteyen kurumsal bayiden levha istememek ise seni vergisel ve hukuki olarak açıkta bırakır.

Pratik kurgu şudur: bireysel bayide kimlik ön yüzü ve iletişim doğrulaması yeterlidir, karşılığında düşük limit ve sadece ön ödemeli çalışma verilir. Kurumsal bayide vergi levhası, imza sirküleri veya yetki belgesi ve banka hesap bilgisi istenir; karşılığında daha iyi fiyat listesi ve daha yüksek limit açılır. Belgenin karşılığı ayrıcalık olmalı; zorunluluk değil, ödül gibi konumlanmalı.

Belge yükleme tarafında iki teknik detay ihmal edilmemeli. Birincisi yüklenen dosyalar web kökünün dışında, tahmin edilemez adlarla saklanmalı ve panelden yetkili erişimle gösterilmeli. İkincisi dosya tipi ve boyutu sunucu tarafında doğrulanmalı; uzantı kontrolü tek başına güvenlik değildir.

Onay akışının yedi durumu nasıl işler?

Başvuruyu "bekliyor" ve "onaylandı" diye ikiye bölmek, ilk elli başvuruda bile yetersiz kalır. Çünkü aradaki gerçeklik çok daha zengindir: belge eksik olabilir, görüşme bekliyor olabilir, şartlı onay verilmiş olabilir. Durum sayısını artırmak bürokrasi değil, görünürlük sağlar.

Önerdiğim yedi durum şu: yeni, e-posta doğrulandı, belge bekleniyor, incelemede, şartlı onay, aktif ve reddedildi. Her durum geçişi kim tarafından, ne zaman, hangi notla yapıldı biçiminde kaydedilmeli. Böylece ekipten biri işten ayrıldığında bile geçmiş anlaşılır kalır.

Kritik nokta şartlı onay. Bu durum, bayinin panele girip fiyat listesini görebildiği ama sipariş veremediği ara aşamadır. Ciddi olan bayi buraya gelince hemen bakiye yükler; ciddi olmayan ise hiç dönmez. Bu tek aşama, boşa harcanan destek zamanını belirgin biçimde azaltır.

Depozito ve ilk yükleme kapısı gerçekten gerekli mi?

Bu konuda net bir görüşüm var: gerekli. Ancak adını doğru koymak şart. Depozito, cezalandırıcı bir bedel değil; bayinin niyetini gösteren asgari ilk yükleme olarak tasarlanmalı. Yani para sana kalmaz, doğrudan bayinin harcanabilir bakiyesine geçer. Bayi için kayıp yoktur, senin için ise ciddiyet filtresi oluşur.

Rakamı pazar segmentine göre belirle. Çok düşük tutar filtre işlevi görmez, çok yüksek tutar iyi bayileri de kaçırır. Uygulamada asgari ilk yükleme, bayinin bir haftalık tahmini alımının yarısı civarında tutulduğunda hem yönetilebilir hem ikna edici olur. Ayrıca bu tutarı fiyat listesi kademesine bağlamak güçlü bir teşviktir: daha yüksek ilk yükleme, daha iyi fiyat grubu demektir.

Sözleşme, KVKK ve iz kaydı: hangi onayları saklamalısın?

Bayi başvurusu, hukuken bir ticari ilişkinin başlangıcıdır ve bu ilişkinin dijital izi kalmak zorundadır. Asgari üç onay kutusu ve her birinin kaydı gerekir: bayilik şartları metni, kişisel verilerin işlenmesine ilişkin aydınlatma ve ticari iletişim izni. Bu onayların hangi metin sürümüyle, hangi IP'den, hangi saniyede verildiği saklanmalı.

Detay şurada: metin sürümlenmeli. Bayilik şartlarını altı ay sonra güncellediğinde, eski bayilerin hangi sürümü kabul ettiğini bilmen gerekir. Sürüm tutmayan sistemlerde bir anlaşmazlık çıktığında elinde sadece güncel metin olur ve bu, geçmişe dönük olarak seni savunmasız bırakır. İyi kurulmuş bir e-pin scripti bu sürüm kaydını otomatik tutar.

Ayrıca personel hareketleri de izlenmeli. Bir başvuruyu kim onayladı, kim reddetti, kim belge doğrulamasını atladı. Bayi ağında en sık görülen iç risk, bir çalışanın tanıdığına belge almadan yüksek limitli hesap açmasıdır. İz kaydı bu davranışı caydırır.

Reddetmeyi nasıl yönetirsin ki köprüler yanmasın?

Reddedilen her başvuru potansiyel bir gelecek bayidir; bugün küçük olan altı ay sonra büyük olabilir. Bu yüzden ret mesajı kişisel ve kaba olmamalı, gerekçe de tam şeffaf olmamalı. Doğru formül şu: nazik dil, kapalı gerekçe, açık bir yeniden başvuru yolu. "Şu an bayi kabul kriterlerimizle eşleşmiyor, 90 gün sonra yeniden değerlendirebiliriz" cümlesi hem ilişkiyi korur hem seni gerekçe tartışmasına sokmaz.

Kara liste ise ayrı bir mekanizmadır ve yalnızca somut zarar durumunda kullanılmalı: ödeme itirazı, dolandırıcılık girişimi, sahte belge. Kara listeye alınan kayıt, e-posta ve telefonun yanında ödeme kimliği düzeyinde de eşleşmeli; aksi halde aynı kişi yeni e-postayla dakikalar içinde geri döner.

Akışı devreye almadan önceki kontrol listesi

Aşağıdaki satırların her biri sahada karşılığı olan, kanla yazılmış kontrollerdir. Kendi akışını bu tabloyla karşılaştır.

Bayi başvuru akışı, satış ekibinin değil sistemin işi olduğunda ölçeklenir. Yedi durumu kur, belge talebini kademelendir, asgari ilk yükleme kapısını ekle ve onay süresini metriğe bağla; gerisi kendiliğinden düzelir. Bu akışın hazır haliyle nasıl işlediğini görmek istersen canlı demo üzerinden bayi başvuru ekranlarını uçtan uca deneyebilirsin.