SaaS abonelikleri için yönlendirme kredi sistemi tasarımı

Yönlendirme kredi sistemi nedir (ve ne değildir)

Yönlendirme kredi programı bir faturalama özelliğidir, ödeme özelliği değil. Ödül, gelecekteki ücretleri azaltan (veya süreyi uzatan) hesap kredisi olarak verilir. Bankaya gönderilen nakit, hediye kartı veya "daha sonra ödeme yapılacak" sözü değildir.

İyi bir sistem her seferinde tek bir soruya cevap verir: "Bu hesabın bir sonraki faturası neden düştü?" Bunu bir veya iki cümlede açıklayamıyorsanız, support talepleri ve itirazlar gelir.

Bir yönlendirme kredi sistemi üç parçadan oluşur: birisi yeni bir müşteri davet eder, net kurallar davetin ne zaman sayılacağını belirler (dönüşüm), ve krediler kazanılır ve gelecekteki abonelik faturalarına uygulanır.

Ne değildir: nakit ödeme, kayıtsız şekilde sayıları değiştiren belirsiz bir indirim veya hiç faturaya bağlanmayan puan sistemi değildir.

Birçok ekip bu detaylara güvenir. Yönlendirenler ne kazandıklarını ve ne zaman uygulanacağını görmek ister. Yönlendirilenler ne aldıklarını ve planlarını etkileyip etkilemediğini bilmek ister. Destek "kreditim neden kayboldu" sorusunu hızlı çözmelidir. Finans, faturalarla uyuşan ve denetlenebilir toplamlar ister.

Örnek: Sam, Priya'yı yönlendirir. Priya ücretli bir plana başlar. Sam, bir sonraki faturasından en fazla 20$ azaltacak şekilde 20$ kredi kazanır. Eğer Sam'in bir sonraki faturası 12$ ise kalan 8$ sonraki kullanımlar için kredide kalır ve kaynağı açık bir kayıtla belirtilir.

Başarı sadece "daha çok yönlendirme" değildir. Başarı öngörülebilir faturalama ve daha az anlaşmazlıktır. Sistem işe yarıyorsa kredi bakiyeleri kolayca açıklanır, faturalar defterle eşleşir ve destek tahmin veya manuel düzeltme yapmadan soruları yanıtlayabilir.

İnşa etmeden önce karar verilmesi gereken kurallar

Yönlendirme programı basit gibi görünür; ta ki ilk talepler gelene kadar: "Neden kredim yok?" İşin çoğu koddan çok politika ile ilgilidir.

Tetikleyici ile başlayın. "Davet gönderildi" çok erken bir noktadır. "Kaydoldu" ise sahte hesaplarla suistimal için kolaydır. Yaygın bir orta yol "nitelikli dönüşüm"dür: e-posta doğrulandı artı ilk ücretli fatura, veya deneme sonrası ilk başarılı ödeme. Bir tetik seçin ve tutarlı kalın ki defteriniz temiz kalsın.

Sonra değer ve sınırları belirleyin. Krediler gerçek hissettirmeli, ama sınırsız bir indirim makinesi olmamalı. Sabit bir miktar mı verileceğine (ör. 20$ kredi) yoksa faturanın yüzdesi mi olacağına ve bunu bir cümlede açıklayabileceğiniz şekilde sınırlandırmaya karar verin.

Daha sonra kafa karışıklığını önleyen kararlar:

• Hangi olay nitelendirir (ilk ödeme, ilk yenileme vb.)
• Ne kadar kredi verilir (sabit vs. yüzde, planlara göre değişip değişmediği)
• Limitler (her yönlendirme, aylık ve ömür boyu)
• Hangi planlar ve teklif türleri sayılır
• Kredilerin süresi dolup dolmayacağı

