B2B Affiliate (Satış Ortaklığı) ve Bayi Komisyon Dağıtım Mimarisi

B2B Affiliate (Satış Ortaklığı) ve Bayi Komisyon Dağıtım Mimarisi

Yazar: Kumsal AjansOluşturulma: Güncellenme: 8 dk okuma
Henüz puanlanmadı Puanınız:

Blog yazısı içeriği

B2B satış ortaklığı ve bayi kanalları büyüdükçe komisyon yönetimi, bir oranı satış tutarıyla çarpmaktan çok daha kapsamlı hâle gelir. Aynı müşteri bir bayi tarafından kazanılmış, affiliate bağlantısıyla siteye gelmiş ve siparişini kurumsal satış temsilcisi üzerinden tamamlamış olabilir. Ürün grubu, müşteri segmenti, kampanya, sözleşme tarihi ve tahsilat durumu da ödenecek komisyonu değiştirebilir. Bu nedenle sürdürülebilir bir B2B affiliate sistemi; satışın kaynağını kanıtlayan, geçerli kuralı açıklayan ve her hakediş hareketini izlenebilir tutan projeye özel bir yazılım mimarisi gerektirir.

Sağlam mimarinin amacı yalnızca doğru tutarı hesaplamak değildir. Satış, finans, operasyon ve bilgi teknolojileri ekiplerinin aynı işlem üzerinde ortak bir gerçeklik görmesini sağlamaktır. Hangi ortağın neden hak kazandığı, hangi sözleşme sürümünün uygulandığı, iadenin hangi dönemi etkilediği ve ERP’ye ne aktarıldığı açıkça cevaplanabilmelidir. Hazır bir komisyon modülü bu bağlamı karşılamadığında bayi portalı, e-ticaret, ERP ve ödeme sistemleri arasında çalışan kuruma özel bir yapı gerekir.

B2B affiliate ve bayi komisyon yönetimi nedir?

B2B affiliate modeli, bir satışın oluşmasına katkı sağlayan iş ortağının belirlenmesi ve tanımlı koşullar gerçekleştiğinde bu ortağa komisyon tahakkuk ettirilmesidir. İş ortağı bir bayi, distribütör, çözüm ortağı, yönlendirme yapan danışman veya dijital affiliate olabilir. Bayi komisyon yönetimi ise bu ilişkinin sözleşme, bölge, müşteri portföyü, ürün ailesi, ciro hedefi ve tahsilat gibi daha kurumsal değişkenlerle yürütülmesini kapsar.

Buradaki kritik ayrım satış kaydı ile hakediş kaydının aynı şey olmamasıdır. Sipariş alınmış olsa bile sevkiyat, fatura veya tahsilat tamamlanmadan komisyon doğmayabilir. Bir siparişin iptali hakedişi tamamen kaldırırken kısmi iade yalnızca ilgili satırın komisyonunu geri alabilir. Sistem bu olayları tek bir bakiyeyi sürekli değiştirerek değil, gerekçeli ve tarihçeli finansal hareketler şeklinde yönetmelidir.

Mimari neden hazır bir komisyon ekranından ibaret değildir?

Komisyonun doğruluğu, birden fazla sistemden gelen verilerin anlamlı biçimde birleşmesine bağlıdır. E-ticaret platformu oturum ve sipariş kaynağını, CRM müşteri sahipliğini, ERP fatura ve iade durumunu, ödeme altyapısı tahsilatı taşıyabilir. Komisyon motoru ise bu verilerin hangi anda kesinleştiğini ve hangi kuralla değerlendirileceğini bilmelidir. Dolayısıyla çözüm; entegrasyon katmanı, satış ilişkilendirme servisi, kural motoru, hakediş defteri, onay akışı, bayi portalı ve raporlama bileşenlerinden oluşur.

Entegrasyonlarda aynı olayın yeniden gönderilebileceği baştan kabul edilmelidir. Microsoft’un asenkron mesajlaşma mimarisi rehberi, tekrar teslim edilen mesajların sistem durumunu ikinci kez değiştirmemesi için tüketici işlemlerinin idempotent tasarlanmasını önerir. Sipariş, fatura veya tahsilat tekrar geldiğinde ikinci bir komisyon üretmemek için kaynak sistem, işlem türü ve benzersiz kayıt kimliğinden oluşan bir tekillik anahtarı kullanılabilir.

