Komisyonlar ve Teşvikler için Web Uygulaması Nasıl Oluşturulur

Bir Komisyon ve Teşvik Uygulamasının Çözmesi Gerekenler

Bir komisyon ve teşvik uygulaması “sadece bir hesap makinesi” değildir. Ödemelere dokunan herkes için paylaşılan bir doğruluk kaynağıdır—böylece temsilciler sayılara güvenir, yöneticiler güvenle koçluk yapabilir ve finans bölümü hesap tabloları peşinde koşmadan dönemleri kapatabilir.

Uygulama kimler için

Çoğu ekip baştan dört kitlenin desteğine ihtiyaç duyar:

• Satış temsilcileri ne kazandıklarını ve nedenini gerçek zamanlı görmek ister.
• Yöneticiler performansı gözden geçirip istisnaları ele almak ve düzeltmeleri onaylamak ister.
• Finans/RevOps politika, uyumluluk, dönem kapanışı ve ödeme dosyalarının sahibi olur.
• Yöneticiler (Admins) kullanıcıları, izinleri, entegrasyonları ve plan değişikliklerini yönetir.

Her grubun farklı hedefleri vardır. Bir temsilci netlik ister. Finans kontrol ve izlenebilirlik ister. Ürün kararlarınız bu farklı “yapılacak işler”i yansıtmalıdır.

Çözülmeye değer problemler (ve neden önemli oldukları)

En yaygın ağrı noktaları öngörülebilirdir:

• Anlaşmazlıklar ve güvensizlik hesaplamalar kişisel hesap tablolarında veya belirsiz CRM raporlarında yapıldığında ortaya çıkar.
• Manüel işler verileri toplamak, kuralları uygulamak ve istisnaları mutabık kılmak için zaman alır.
• Yavaş ödemeler onaylar ve düzeltmeler e-posta zincirlerinde kaldığında gecikir.

İyi bir uygulama belirsizliği azaltır ve gösterir:

• Girdiler (anlaşmalar, tarihler, kredi dağılımı)
• Uygulanan kurallar (oranlar, kademeler, hızlandırıcılar)
• Çıktılar (kazançlar, beklemeler, geri alımlar)

Hedeflenecek başarı metrikleri

İnşa etmeden önce ölçülebilir sonuçları tanımlayın. Pratik metrikler şunlar olabilir:

• Ödeme doğruluğu (ör. bordro sonrası düzeltmelerin azalması)
• Bir dönem kapama süresi (dönem bitiminden onaylı ödemeye kadar geçen gün sayısı)
• İstisna oranı (manuel düzeltme gerektiren anlaşmaların oranı)

Bu kılavuzun kapsamı

Bu makale planlamadan MVP’ye bir yol haritasıdır: gereksinimleri taslak haline getirmek, paydaşları hizalamak ve komisyonları hesaplayan, inceleme/onay destekleyen ve ödeme için hazır dışa aktarımlar üreten ilk sürümü inşa etmek için yeterli ayrıntı. Eğer satıcıları değerlendiriyorsanız, bkz. /blog/buy-vs-build-commission-software.

Komisyon Kurallarınızı ve Teşvik Programlarınızı Netleştirin

Ekranları tasarlamadan veya bir satır kod yazmadan önce, tazminat kurallarınızı yeni bir satış temsilcisine nasıl açıklar gibi yazın. Plan düz yazıyla anlaşılamıyorsa, yazılımda temiz hesaplanamaz.

Gerçekte kullandığınız komisyon türlerini belgeleyin

Kapsamdaki her komisyon yöntemini ve nerede uygulandığını listeleyerek başlayın:

• Gelirin yüzdesi (ve gelir tanımını yapın: sözleşme değeri, fatura tutarı veya tahsilat)
• Marj bazlı komisyonlar (marjın nasıl hesaplandığı—indirimler, COGS, hizmetler, kredi notları)
• Kademeli oranlar (eşikler, ölçüm dönemi, kademelerin sıfırlanıp sıfırlanmadığı)
• Paylaşılan anlaşmalar (yüzdeye göre, kredi kurallarına göre, role göre—AE/SE/CSM)

Her biri için sayısal örnekler yakalayın. Her plan için bir çalışılmış örnek, politika metninin sayfalarca açıklamasından daha değerlidir.

Teşvikleri temel komisyonlardan ayrı yakalayın

Teşvikler genellikle farklı kurallara sahiptir; bu yüzden onları birinci sınıf programlar olarak ele alın:

• SPIFF’ler (belirli ürün veya davranışlar için tek seferlik ödemeler)
• Primler (kota gerçekleşimi, takım hedefleri, yönetici onayları)
• Yarışmalar (sıralama mantığı, uygunluk, eşitlik durumları)
• Hızlandırıcılar ve çarpanlar (ne zaman başlar, neye uygulanır, üst üste binme kuralları)

Ayrıca uygunluğu tanımlayın: başlangıç/bitiş tarihleri, yeni işe başlayan rampaları, bölge değişiklikleri ve izin kuralları.

Ödeme zamanlaması ve tetikleyici olayı netleştirin

Takvimi (aylık/çeyreklik) ve daha da önemlisi anlaşmaların ne zaman ödenebilir hale geldiğini kararlaştırın: fatura oluşturulduğunda, ödeme alındığında, uygulama sonrası veya geri çekme penceresinden sonra.

Uç durumları önceden tanımlayın

Çoğu ödeme hatası istisnalardan kaynaklanır. İadeler, ters işlemler, yenilemeler, iptaller, kısmi ödemeler, değişiklikler ve geriye tarihli faturalar için açık kurallar yazın—ayrıca verinin eksik veya düzeltilmiş olduğu durumlarda ne olacağı.

Kurallarınız net olduğunda, web uygulamanız bir hesap makinesinden çok tartışma çözümleyicisi olur.

Veri Modelini Tasarlayın (Temsilciler, Anlaşmalar, Oranlar ve Dönemler)

Bir komisyon uygulaması veri modeline bağlıdır. Alttaki kayıtlar “kim ne kazandı, ne zaman ve neden”i açıklayamazsa, manuel düzeltmeler ve anlaşmazlıklar ile karşılaşırsınız. Açık hesaplamaları, değişim geçmişini ve raporlamayı destekleyen bir model hedefleyin.

Dahili varlıklar

İlk olarak küçük birinci sınıf kayıt setiyle başlayın:

• Temsilciler (opsiyonel olarak takımlar/bölgeler) ödeme alanları ve organizasyon yapısını temsil eder
• Müşteriler/hesaplar geliri bir alıcıya bağlamak için
• Anlaşmalar/fırsatlar (pipeline) ve faturalar/ödemeler (gerçek gelir olayları)
• Ürünler/SKU’lar oranlar ürün hattına göre değişiyorsa
• Komisyon planları/oranlar ve dönemler (aylık/çeyreklik ödeme döngüleri)

Gereken alanlar (kaybettiğinizde pişman olacağınız)

Her anlaşma veya gelir olayı için, ödemeleri hesaplamak ve açıklamak için yeterli bilgi yakalayın:

• Değişmez bir temsilci ID’si (isimlere güvenmeyin), artı işe başlama/işten ayrılma tarihleri
• Anlaşma değeri (ve/veya fatura tutarı), para birimi ve kapanış tarihi
• Aşama/durum (ör. kazanıldı, iptal edildi, iade edildi) ve kaynak sistem ID’si
• Önemli zaman damgaları (oluşturuldu/güncellendi) ve “dönem sonu” kuralları için kullanılan zaman dilimi

İlişkiler ve paylaştırma

Komisyonlar nadiren bir anlaşmayı bir kişiye bağlar. Şunu modelleyin:

• Bir anlaşma → birçok temsilci junction tablosu (örn. deal_participants) ile pay % veya rol
• Bir temsilci → birçok anlaşma zaman içinde

Bu, SDR/AE paylaşımlarını ve yönetici geçersiz kılmalarını hack yapmadan mümkün kılar.

Geçmişi planlayın (oranlar ve bölgeler değişir)

Mevcut kuralları üzerine yazmayın. Etkili tarihli kayıtlar kullanın:

• valid_from / valid_to ile oran versiyonları
• Zaman aralıklarıyla temsilci atamaları (takım/bölge)

Böylece geçmiş dönemleri tam olarak ödendiği gibi yeniden hesaplayabilirsiniz.

ID’ler ve zaman dilimleri: bir yaklaşım seçin

Değişmez dahili ID’ler (UUID veya sayısal) kullanın ve entegrasyonlar için harici ID’leri saklayın. Depolama için UTC zaman damgaları ve dönem sınırları için açık bir “iş zaman dilimi” standardize edin; bu, gün hatalarını önler.

MVP Özellikleri ve Kullanıcı Rolleri Planlayın

Bir komisyon ve teşvik uygulaması için MVP “her şeyin daha küçük bir versiyonu” değildir. Bu, ödeme hatalarını önleyen ve her paydaşa sayılara güven verecek en küçük akıştır.