Uygunluk kuralları beklenenden daha önemlidir. Sadece ücretli planlar sayılıyorsa bunu belirtin. Bazı bölgeler hariçse (vergi, uyumluluk, promosyonlar), bunu söyleyin. Yıllık planlar uygunken aylık planlar değilse bunu belirtin. Koder.ai gibi bir platform için birden fazla katman varsa, ücretsizten pro'ya yükseltmelerin uygun olup olmadığı ve kurumsal sözleşmelerin manuel olarak mı ele alınacağına önceden karar verin.

Kullanıcıya yönelik metni yayınlamadan önce yazın. Her kuralı iki kısa cümleyle açıklayamıyorsanız kullanıcılar yanlış anlayacaktır. Sert ama sakin bir dil kullanın: "Şüpheli etkinlikte kredileri bekletebiliriz" uzun bir tehdit listesi yerine daha net ve daha az düşmancadır.

Davetten nitelikli dönüşüme kadar yönlendirmeleri nasıl takip edersiniz

Birincil bir tanımlayıcı seçin ve diğer her şeyi destekleyici delil olarak kabul edin. En temiz seçenekler yönlendirme bağlantı token'ı (paylaşması kolay), kısa kod (yazması kolay) ve belirli bir e-postaya gönderilen davettir (doğrudan davetler için en iyi). Birini gerçek kaynak olarak seçin ki atıf öngörülebilir olsun.

Bu tanımlayıcıyı mümkün olduğunca erken yakalayın ve yol boyunca taşıyın. Bir bağlantı token'ı genelde açılış sayfasında yakalanır, birinci taraf depolamada saklanır, sonra kayıt sırasında tekrar gönderilir. Mobil için mümkünse uygulama yükleme akışında geçirin, ama bazen kaybolacağını varsayın.

İş kurallarınıza uyan küçük bir olay seti takip edin. Hedefiniz "bu ücretli müşteri oldu mu" ise (sadece "tıkladılar" değil), minimal bir set yeterlidir:

• referral_click (token görüldü)
• account_signup (yeni kullanıcı oluşturuldu)
• account_verified (e-posta/telefon doğrulandı)
• first_paid_invoice (ilk başarılı ödeme)
• qualification_locked (dönüşüm kabul edildi ve artık değişmez)

Cihaz değişimleri ve engellenen çerezler normaldir. Bunları garip takip yöntemleriyle değil, kayıt sırasında iddia adımı ekleyerek ele alın: kullanıcı bir token ile gelmişse, yeni hesaba ekleyin; gelmemişse onboarding sırasında bir kez kısa kod girilmesine izin verin. Her ikisi de varsa, birincil olarak en erken yakalananı kullanın ve diğerini ikincil delil olarak saklayın.

Son olarak, destek ekibinin bir dakikada okuyabileceği basit bir zaman çizelgesi tutun: yönlendiren, yönlendirilen hesap (bilindiğinde), mevcut durum ve son anlamlı olay ile zaman damgaları. Birisi "neden kredi almadım?" diye sorduğunda, "kayıt oldu ama ilk ücretli fatura hiç gerçekleşmedi" gibi gerçeklerle cevap verebilirsiniz, tahminde bulunmak yerine.

Okunabilir ve hata ayıklanabilir kalan veri modeli

Yönlendirme programları genelde veri modeli belirsiz olduğunda bozulur. Destek "kimi kim yönlendirdi?" diye sorar. Faturalama "kredi zaten verildi mi?" diye sorar. Günlükleri kazmadan cevap veremiyorsanız model sıkılaşmalı.

Yönlendirme ilişkisini birinci sınıf kayıt olarak saklayın, tıklamalardan türetilmiş bir tahmin olarak değil.

Saklanacak temel kayıtlar

Basit, hata ayıklaması kolay bir düzen şöyle görünür:

• referrals: id, referrer_user_id, referred_user_id, created_at, source (invite link, coupon, manual), status, status_updated_at
• referral_attribution (opsiyonel): referral_id, invite_code_id veya campaign_id, first_seen_ip_hash, first_seen_user_agent_hash
• workspaces (eğer ekipleriniz varsa): workspace_id, owner_user_id, created_at
• workspace_members: workspace_id, user_id, role, joined_at

