Bayilik ilişkisinin kurulması herkesin ilgi alanındadır: kademe belirlenir, fiyat listesi paylaşılır, panel açılır, ilk sipariş kutlanır. Çıkış tarafını ise neredeyse hiç kimse önceden planlamaz. Çoğu işletmeci bayi ayrıldığında olacak şeyin "hesabı kapatmak" olduğunu sanır. Gerçekte olan şey bundan çok farklıdır: bir veri, alacak ve müşteri devri süreci başlar ve bu sürecin kuralları önceden yazılmadıysa, kuralları ayrılan taraf yazar.
Asıl kayıp da burada oluşur. Bayi giderken paneldeki bakiyesini tartışır, alt bayilerini kendi yanına çeker, kendi müşterilerinin sipariş geçmişini dışa aktarır ve bekleyen teslimatları kimin tamamlayacağı belirsiz kalır. Sen bu arada "ayrılık" konuşurken o "devir" yapıyordur. Bu yazıda çıkışın hem hukuki hem operasyonel hem de e-pin satış scripti tarafını tek tek açıyoruz; çünkü çıkış iyi tasarlandığında kayıp değil, temiz bir kapanış olur.
Bayi Ayrılırken Aslında Neyi Yanına Alır?
Bir bayinin senden aldığı şey sadece indirimli fiyat değildir. Zamanla panelde biriken bir varlık kümesi oluşur: kendi müşteri kayıtları, o müşterilerin sipariş geçmişi, alt bayi hiyerarşisi, kendi belirlediği satış fiyatları, entegrasyon anahtarları, fatura arşivi ve varsa açık cari hesabı. Çıkışta bu kalemlerin her biri için ayrı bir soru sorulmalıdır: kimin, hangi formatta, ne zamana kadar.
Bu soruların cevabını baştan vermezsen, çıkış anında pazarlık masasında olursun. Ve o masada sen "sistemde öyle bir özellik yok" dediğin her seferinde bayi "o zaman müşterilerimi tek tek arayıp taşırım" diyebilir. Çıkışın kontrolü, çıkışta değil sözleşme ve panel tasarımında kazanılır.
Sözleşmede Olmayan Şey Panelde de Yoktur: Veri Sahipliği Maddesi
Veri sahipliği maddesi, bayilik sözleşmelerinin en sık atlanan bölümüdür. Oysa yazılması gereken şey karmaşık değil. Üç ayrımı netleştirmen yeterli: bayinin kendi getirdiği müşteri verisi, senin platformun ürettiği işlem verisi, ve ikisinin kesişimi olan sipariş kayıtları. Genel kabul gören yaklaşım şudur: müşteri kimlik verisi bayiye, işlem ve teslim verisi platforma, sipariş kayıtları ise her iki tarafa kendi ilgili kısmıyla açık olur.
Buna ek olarak üç pratik madde daha gerekir. Birincisi, çıkış talebinden sonra verinin hangi süre içinde ve hangi formatta teslim edileceği. İkincisi, alt bayilerin durumu: ayrılan bayi alt bayilerini götürebilir mi, yoksa alt bayiler doğrudan platforma mı bağlanır. Üçüncüsü, teslim edilmiş kodların garanti ve iade sorumluluğunun kimde kalacağı. Bu üç maddenin olmadığı bir ilişkide her çıkış ayrı bir müzakereye dönüşür.
| Devir kalemi | Doğal hak sahibi | Devir yöntemi | Atlanırsa risk |
|---|---|---|---|
| Müşteri kimlik ve iletişim verisi | Bayi | Şifreli CSV, tek seferlik indirme | Veri koruma şikâyeti |
| Sipariş ve teslim geçmişi | Ortak | Bayiye kendi kayıtları, platforma tümü | İade ve garanti anlaşmazlığı |
| Alt bayi hiyerarşisi | Sözleşmeye bağlı | Üst bağ değişikliği, alt bayilere bildirim | Ağ kaybı, çift tedarik |
| Kalan panel bakiyesi | Bayi | Mutabakat sonrası banka iadesi | Hukuki takip |
| Bekleyen siparişler | Platform sorumlu | 72 saatte tamamla veya iade | Son kullanıcı şikâyeti |
| API anahtarı ve entegrasyon | Platform | Tarihli iptal, kademeli kapatma | Bayi sitesinde ani kesinti |
| Fatura ve muhasebe arşivi | Ortak | PDF paket, yasal saklama süresince erişim | Vergi denetimi sorunu |
Devirde En Çok Kırılan Halka: Bekleyen Siparişler ve Emanet Bakiye
Çıkış anında panelin içinde üç tür "asılı" kayıt bulunur. Birincisi ödemesi alınmış ama teslimi tamamlanmamış siparişler. İkincisi stok beklediği için kuyrukta duran talepler. Üçüncüsü iade veya garanti incelemesinde olan kodlar. Bu üç kümeyi çıkış anında dondurup tek tek kapatmazsan, bayi gittikten iki hafta sonra bir son kullanıcı sana yazar ve muhatap kalmaz.
Emanet bakiye ise en hassas kalemdir. Doğru sıra şudur: önce hesap yeni sipariş almayacak şekilde kısıtlanır, sonra bekleyen işlemler kapatılır, ardından iade penceresi süresi kadar beklenir, en son mutabakat imzalanır ve kalan tutar iade edilir. Bu sırayı bozup bakiyeyi en başta iade edersen, sonradan çıkan bir iade talebinin maliyeti sana kalır. Dijital ürün satış yazılımında bu adımların "çıkış modu" gibi tek bir durum olarak tanımlanması, işi sürekli elle takip etmekten kurtarır.
Bayi Çıkışlarında Yaşanan Anlaşmazlıkların Konusu
- Kalan bakiye ve mutabakat 45%
- Müşteri verisinin devri 25%
- Alt bayi ağının aidiyeti 20%
- Garanti ve iade sorumluluğu 10%
Alt Bayi Ağını Kime, Nasıl Bağlarsın?
Çok kademeli yapılarda gerçek değer alt bayi ağındadır. Ayrılan bir üst bayinin altında on beş küçük satıcı varsa, onların nereye bağlanacağı senin cironun kaderini belirler. Burada iki model var. Birincisi "ağ bayiye aittir" modeli: üst bayi gittiğinde alt bayiler de onunla gider, sen sadece net bir kopuş yaşarsın. İkincisi "ağ platformda kalır, komisyon bayiye aittir" modeli: alt bayiler senin sisteminde hesap sahibidir, üst bayi sadece komisyon alır ve gittiğinde alt bayiler doğrudan sana bağlanır.
İkinci modelin şart koştuğu tek şey teknik olarak alt bayinin kendi hesabının bulunması ve üst bağın bir alan olarak değiştirilebilmesidir. Bunu destekleyen bir epin yazılımında üst bayi çıkışı bir felaket değil, tek bir toplu güncelleme işlemidir. Desteklemeyen bir altyapıda ise alt bayiler üst bayinin hesabının içinde yaşadığı için ağ otomatik olarak onunla gider.
Entegre bayinin anahtarını bir anda iptal etmek, onun sitesindeki son kullanıcıları ortada bırakır ve şikâyetler dönüp sana gelir. Doğru yol tarihli iptaldir: yeni sipariş kabulünü kapat, mevcut sorguları 72 saat daha yanıtla, sonra anahtarı tamamen kapat. Bu üç günlük pencere hem ticari itibarını hem hukuki pozisyonunu korur.
Çıkış Denetimini Tek Listeye Nasıl İndirirsin?
Çıkış süreci duygusal gerginlik taşıdığı için hafızaya bırakılmaya en uygunsuz süreçtir. Bu yüzden tek doğru yöntem yazılı bir denetim listesidir. Aşağıdaki liste, bir bayilik ilişkisi sona ererken kapatılması gereken dokuz kalemi sırasıyla veriyor. Sıra önemli: veri teslimi mutabakattan önce, bakiye iadesi iade penceresinden sonra gelir.
| Sıra | Çıkış denetimi kalemi | Tamamlanma kriteri | Süre |
|---|---|---|---|
| 1 | Hesabı yeni sipariş alamayacak moda geçir | Sipariş butonu kapalı, giriş açık | Aynı gün |
| 2 | Bekleyen teslimatları tamamla veya iade et | Kuyrukta sıfır kayıt | 72 saat |
| 3 | Açık garanti ve iade taleplerini kapat | Talep listesi boş | 7 gün |
| 4 | Alt bayilerin üst bağını güncelle | Alt bayiler sipariş verebiliyor | 48 saat |
| 5 | Müşteri verisini şifreli paket olarak teslim et | İndirme kaydı loglandı | 5 gün |
| 6 | Fatura arşivini PDF paket hâline getir | Paket teslim edildi | 5 gün |
| 7 | Cari mutabakat metnini imzala | Karşılıklı yazılı onay | 10 gün |
| 8 | Kalan bakiyeyi banka üzerinden iade et | Dekont dosyaya eklendi | Mutabakat sonrası |
| 9 | API anahtarını tarihli olarak kapat | Sıfır yetkili çağrı | 72 saat sonra |
Çıkışı bir kriz değil, bir prosedür yap
Çıkış modu, tarihli anahtar iptali, alt bayi üst bağ güncellemesi ve şifreli veri dışa aktarma; hepsi panelin doğal parçası olduğunda bayilik sonlandırmak on dakikalık bir iş olur. Pinova'nın bayi ve yetki yönetimini kendi yapına göre değerlendir.
Bayinin müşteri listesini vermek zorunda mıyım?
Bayinin kendi getirdiği müşterilerin iletişim verisini, sözleşmede aksi yazmıyorsa vermek hem hakkaniyetli hem de risk azaltıcıdır. Vermediğinde bayi bu veriyi zaten kendi kayıtlarından toplar, sen ise gereksiz bir ihtilaf yaratmış olursun. Önemli olan teslimin şifreli, tek seferlik ve loglanmış olmasıdır.
Kalan bakiyeyi hemen iade etmem gerekir mi?
Hayır, doğru sıra iade penceresi kapandıktan sonrasıdır. Bekleyen teslim ve garanti talepleri kapanmadan yapılan iade, sonradan çıkan maliyetin tamamını senin üstünde bırakır. Mutabakat metni imzalandıktan sonra iade etmek her iki taraf için de güvenlidir.
Alt bayiler otomatik olarak bende kalır mı?
Bu tamamen yapıya bağlıdır. Alt bayiler senin sisteminde kendi hesaplarıyla duruyorsa üst bağı değiştirip elinde tutabilirsin. Üst bayinin hesabının alt kırılımı olarak tanımlanmışlarsa teknik olarak onunla giderler; bu yüzden hiyerarşi kurgusu en başta doğru seçilmelidir.
Çıkış sürecini yazılım üzerinden yönetmenin avantajı ne?
Her adımın tarih ve kullanıcı bilgisiyle loglanması, sonradan çıkan bir anlaşmazlıkta elindeki tek objektif kanıttır. İyi bir e-pin satış scripti çıkış modunu bir durum olarak tanımlar ve sıralamayı sana hatırlatır; böylece süreç kişilerin hafızasına değil sisteme bağlı çalışır.
İyi tasarlanmış bir çıkış süreci, paradoksal biçimde bayi kalma oranını da yükseltir; çünkü kuralların net olduğu bir ilişkide taraflar daha rahat çalışır ve ayrılık tehdit aracı olmaktan çıkar. Çıkış modu, tarihli anahtar iptali ve alt bayi bağ güncellemesinin gerçek bir panelde nasıl işlediğini görmek için canlı demo içindeki bayi yönetimi bölümünü aç; ardından kendi bayi kademelerine uygun paketi fiyat tablosundan karşılaştırabilirsin.