Satışın doğru ortakla ilişkilendirilmesi

Komisyon hesaplamasından önce satışın kime ait olduğuna karar verilmelidir. Dijital kanalda takip bağlantısı, kampanya kodu, çerez veya oturum kaydı kullanılabilir. Kurumsal satışlarda bayi tarafından açılan fırsat, kayıtlı müşteri portföyü, teklif numarası, bölge veya satış temsilcisi ilişkisi daha güçlü kanıt olabilir. Tek bir ilişkilendirme yöntemi bütün kanallarda güvenilir sonuç vermez; sistem kanıt türlerini ve önceliklerini iş modeline göre tanımlamalıdır.

Atıf önceliği ve kanıt kaydı

Çakışan talepler için açık bir öncelik sırası gerekir. Örneğin onaylanmış fırsat kaydı, genel affiliate bağlantısından daha güçlü kabul edilebilir; sözleşmeli müşteri sahipliği ise kampanya kodunun önüne geçebilir. Kural motoru yalnızca kazanan ortağı değil, kararın girdilerini de saklamalıdır. Kaynak kodu, fırsat kaydı, müşteri eşleşmesi, zaman damgası ve uygulanan öncelik maddesi sonradan incelenebilmelidir.

Mükerrer müşteri ve sipariş kontrolü de bu aşamanın parçasıdır. Vergi numarası, ERP cari kodu, sipariş numarası ve kaynak işlem kimliği uygun güven seviyeleriyle eşleştirilmelidir. Benzer unvanlara dayanarak otomatik birleşim yapmak risklidir; belirsiz kayıtlar inceleme kuyruğuna gönderilmelidir. Web kanalı ile satış ekibi arasındaki veri sahipliğini planlarken web sitesi–CRM entegrasyonu için kullanılan alan eşleştirme ve mükerrer kayıt yaklaşımı da yol gösterici olabilir.

Komisyon kural motoru nasıl tasarlanır?

Kural motoru sözleşme koşullarını yazılım içinde açıklanabilir kararlara dönüştürür. Kurallar; ortak türü, ürün veya kategori, müşteri segmenti, satış kanalı, bölge, para birimi, ciro basamağı ve geçerlilik dönemi gibi alanları kullanabilir. Yüzde oranı, sabit tutar, kademeli prim, hedef aşımı bonusu veya marj üzerinden pay gibi farklı sonuç tipleri desteklenebilir.

Öncelik, çakışma ve sürümleme

Aynı satış birden çok kurala uyduğunda hangisinin önce uygulanacağı belirlenmelidir. Özel sözleşme genel bayi tarifesinin, müşteri istisnası ürün kampanyasının önüne geçebilir. Birleştirilebilen ve birbirini dışlayan kurallar ayrıca işaretlenmelidir. Sistem kararı kural adıyla sınırlamamalı; öncelik, koşul değerleri, hesap tabanı, oran, kesinti ve yuvarlama yöntemini dökümde göstermelidir.

Kurallar geçmişe dönük değiştirilmemelidir. Her değişiklik yeni bir sürüm olarak, başlangıç ve gerekirse bitiş tarihiyle yayınlanmalıdır. Onaylanmış bir hakediş, daha sonra güncellenen oranla sessizce yeniden hesaplanmamalıdır. Düzeltme gerekiyorsa eski hareketi koruyan ters kayıt ve yeni hesap hareketi oluşturulmalıdır. Böylece finans ekibi geçmiş dönem raporlarını yeniden üretebilir, bayi ise tutarın neden değiştiğini görebilir.

Hakediş yaşam döngüsü nasıl kurulmalıdır?

Hakediş tek adımlı bir ödeme kaydı değil, kontrollü bir durum makinesi olarak ele alınmalıdır. Önerilen akış; taslak hesaplama, kontrol bekliyor, onaylandı, ödemeye hazır, ERP’ye aktarıldı ve ödendi durumlarını içerir. İhtiyaca göre itirazda, bloke veya düzeltildi durumları eklenebilir. Her geçişi yapan kullanıcı, zaman, açıklama ve önceki değer denetim izine yazılmalıdır.

  • Taslak aşamasında satış, sözleşme ve kaynak kanıtı doğrulanır.
  • Kontrol aşamasında istisnalar ve yüksek tutarlı işlemler incelenir.
  • Onay sonrasında dönem kilitlenir ve yetkisiz değişiklik engellenir.
  • ERP aktarımında fiş, masraf, cari veya ödeme belgesi referansı alınır.
  • Ödeme sonrasında banka ya da ERP sonucu bayi portalına yansıtılır.