Referrals tablosunu küçük tutun. Sonradan pişman olacağınız şeyleri (ham IP, tam user agent, isimler) saklamaktan kaçının veya yalnızca kısa ömürlü hash'ler halinde ve net bir saklama politikasıyla saklayın.

Durumları açık ve birbirini dışlayan hâle getirin: pending (kaydoldu, henüz uygun değil), qualified (kuralları sağladı), credited (kredi verildi), rejected (kontroller başarısız), reversed (iade/chargeback sonrası kredi geri alındı).

Çifte sayımı önleyen kurallar

Önceliği bir kere belirleyin ve sonra bunu veritabanında uygulayın ki uygulama yanlışlıkla iki kez kredi veremesin. En azından:

• Her yönlendirilen hesap için yalnızca bir referrer (unique on referred_user_id)
• Her yönlendirilen hesap için yalnızca bir referral credited durumuna gelebilir
• Birden fazla temas olursa first-touch veya last-touch seçin ve seçilen referral_id'yi saklayın

Ekipleri destekliyorsanız, yönlendirmenin kişisel kayda mı yoksa workspace oluşturulmasına mı bağlanacağını belirleyin. İkisini aynı anda yapmaya çalışmayın. İşe yarayan bir yaklaşım yönlendirmeyi kullanıcı hesabına bağlamak, uygunluk kontrollerinin ise o kullanıcının (veya workspace'in) ücretli abone olup olmadığına bakmasıdır.

Kredi defteri temelleri: doğru, denetlenebilir, açıklanabilir

Daha az fatura hatası ve daha az destek bileti istiyorsanız, bir bakiye alanı yerine bir defter kullanın. Bir bakiye sayısı üzerine yazılabilir, yuvarlanabilir veya iki kez güncellenebilir. Bir defter her zaman toplamlanabilen girişlerin geçmişidir.

Giriş türlerini sınırlı ve net tutun: earn (verme), spend (faturaya uygulama), expire, reversal (geri alma) ve manual adjustment (not ve onaylayan ile).

Her giriş mühendislerin ve desteğin okuyabileceği şekilde olmalı. Tutarlı alanlar saklayın: amount, credit type (krediler nakit değilse "USD" demeyin), reason text, source event (ör. referral_signup_qualified), source ID'leri (kullanıcı, yönlendirilen kullanıcı, abonelik veya fatura), zaman damgaları ve created_by (sistem veya admin).

Idempotency beklenenden daha önemlidir. Aynı webhook veya arka plan işi iki kez çalışabilir. Kaynak olay başına benzersiz bir idempotency anahtarı gerektirin ki güvenli şekilde yeniden deneme yapabilesiniz ve çift kredi oluşmasın.

Kullanıcıya açıklanabilir yapın. Birisi "neden 20 kredi aldım?" diye sorduğunda hangi yönlendirmenin tetiklediğini, ne zaman kaydedildiğini, süresinin dolup dolmadığını ve sonra bir geri alma olup olmadığını gösterebilmelisiniz. Arkadaş bir yükseltme yaparsa, o yükseltme olayına bağlı bir earn girişi eklenir. Ödeme iade edilirse, iade olayına bağlı bir reversal girisi yayınlanır.

Öz-yönlendirmeleri ve yaygın suistimalleri cezalandırmadan önleme

Çoğu insan dürüsttur; birkaç kişi kolay hileler deneyecektir. Amaç kolay suistimalleri durdurmak, kuralları açık tutmak ve aynı Wi-Fi ağını veya aile kartını paylaşan gerçek müşterileri engellememektir.

Basit, açıklanabilir kurallarla öz-yönlendirmeyi engelleme

Referrer ile referred hesabın aynı kişi olduğu açık olduğunda kredi vermeyin: aynı user ID, aynı doğrulanmış e-posta veya aynı ödeme yöntemi parmak izi gibi. E-posta alanı kuralları yardımcı olabilir, ancak dar tutun—tüm şirket domain'lerini engellemek meşru ekipleri zarar verebilir.

Sonra döngüler ve toplu kayıtlar için hafif algılama ekleyin. Birinci günde mükemmel bir dolandırıcılık skorlamasına gerek yok. Güçlü birkaç sinyal çoğu suistimali yakalar: kısa sürede aynı cihazdan çok sayıda kayıt, dakikalar içinde aynı IP aralısından tekrar kullanımlar, aynı kartın birden çok "yeni" hesapta kullanılması, e-postaları doğrulamayan çok sayıda hesap veya krediler uygulandıktan sonra hızlı iptal ve yeniden abone olma örüntüleri.

Krediler kullanılmadan önce nitelendirici bir eylem gerektirin (örneğin: doğrulanmış e-posta artı ücretli fatura). Bu, botları ve ücretsiz katman churn'ünü ödül üretmekten alıkoyar.

Normal kullanıcıları cezalandırmadan kötü niyetlileri yavaşlatma

Yönlendirme bağlantıları ve çözümlemeler etrafında hız sınırlamaları ve bekletmeler ekleyin, ama yalnızca gerektiğinde sessizce. Bir bağlantı bir saatte aynı ağdan 20 kez kullanıldıysa ödülleri duraklatın ve işaretleyin.

Müdahale ettiğinizde deneyimi sakin tutun. Kredileri ödeme doğrulanana kadar beklemede gösterin, ödüller geciktiğinde basit bir sebep gösterin (suçlama yerine), destek için açık bir yol sunun ve uç vakaları otomatik yasak yerine manuel incelemeye yönlendirin.

Örnek: bir startup ekibi tek bir ofis IP'si paylaşır. Üç iş arkadaşı aynı gün aynı yönlendirmeyle kaydolursa, doğrulama + ücretli fatura + temel bir soğuma süresi ile faturalar ödendikten sonra yine kredi kazanırlar; bot benzeri patlamalar ise incelemeye alınır.

Gerçek hayattaki karışık durumlar: iadeler, geri almalar ve hesap değişiklikleri

Yönlendirme programları ödeme hareket etmediğinde basit hissedilir: bir iade, chargeback, void edilmiş fatura veya hesabın sahibi değiştiğinde işler karışır. Bu durumları baştan tasarlarsanız, kızgın kullanıcılar ve uzun destek konuları önlenir.

Krediler ne zaman geri alınır (ve nasıl)

Kredileri sadece bir kayıt olarak değil, ücretli bir sonuç temelinde kazanılan şeyler olarak ele alın. O zaman geri alma politikasını faturalama olaylarına bağlayın.

Destek ekibinin açıklayabileceği bir kural seti:

• Orijinal ücretli fatura tamamen iade edilir veya chargeback olursa, o faturaya ilişkin yönlendirme kredisini geri alın.
• Bir fatura ödemesi yakalanmadan iptal edildiyse, kredi verme.
• Krediler daha önce verildiyse (örneğin "fatura ödendi" esnasında), geri almalar otomatik olmalı ve açık bir iz bırakmalı.

Kısmi iadeler ekipleri zorlar. Bir yaklaşım seçin ve tutarlı kalın: orantılı geri alma (iadeye oranla kredi geri alınır) veya tam geri alma (herhangi bir iade tüm krediyi geri alır). Orantılı daha adildir ama test etmesi daha zordur; tam geri alma daha basittir ama sert gelebilir.

Denemeden ücrete geçişler de açık olmalı. Yaygın bir yöntem kredileri deneme süresi boyunca beklemede tutmak, sonra ilk başarılı ücretli fatura doğrulanınca (opsiyonel kısa bir bekleme sonrası) kilitlemektir.

Hesap birleştirmeleri ve sahiplik değişiklikleri

Kişiler e-posta değiştirir, hesap birleştirir veya kişisel kullanımdan ekip workspace'ine geçer. Neyin kişiyi takip edeceğine ve neyin ödeyen hesabı takip edeceğine karar verin. Eğer bir workspace abone ise, krediler genellikle workspace'e aittir, üyeden ayrılabilecek bir kişiye değil.

Hesap birleştirmelerini veya sahiplik transferlerini destekliyorsanız, geçmişi yeniden yazmak yerine bir ayarlama olayı kaydedin. Her geri alma veya manuel düzeltme destek dostu bir not içermeli: "Invoice 10482 üzerindeki chargeback" veya "Workspace sahipliği transferi, destek tarafından onaylandı" gibi. Koder.ai gibi kredilerin aboneliklere uygulandığı platformlarda bu notlar "kredilerim neden değişti?" sorusuna tek bakışta cevap verir.

Kredileri aboneliklere temiz uygulama

En zor kısım yönlendirmeleri takip etmek değil. Kredilerin yenilemeler, yükseltmeler, düşürmeler ve vergiler arasında aynı şekilde davranmasını sağlamaktır.

Önce kredilerin nerede kullanılabileceğine karar verin. Bazı ekipler kredileri yalnızca sonraki yeni faturaya uygular. Diğerleri kredilerin herhangi bir açık (ödenmemiş) faturayı kapatmasına izin verir. Bir kural seçin ve kullanıcı arayüzünde gösterin ki sürpriz olmasın.

Sonra işlem sırasını kilitleyin. Öngörülebilir bir yaklaşım: abonelik ücretlerini hesapla (prorasyon dahil), indirimleri uygula, vergiyi hesapla, sonra kredileri en sonda uygula. Kredileri en sona uygulamak vergi mantığını tutarlı tutar ve kredilerin her bölgede vergilendirilebilir tutarı azaltıp azaltmadığı tartışmalarını azaltır. Yasal/vergi gereksinimleriniz farklı bir sıra gerektiriyorsa, bunu belgeleyin ve testler yazın.

Prorasyon faturalama hatalarının en sık görüldüğü yerdir. Birisi dönemin ortasında yükseltme yaparsa, bir prorasyon satırı (ücret veya kredi) oluşturun ve bunu herhangi bir diğer satır gibi ele alın. Sonra yönlendirme kredilerini bireysel satırlara değil fatura toplamına uygulayın.

Fatura kurallarını sıkı tutun:

• Krediler müşterinin borcunu azaltır ama asla $0'ın altına düşürmez.
• Kullanılmamış kredi gelecekte kullanılmak üzere kalır.
• Kredileri sabit bir sırada uygula (en eskiden başlayarak) ki sonuçlar tekrarlanabilir olsun.
• Bir fatura iptal edilirse veya iade edilirse, o faturada gerçekten tüketilen kredileri geri al.

Örnek: bir kullanıcı ay ortasında yükseltme yapar ve 12$ prorasyon ücreti oluşur. İndirimler ve vergi sonrası fatura toplamı 32$ olur. Eğer kullanıcının 50$ yönlendirme kredisi varsa 32$ uygulanır, fatura 0$ olur ve 18$ sonraki yenileme için kalır.

Adım adım uygulama planı (MVP'den v1'e)

Yönlendirme programını küçük bir faturalama özelliği olarak ele alın, pazarlama aracı değil. Amaç sıkıcı tutarlılık: her kredi bir sebebe, zaman damgasına ve bir sonraki faturaya giden net bir yola sahip olmalı.

MVP (günler içinde yayınlanabilir)

Bir dönüşüm olayı ve bir kredi kuralı seçin. Örneğin: davet edilen kullanıcı sadece ücretli abone olduğunda ve ilk ödemesi onaylandığında nitelikli sayılır.

MVP'yi uçtan uca bir akış etrafında inşa edin: kayıt sırasında bir referral token veya kod yakalayın, nitelendirmeyi ödeme başarılı olduğunda çalıştırın (kullanıcı kartı girdiğinde değil), benzersiz bir idempotency anahtarı ile bir defter girişi yazın ve kredileri tahmin edilebilir sırada bir sonraki faturaya uygulayın.

Gerçeğin kaynağını erken belirleyin. Ya faturalama sağlayıcınız gerçek kaynak olur ve uygulamanız onu yansıtacak, ya da dahili defteriniz gerçek kaynak olur ve faturalama sadece "bu faturaya X krediyi uygula" bilgisini alır. İkisini karıştırmak genelde "kredilerim kayboldu" türü taleplere yol açar.

v1 (desteklenebilir hale getirin)

Daha fazla yönlendirme kuralı eklemeden önce yönetici araçları ekleyin. Destek, kullanıcı, referral kodu ve fatura ile arama yapabilmeli, sonra şu zaman çizelgesini görmeli: davet, kayıt, nitelendirme, krediler verildi, krediler harcandı ve geri almalar. Manuel ayarlamalar ekleyin ve her zaman kısa bir not zorunlu kılın.

Sonra kullanıcı deneyimini ekleyin: bir yönlendirme sayfası, her davet için bir durum satırı (pending, qualified, credited) ve faturalarla eşleşen bir kredi geçmişi.

Son olarak izleme ekleyin: yönlendirmelerde ani artışlar, yüksek geri alma oranları (iadeler veya chargeback'ler) ve aynı cihaz veya ödeme yöntemi paylaşımı gibi olağandışı örüntüler için alarmlar. Bu, suistimal kontrollerini sıkı tutarken normal kullanıcıları cezalandırmamanıza yardımcı olur.

Örnek: biri Koder.ai yönlendirmesini ekibiyle paylaşırsa, krediler yalnızca ilk başarılı ücretli abonelik sonrası görünmeli ve bu krediler bir sonraki yenilemede otomatik olarak azaltmalı, elle kupon gibi değil.

Faturalama hatalarına ve destek yüküne yol açan yaygın hatalar

Çoğu yönlendirme programı pazarlamada değil faturalamada başarısız olur. En hızlı şekilde bilet üreten şey kredilerin tahmin edilemez hissettirilmesidir: kullanıcılar neden aldıklarını, ne zaman uygulanacağını veya bir faturanın neden farklı olduğunu söyleyemez.

Yaygın tuzak kurallar netleşmeden önce inşa etmektir. Eğer "nitelikli yönlendirme" belirsizse (deneme başlatıldı, ilk ödeme, 30 gün tutulan ücretli plan), krediler vaka bazında görüşülüp iade yapılmaya başlanır ve destek yükü artar.

Başka bir sık hata tek değişken bir "kredi bakiyesi" alımıdır. Bu basit görünürken yeniden denemeler, iadeler, plan değişiklikleri veya manuel ayarlamalarla sayı sürüklenir ve nasıl oluştuğu açılamaz.

Idempotency genelde göz ardı edilir. Ödeme sağlayıcıları webhook'ları tekrar dener, işçiler işleri tekrarlar ve kullanıcılar çift tık yapar. "Kredi ver" eyleminiz idempotent değilse, çift kredi basılır ve sadece gelir tutarsızlığı ortaya çıktığında fark edilir.

Kredi matematiği de doğru olmayabilir hatta toplamlar doğru olsa bile. Kredileri vergiden önce uygulamak veya prorasyonu yok saymak, ödeme sisteminin beklediğiyle uyumsuz faturalar oluşturur. Bu, eşleşmeyen makbuzlar, başarısız ödemeler ve zor uzlaşmalar getirir.

Fraud kontrolleri çok katı da olabilir. IP, cihaz veya domain'e göre engelleme yapıp itiraz yolu tanımamak gerçek yönlendirmeleri (ev arkadaşları, iş arkadaşları, aynı ağdaki ekipler) durdurur ve büyümeyi sessizce engeller.

Dikkat edilmesi gereken beş kırmızı bayrak:

• Nitelendirme kuralları sadece kodda var ve admin/destek görünümlerinde görünmüyor.
• Krediler benzersiz bir olay anahtarına (invite_id, conversion_id) sahip değil.
• "Bakiye" bir alan üzerine yazılarak saklanıyor, defter girişleri eklenmiyor.
• Faturalar kredileri uygulamada faturalama sağlayıcınızın beklediği sıradan farklı bir sıra izliyor (vergi, prorasyon, indirimler).
• Fraud önlemlerinin itiraz yolu veya manuel geçersiz kılma mekanizması yok.

Örnek: bir Koder.ai Pro kullanıcısı ay ortasında yükseltme yapar, yönlendirme kredisi kazanır, sonra düşürür. Eğer sisteminiz tek bir bakiye alanı kullanıyor ve kredileri prorasyondan önce uyguluyorsa, sonraki fatura yanlış görünebilir; toplam yakın olsa bile uzun destek konusu olur. Bir defter ve sabit uygulama sırası bunu engeller.

Hızlı kontrol listesi, basit bir örnek ve sonraki adımlar

Yayınlamadan önce birkaç kontrol çalıştırın; bunlar çoğu fatura ve destek sorununu erken yakalar:

• Hesap başına bir yönlendiren: bir kullanıcı atandığında, sessizce değişmesine izin vermeyin.
• Net nitelendirme: krediyi kazandıran kesin olayı tanımlayın (ör. ilk başarılı ücretli fatura başarılı ve iade edilmedi).
• Defter, bakiye değil: her kredi ve borç kaydını giriş olarak saklayın.
• Geri almalar mevcut: iadeler, chargeback'ler ve iptal edilen denemeler ters girişler oluşturur.
• Yönetici ayarlamaları kaydedilir: manuel verme ve kaldırma normal defter girişi gibi notla saklanır.

Örnek: Maya, Noah'ı davet eder. Noah Maya'nın davetinden kaydolur, deneme başlatır, sonra Pro'ya yükseltir ve 30$ öder. Sisteminiz o faturayı nitelikli sayar ve Maya için 10$ abonelik kredisi girişini oluşturur.

Maya'nın sonraki yenilemesinde, fatura ara toplamı 30$ olur. Faturalama adımı kullanılabilir kredilerinden en fazla 10$ uygular; fatura 30$ ara toplam, -10$ kredi ve 20$ borç gösterir. Maya'nın defterinde kazanma için bir (+10) ve harcama için bir (-10 invoice #1234'e uygulandı) girişi olur.

Eğer Noah daha sonra ilk ödemesi için iade isterse, sistem Maya'nın kazanmış olduğu krediyi geri alan bir reversal girişi ekler (veya eşdeğer bir borç kaydı). Eğer herhangi bir kredi zaten kullanıldıysa, sonraki fatura farkı tahsil eder; geçmişi yeniden yazmaz.

Kırmızı bayrakları önlemeden hızlı ilerlemek için iki sonraki adım:

1. Atıf, nitelendirme, defter girişleri, faturaya uygulama ve geri almaları içeren tam akışı kısa bir plan dokümanında prototipleyin.

2. Sandbox'ta sabit senaryoları test edin: denemeden ücrete geçiş, kredi kullanıldıktan sonra iade, ay ortası yükseltme ve düşürme, ve bir yönetici ayarlaması.

Hızlı ilerleyip fatura mantığını kaybetmek istemiyorsanız, Koder.ai Planning Mode, snapshot ve rollback özellikleriyle yönlendirme akışını yineleyip fatura matematiği tutarlı olana dek platform içinde denemenize yardımcı olabilir. Tüm süreci koder.ai içinde yapıp hazır olduğunuzda kodu dışa aktarabilirsiniz.