Satış komisyonları ve teşvikleri izleyen; kurallar, onaylar, entegrasyonlar ve doğru ödemelerle çalışacak bir web uygulamasını planlamayı, inşa etmeyi ve yayına almayı öğrenin.
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.
Çoğu ekip baştan dört kitlenin desteğine ihtiyaç duyar:
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.
En yaygın ağrı noktaları öngörülebilirdir:
İyi bir uygulama belirsizliği azaltır ve gösterir:
İnşa etmeden önce ölçülebilir sonuçları tanımlayın. Pratik metrikler şunlar olabilir:
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.
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.
Kapsamdaki her komisyon yöntemini ve nerede uygulandığını listeleyerek başlayın:
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şvikler genellikle farklı kurallara sahiptir; bu yüzden onları birinci sınıf programlar olarak ele alın:
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ı.
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.
Ç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.
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.
İlk olarak küçük birinci sınıf kayıt setiyle başlayın:
Her anlaşma veya gelir olayı için, ödemeleri hesaplamak ve açıklamak için yeterli bilgi yakalayın:
Komisyonlar nadiren bir anlaşmayı bir kişiye bağlar. Şunu modelleyin:
deal_participants) ile pay % veya rolBu, SDR/AE paylaşımlarını ve yönetici geçersiz kılmalarını hack yapmadan mümkün kılar.
Mevcut kuralları üzerine yazmayın. Etkili tarihli kayıtlar kullanın:
valid_from / valid_to ile oran versiyonlarıBöylece geçmiş dönemleri tam olarak ödendiği gibi yeniden hesaplayabilirsiniz.
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.
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.
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.
Rolleri basit ama gerçek tutun:
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.
İtirazlar kaçınılmazdır; bunları sistem içinde ele alın ki kararlar izlenebilir olsun:
Yapılandırılabilir yapın:
Başlangıçta sabit tutun:
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.
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.
Çoğu komisyon uygulaması standart bir web uygulaması artı bir hesaplama servisi şeklindedir. Yaygın, denenmiş eşleştirmeler şunlardır:
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.
Bu, girdileri (anlaşmalar/faturalar, tarihler, kredi paylaşımları), uygulanan kuralları (oranlar, kademeler, hızlandırıcılar, üst sınırlar) ve çıktıları (kazançlar, beklemeler, geri alımlar) gösteren, ödemeler için paylaşılan bir doğruluk kaynağı olmalıdır; böylece temsilciler sayılara güvenir ve Finans hesap tabloları peşinde koşmadan dönemleri kapatabilir.
Dört kitle için inşa edin:
İş akışlarını ve izinleri her grubun ne yapması gerektiğine göre (sadece ne görmeyi istediklerine göre değil) tasarlayın.
Aşağıdaki ölçülebilir sonuçlarla başlayın:
MVP kapsamınızı hataları azaltan ve içe aktarımdan ödemeye kadar olan döngüyü kısaltan metriklere bağlayın.
Kuralları sade bir dille yazın ve örneklerle destekleyin. En azından belgeleyin:
Eğer yeni bir temsilciye açıkça açıklayamıyorsanız, bu yazılıma düzgün hesaplanmayacaktır.
Ana varlıkları ve ilişkileri içeren bir veri modeli oluşturun ki “kim ne kazandı, ne zaman ve neden” açıklanabilsin:
Bir anlaşma → birçok temsilci ilişkisini (paylaşım/roller) modelleyin ve geçmiş dönemleri tam olarak yeniden hesaplayabilmek için etkili tarihli kayıtlar kullanın.
Değişmez dahili kimlikler (UUID veya sayısal) kullanın ve entegrasyonlar için dış kimlikleri saklayın. Zaman için:
Bu, ay sonu yakınındaki bir günlük hatalarını ve denetimler ile yeniden hesaplamaları önler.
En küçük kullanılabilir uçtan uca akış şudur:
Kullanıcılar hâlâ kaynak veriden bordroya uygun bir dosya çıkarmak için hesap tablosuna ihtiyaç duyuyorsa, MVP tamamlanmış sayılmaz.
İtirazları sistem içinde yönetin ki kararlar izlenebilir olsun:
Bu, e-posta tabanlı belirsizliği azaltır ve dönem kapanışını hızlandırır.
Hesaplamaları şu şekilde sağlayın:
Veri kalitesini bir ürün özelliği olarak ele alın:
Veriler karışıksa ödeme anlaşmazlıkları çıkacaktır—görünürlük ve düzeltme yolları eşitleme kadar önemlidir.
Bu, bildirimleri “bana güven” yerine “izlenebilir” hale getirir.