En küçük kullanılabilir uçtan uca akış

Tek, tekrarlanabilir bir yol ile başlayın:

Verileri içe aktar → komisyonları hesapla → sonuçları incele → onayla → ödeme dışa aktarımı üret.

Bu akış bir plan, bir takım ve bir ödeme dönemi için istisnalar eklemeden önce çalışmalı. Kullanıcılar veriden ödeme dosyasına kadar hesap tablolarına ihtiyaç duyuyorsa, MVP tamamlanmamıştır.

İlk günden desteklemeniz gereken kullanıcı rolleri

Rolleri basit ama gerçek tutun:

• Temsilci: salt okunur pano ve bildirim görünümü; sorun işaretleyebilir.
• Yönetici: kendi takımı için anlaşmaları/kredi girdilerini gözden geçirip onaylar; itirazlara yanıt verir.
• Finans: nihai onay, dönemi kilitleme, ödeme dışa aktarımları üretme.
• Admin: planları, eşlemeleri ve erişimi yapılandırır.

Rol tabanlı erişim, kim sonuçları değiştirebilir (yönetici/finans/admin) ile kim sadece görebilir (temsilci) ayrımına dayanmalıdır.

Hafif bir itiraz iş akışı ekleyin

İtirazlar kaçınılmazdır; bunları sistem içinde ele alın ki kararlar izlenebilir olsun:

• Anlaşma/kalem başına yorum dizisi
• Ekler (sözleşme, e-posta onayı gibi)
• Durum (Açık → İnceleniyor → Çözüldü)
• Çözüm notu ve onaylayan kişi

Yapılandırılabilir vs başlangıçta sabit (MVP için)

Yapılandırılabilir yapın:

• Ödeme dönemleri
• Temsilci başına plan ataması
• Oran tabloları
• Kreditlendirme kuralları
• Onay eşikleri

Başlangıçta sabit tutun:

• Sınırlı hesaplama türleri (ör. gelir yüzdesi, kademeli oranlar)
• Tek bir dışa aktarma formatı
• Tek bir itiraz durum iş akışı

Kapsam kontrolü: zorunlu vs iyi-olur

Zorunlu: veri içe aktarımı, hesaplama çalıştırma, denetime uygun inceleme ekranı, onaylar, dönem kilitleme, ödeme dışa aktarımı, temel itiraz yönetimi.

İyi-olur: tahminleme, ne-olursa modelleme, karmaşık SPIFF’ler, çoklu para birimi, gelişmiş analizler, Slack bildirimleri, özel bildirim şablonları.

Kapsam büyürse, yalnızca içe aktarımdan ödemeye döngüyü kısaltan veya hataları azaltan özellikleri ekleyin.

İş Uygulamasına Uygun Bir Teknoloji Yığını Seçin

Bir komisyon uygulaması öncelikle bir iş sistemidir: güvenilir veri, net izinler, tekrarlanabilir hesaplamalar ve kolay raporlama gerekir. En iyi yığın genellikle ekibinizin yıllarca güvenle bakımını yapabileceği seçenektir—en moda olan değil.

Ekip tarafından teslim edilebilecek bir yığın seçin

Çoğu komisyon uygulaması standart bir web uygulaması artı bir hesaplama servisi şeklindedir. Yaygın, denenmiş eşleştirmeler şunlardır:

• React + Node.js (Express/NestJS) JavaScript uygulamalarını uçtan uca inşa eden ekipler için
• Django (Python) hızlı yönetici araçları ve güçlü veri modellemesi istendiğinde
• Ruby on Rails hızlı CRUD geliştirme ve olgun gelenekler için
• Laravel (PHP) şirketiniz zaten PHP destekliyorsa ve hızlı teslimat isteniyorsa

Ne seçerseniz seçin, öncelik verin: güçlü kimlik doğrulama kitaplıkları, iyi ORM/veritabanı araçları ve test ekosistemi.

Eğer gereksinimlerden çalışan bir dahili araç prototipine hızla geçmek istiyorsanız, platformlar Koder.ai gibi sohbet odaklı iş akışlarıyla iş uygulamalarını prototiplemenize yardımcı olabilir—içe aktarma → hesaplama → onay → dışa aktarma akışını doğrularken hız kazandırır. Koder.ai genellikle React ön uç ile Go + PostgreSQL arka uç üreten gerçek uygulama kodu oluşturur ve sürdürür; bu, bir MVP’yi erken paydaşların eline hızlıca vermek için pratik bir yol olabilir ve sonrasında kod tabanını dışa aktarabilirsiniz.