Onay akışı tutar, ortak tipi, iş birimi veya istisna sebebine göre değişebilir. Belirli limitin üzerindeki hakedişler finans yöneticisine, manuel atıf değişiklikleri kanal yöneticisine yönlendirilebilir. Vekâlet, görev ayrılığı ve süre aşımı tanımları unutulmamalıdır. Benzer kontrol mantıkları için B2B sipariş onay akışı yaklaşımındaki rol, limit ve istisna ilkeleri uyarlanabilir.

İade, iptal ve dönem düzeltmeleri

İade ve iptal, komisyon sisteminin sonradan eklenen bir istisnası değil temel işlem türüdür. Sipariş ödeme öncesinde iptal edilirse taslak hakediş kaldırılabilir. Komisyon onaylandıktan veya ödendikten sonra gelen iade ise önceki kaydı silmemeli; ilgili satış satırına bağlı negatif düzeltme üretmelidir. Kısmi miktar, vergi, indirim ve para birimi etkisi hesap tabanına göre yeniden değerlendirilmelidir.

Dönem kapanmışsa negatif hareket sonraki açık döneme taşınabilir veya kurum politikasına göre alacak bakiyesine dönüştürülebilir. Bayinin bakiyesi yetersiz olduğunda mahsup sınırı, bekletme ve manuel karar seçenekleri tanımlanmalıdır. İade sebebi, ERP belgesi, önceki hakediş kimliği ve düzeltme kuralı birlikte saklandığında taraflar aynı kanıt seti üzerinden konuşabilir.

AşamaTemel kanıtAna kontrolÇıktı
İlişkilendirmeKaynak kodu / fırsatAtıf önceliğiOrtak kaydı
HesaplamaSözleşme sürümüKural çakışmasıKomisyon dökümü
OnayYetki / limitGörev ayrılığıKilitli hakediş
Düzeltmeİade belgesiÖnceki harekete bağNegatif hareket
ERP aktarımıAktarım kimliğiMükerrer gönderimERP belge no.

Bayi portalı hangi görünürlüğü sağlamalıdır?

Bayi portalı yalnızca toplam komisyon rakamı göstermemelidir. Ortak; satış tarihi, müşteri için izin verilen görünürlük, ürün veya kategori, net hesap tabanı, oran, hakediş durumu, iade kesintisi ve beklenen ödeme dönemini inceleyebilmelidir. Filtrelenebilir dökümler, belge indirme, itiraz açma ve itiraz yanıtlarını izleme iş yükünü azaltır.

Görünürlük veri güvenliğiyle dengelenmelidir. Bayi yalnızca kendi organizasyonuna ve yetkili olduğu alt hesaplara erişebilmelidir. OWASP’ın yetkilendirme rehberi, en az ayrıcalık, varsayılan olarak erişimi reddetme ve her istekte izin kontrolü ilkelerini vurgular. Bu nedenle rol tanımları ekran seviyesinde bırakılmamalı; satış, müşteri, belge ve hakediş nesnesi düzeyinde sunucu tarafında uygulanmalıdır.

ERP ve finans entegrasyonu

ERP’ye aktarılacak verinin muhasebe karşılığı analiz aşamasında netleştirilmelidir. Hakediş bir satın alma faturası beklentisi, gider tahakkuku, cari alacak veya ödeme talimatı olarak ele alınabilir. Şirket, ülke, vergi ve sözleşme yapısı bu modeli değiştireceğinden yazılım tek bir muhasebe varsayımını dayatmamalıdır. Hesap kodu, masraf merkezi, proje, iş birimi, cari kart ve belge tipi eşlemeleri yönetilebilir olmalıdır.

Aktarım başarılı sayılmadan önce ERP belge numarası alınmalı; zaman aşımında aynı kayıt kontrolsüz biçimde yeniden gönderilmemelidir. Başarısız işlemler hata kuyruğuna düşmeli, teknik hata ile eksik ana veri ayrılmalı ve yetkili kullanıcı güvenli yeniden deneme yapabilmelidir. Mutabakat raporu portal toplamı, ERP’ye kabul edilen tutar, reddedilen kayıt ve ödeme sonucunu dönem bazında karşılaştırmalıdır.

Denetim izi, kişisel veri ve güvenlik

Denetim kaydı; kimin, ne zaman, hangi değeri, hangi gerekçeyle değiştirdiğini göstermelidir. Kural yayınlama, satışın başka ortağa atanması, manuel komisyon, onay, ret, belge görüntüleme ve ERP yeniden gönderimi kritik olaylardır. Loglar uygulama kullanıcılarının değiştiremeyeceği biçimde korunmalı, korelasyon kimliğiyle entegrasyon hareketlerine bağlanmalıdır.

Müşteri ve kullanıcı verileri için amaç, saklama süresi ve erişim kapsamı belirlenmelidir. GDPR’nin resmî metnindeki kişisel veri işleme ilkeleri, veri minimizasyonu ve hesap verebilirlik açısından yararlı bir çerçeve sunar. Portalda komisyonu açıklamak için gerekmeyen müşteri alanları maskelenebilir; dışa aktarımlar yetkiye bağlanabilir ve saklama süresi dolan izleme verileri kurum politikası doğrultusunda temizlenebilir.

Uygulama projesi hangi aşamalarla ilerlemelidir?

Proje, ekran tasarımından önce iş kurallarının ve veri sahipliğinin keşfiyle başlamalıdır. Satıştan iadeye kadar örnek senaryolar, gerçek sözleşmeler ve istisnalar üzerinden modellenmelidir. Ardından kaynak sistem alanları, benzersiz kimlikler, olay sırası, gecikmeler ve hata koşulları belgelenir. Böylece entegrasyon ile iş kuralı arasındaki sınır netleşir.

  • Kanal, ortak, müşteri ve sözleşme modellerini çıkarın.
  • Atıf kanıtlarını, öncelikleri ve mükerrer kontrolünü tanımlayın.
  • Kural sürümlerini örnek satış ve iade senaryolarıyla doğrulayın.
  • Hakediş, onay, itiraz ve dönem kapanışını pilot grupla deneyin.
  • ERP aktarımı ile finansal mutabakatı uçtan uca test edin.

Canlıya geçiş öncesinde paralel hesap dönemi yürütmek faydalıdır. Mevcut Excel veya ERP sonucu ile yeni motorun sonucu karşılaştırılır; farklar hata olarak kapatılmadan önce veri, zamanlama ve sözleşme yorumu açısından sınıflandırılır. Başarı ölçütleri yalnızca hesap doğruluğu değil; istisna oranı, onay süresi, başarısız entegrasyon sayısı, itiraz çözüm süresi ve kapanış sonrasındaki düzeltme hacmi olmalıdır.

Kuruma özel mimariyle ölçeklenebilir komisyon yönetimi

B2B affiliate ve bayi komisyon dağıtımı; kural motoru, finansal hareket defteri, entegrasyon güvenilirliği ve kullanıcı yetkilerinin birlikte tasarlanmasını gerektirir. Doğru çözüm, satışın hangi ortağa ait olduğunu kanıtlar; hesaplamayı kullanılan sözleşme sürümüyle açıklar; iade ve iptalleri iz bırakarak düzeltir; onaylanan sonucu ERP’ye kontrollü biçimde taşır. Böylece bayi şeffaf bir döküm, finans mutabık bir kayıt, operasyon yönetilebilir bir istisna kuyruğu elde eder.

Kumsal Ajans, İstanbul merkezli bir dijital ajans olarak iş süreçlerini, kullanıcı rollerini, veri akışlarını ve entegrasyon gereksinimlerini aynı mimari içinde ele alır. Affiliate ve bayi komisyon süreçlerinizi mevcut satış kanallarınız, sözleşme kurallarınız ve ERP altyapınızla birlikte analiz ederek kuruma özel web yazılımı mimarisini planlamak için Kumsal Ajans ile iletişime geçin.

Anasayfa

Projelerimiz

Ürünlerimiz

Hizmetlerimiz