Abonelikler vs kullanıma-göre faturalama: baştan ne saklamalısınız

Neden fiyat modellerinin bir veri planı olmalı

Fiyatlandırma sadece web sayfanızdaki bir sayfa değildir. Hangi verileri kaydetmeniz gerektiğini, nasıl raporlayacağınızı ve aylar sonra bir ücreti nasıl açıklayacağınızı belirler. Abonelikler ile kullanıma-göre faturalama arasında seçim yaptığınızda, fatura verilerinizin şeklini de seçmiş olursunuz.

Basit bir abonelik genellikle birkaç bilgiyle hesaplanabilir: plan, faturalama dönemi, başlangıç tarihi ve indirimler. Kullanıma dayalı fiyatlandırma daha fazlasını gerektirir: ne kullanıldı, ne zaman oldu, hangi müşteriye ait ve bu kullanım paraya nasıl dönüşüyor. Bu kayıtlar yoksa faturalar gönderebilirsiniz, ama savunamazsınız.

Sonradan kullanım eklemek çoğunlukla üç yerde bozar:

• Güvenilir kullanım geçmişiniz yoktur, bu yüzden müşteriler ücretleri itiraz eder.
• Analitikler tahmin yürütür hale gelir çünkü ekipler "kullanım"ı farklı tanımlar.
• Finans faturaları denetleyemez çünkü ham girdiler ya eksik ya da üzerine yazılmıştır.

Amaç sıkıcı ama hayati: her seferinde aynı faturayı aynı şekilde hesaplamak. Bu, saklanan gerçeklerden (plan koşulları, ölçüm kuralları, kullanım olayları ve uygulanan tam fiyat versiyonu) hesaplamayı yeniden oynatabileceğiniz anlamına gelir.

"Modelleme görünümü" demek, mühendis olmasanız bile faturalamayı birbirine uyan yapı taşları olarak tanımlamaktır. Bir ekip sohbet ürünü hayal edin:

• Abonelik: her çalışma alanı için aylık 99$
• Kullanım: 50.000 mesajdan sonra mesaj başına 0.01$

Bunu sonradan desteklemek için verileriniz şu soruları yanıtlamalı: hangi çalışma alanı, hangi ay, kaç mesaj, neler dahil ve hangi fiyat kuralları aktifti.

Abonelikler vs kullanım: uygulamada nasıl farklılaşırlar

Abonelikler erişim için ücret alır. Kullanıma dayalı faturalama tüketim için ücret alır. Yükseltmeler, düşürmeler, prorasyon ve gerçek dünya kenar durumları ortaya çıktığında çok farklı davranırlar.

Abonelikte ana soru şudur: "Müşteri bu süre zarfında ürünü kullanmaya hak kazanmış mı?" Genellikle plan, koltuk sayısı, faturalama dönemi ve faturanın ödenip ödenmediği izlenir. Kullanım yine önemlidir, fakat genellikle madde olarak değil limitler (yumuşak veya sert) şeklinde görünür.

Kullanıma dayalı faturalamada ana soru şuna dönüşür: "Tam olarak ne oldu ve ne zaman?" Güvenilir ölçüm, kullanımın hangi durumlarda sayılacağına dair açık kurallar ve her ücreti daha sonra açıklayabilme yolu gerekir. Arayüzünüz tek bir sayı gösterse bile (örneğin "1,243 API çağrısı"), arkasında tutarlı ve denetlenebilir bir olay seti vardır.

Birçok B2B SaaS ekibi hibrit fiyatlandırmada karar kılar: bir temel ücret, bir paket kapsama alanı ve fazlalık ücretleri.

Yaygın hibrit desenler

Çoğu hibrit model birkaç tanıdık şekle girer:

• Temel platform ücreti artı kullanıcı başına ücret
• Dahil edilen birimler (mesajlar, görevler, API çağrıları) ve fazlalık oranı ile temel ücret
• Birden çok seviye plan ve yalnızca etkinleştirildiğinde ücretlendirilen kullanım eklentisi
• Minimum taahhüt ve kullanım kredisi çekimi

Tahmin edilebilirlik, müşterilerin bütçe onayı ve sabit aylık harcama ihtiyaçları olduğunda yardımcı olur. Kullan-öde, değer etkinlikle ölçekleniyorsa (örneğin "işlem başına fatura"), veya müşteriler deneme amaçlı düşük risk istiyorsa daha uygundur.

Plan değişiklikleri kaçınılmazdır. Fiyatlar, paketler ve paketleme değişecektir. Yeni bir metre ekleyebilmeniz, yeni bir seviye tanıtabilmeniz veya "dahil" olanı değiştirebilmeniz için faturalamayı tarih yeniden yazmadan tasarlayın. Pratik bir kural: müşterinin planını ve fiyat koşullarını, sadece bugün ne olduklarını değil, ücretlendirme zamanında oldukları şekilde saklayın.

Güvenilir ölçümler (meter) tanımlayın

Bir metre, ücretlendirdiğiniz şeyin tam olarak yazılı tanımıdır; iki kişinin saydığında aynı sonuca ulaşacağı kadar açık olmalıdır. Üç kısmı vardır: olay (ne oldu), birim (ne sayıyorsunuz) ve zamanlama (ne zaman sayılıyor).

Çoğu tartışma buradan başlar. Bir taraf sonucun için ödüyor olduğunu düşünürken, diğer taraf ölçülebilir aktivite için ücret alıyor olabilir.

Metreyi (ölçümü) netleştirin

Gerçek ürün eylemlerine haritalanan ve otomatik olarak kaydedilebilen metrikler seçin. Yaygın örnekler:

• Koltuklar (giriş yapabilen aktif kullanıcılar)
• API çağrıları (başarılı istekler veya tüm istekler)
• Depolama (bir noktadaki GB veya dönem ortalaması)
• Mesajlar (gönderilen, teslim edilen veya açılan)
• Hesaplama dakikaları (bir işin çalıştığı süre)

Sonra neyin sayıldığını ve neyin sayılmadığını tanımlayın. API çağrısı başına faturalandırıyorsanız, tekrar denemelerin sayılıp sayılmayacağını, 4xx ve 5xx yanıtların sayılıp sayılmayacağını ve kendi entegrasyonlarınızın yaptığı dahili çağrıların dahil olup olmadığını belirleyin.

Zamanlama, birim kadar önemlidir. Koltuklar genelde faturalama dönemi başına bir anlık görüntü olarak çalışır. API çağrıları genelde bir pencere içinde toplanır. Depolama zordur: müşteriler genelde "ne kadar depoladığınız" için ödeme bekler, bu genelde zirve değil dönemsel ortalama anlamına gelir.

Ayrıca kapsamı belirleyin: hesap başına mı yoksa çalışma alanı/proje başına mı. Basit bir kural: ekipler ayrı ayrı fatura edilebiliyorsa, metrikler çalışma alanı başına olmalıdır.

Limitler, seviyeler ve yetkilendirmeler (entitlements)

Yetkilendirmeler, müşterinin satın aldığı şeye göre ne yapmasına izin verildiğini belirleyen kurallardır. Kaç kullanıcı ekleyebilecekleri, hangi özelliklerin etkin olduğu, ayda hangi hacmin izinli olduğu gibi soruları cevaplar. Yetkilendirmeler erişim ile faturalama arasında durur: ürünün ne izin verdiğini şekillendirir, ölçüm ise gerçekte ne olduğunu kaydeder.

Yetkilendirmeleri ölçüm mantığından ayrı tutun. Yetkilendirmeler okunabilir ve sabit olmalı (plan, eklentiler, sözleşme koşulları). Ölçüm ürün geliştikçe (yeni olaylar, yeni metrikler) evrilecektir ve her metriğin değişiminin erişimi bozmasını istemezsiniz.

Sert limitler, yumuşak limitler ve fazlalık faturalaması UI'da benzer görünse de farklı davranırlar:

• Sert limit, kapağı aştıktan sonra işlemi engeller.
• Yumuşak limit, işlemi izin verir ama uyarır ve izleme için işaretler.
• Fazlalık faturalaması, işlemi izin verir ve ekstra kullanım için ücret alır.
• Bir süre tanıma (grace period) sert limiti geçici olarak yumuşak gibi davranmaya zorlayabilir.
• Denemeler ve ücretsiz seviyeler yetkilendirme uygular, ancak fiyatlandırma genelde bir tarih veya eşik olana kadar farklıdır (çoğunlukla sıfır).

Bir limit aşıldığında ne olacağını önceden kararlaştırın. Örnek: "Starter" seviyesindeki bir ekip 5 koltuk ve ayda 10.000 API çağrısı içeriyor. 6. kullanıcı davet edilirse, engeller misiniz, ekstra koltuk başına ücret mi almaya başlarsınız yoksa 7 gün boyunca izin verir misiniz? Her seçim, faturada ve destek kayıtlarında gösterilebilecek bir kural gerektirir.

Yetkilendirmeleri zaman bağlı kayıtlar olarak saklayın: müşteri, plan veya eklenti, başlangıç ve bitiş zaman damgaları, limit değerleri ve uygulama modu (sert, yumuşak, fazlalık). Bu, erişim kararları ile faturalama kararlarının tutarlı kalmasını sağlar.

Denetlenebilir faturalar ve faturalama dönemleri

Fatura sadece bir PDF değildir. Kim faturalandı, ne için, hangi tarihler arasında, hangi kurallara göre sorularını yanıtlayan bir denet izidir. Fiyatları değiştirirseniz, eski faturaları aynı şekilde yeniden oluşturabilmelisiniz.

Başlangıç olarak birkaç temel kayıtla başlayın: Müşteri, Abonelik (veya Sözleşme), Faturalama Dönemi ve Fatura ile Satır Öğeleri. Her satır öğesi kaynağına işaret etmelidir: bir plan ücreti, kullanım özeti veya tek seferlik bir ücret. Bu bağlantı, bir ücret itiraz edildiğinde faturalamayı açıklayan şeydir.

Faturalama dönemlerinin bir ankırı ve bir zaman dilimi olmalıdır. "Aylık" yeterli değildir. Döngü başlama tarihini (örneğin 15'i 00:00) ve dönemlerin kesildiği zaman dilimini saklayın. Bunu tutarlı tutmazsanız yaz saati uygulamaları etrafında bir günlük hatalar yaşarsınız.

Denetlenebilir faturalar genelde şunları gerektirir:

• Her fatura ve satır öğesinde period_start ve period_end
• O fatura için kullanılan fiyat versiyonu (plan/fiyat kimlikleri)
• Değiştirilemez toplamlar: ara toplam, vergi, indirimler, ödenecek_tutar, para birimi
• Herhangi bir kullanım bazlı satır öğesi için tam kullanım penceresi
• Uygunsa harici ödeme referansları (işlemci ücret kimliği)

Gelir tanıma (revenue recognition) ilgili ama aynı şey değildir. Peşin ödenmiş abonelik ücreti genellikle hizmet dönemi boyunca tanınırken, kullanım genelde sağlandığında tanınır. Bunu yüksek seviyede tutsanız bile, daha sonra destekleyecek yeterli tarihleri saklayın.

Kredi notları, iadeler ve ayarlamaları birinci sınıf kayıtlar olarak ele alın; eski faturaların üzerine düzenleme yapmayın. Müşteri bir dönemin ortasında yükseltme yaparsa, orijinal faturaya referans veren ve kullanılan prorasyon kuralını belirten bir düzeltme satırı veya kredi notu oluşturun.

Fatura oluşturma ve ödeme denemeleri için idempotency anahtarları önemlidir. Bir iş iki kez çalışırsa, tek bir fatura, tek bir tahsilat ve net bir günlük istersiniz.

Prorasyon ve dönemin ortasındaki değişiklikler

Dönemin ortasındaki değişiklikler faturalama tartışmalarının başladığı yerdir. Birisi 20'sinde yükseltme yaparsa, bir hafta duraklatır sonra iptal ederse, bu eylemleri faturalarda anlamlı sayılara dönüştürecek kurallara ihtiyacınız vardır.

Hangi değişikliklere izin verdiğinizi ve ne zaman yürürlüğe gireceğini kararlaştırın. Pek çok ekip yükseltmeleri hemen uygular, böylece müşteriler değeri hemen alır; ancak düşürmeleri yenilemeye kadar erteleyebilirler ki karmaşık iade işlemlerinden kaçınılsın.

Açıklanabilir bir prorasyon politikası seçin

Prorasyon günlük, saatlik veya hiç olmayabilir. Ne kadar hassas olursanız, o kadar çok zaman damgası, yuvarlama kuralı ve kenar durumu saklamanız ve test etmeniz gerekir.

Politika seçimlerini erken kilitleyin:

• Yükseltmeleri hemen prorasyona tabi tutun, düşürmeleri yenilemeye erteleyin
• Günlük prorasyon kullanın (saatlikten daha basit, genelde yeterince adil)
• Yuvarlama kurallarını tanımlayın (örneğin en yakın sent'e yuvarla)
• Duraklatmalar nasıl çalışır karar verin (zamanı kredi olarak geri ver veya dönemi uzat)
• İptaller için net bir iade politikası belirleyin (tam, kısmi veya yok)

Prorasyonu fatura satır öğeleri olarak modelleyin

Gizli matematikten kaçının. Prorasyonu faturada açık ayarlamalar olarak gösterin: yeni plan için kalan süreye ait borç ve eski plan için kullanılmamış süreye ait alacak gibi. Her satır öğesi, onu tetikleyen değişiklik olayına (change_id) işaret etmeli ve prorasyon penceresini (start_at, end_at), miktar/zaman temelini ve vergi kategorisini içermelidir.

Kullanım metrikleri bir karar daha ekler: plan değiştiğinde metrikler sıfırlanır mı, biriktirilmeye devam eder mi yoksa segmentlere mi bölünür? Basit ve denetlenebilir bir yaklaşım, kullanımı plan versiyonu bazında segmentlemektir. Örnek: bir müşteri ay ortasında 10 koltuktan 25 koltuğa yükselir. Kullanım olaylarını olduğu gibi bırakırsınız, ancak puanlama onları o an aktif olan yetki dönemiyle gruplandırır.

Geri çevrilebilir olanı karar verin. Kullanım olaylarını kabul edildikten sonra final olarak ele almak genellikle yardımcı olur; abonelik değişiklikleri ise fatura kesinleştirilene kadar sadece geri alınabilir olabilir. Değişiklik olaylarını ve fatura düzeltmelerini saklayın ki kurallar evrildiğinde faturaları temizce yeniden oluşturabilesiniz.

Başlangıçtan itibaren saklamanız gereken veriler

Müşteriler şikayet edene kadar faturalama verisini tasarlamak için beklerseniz tahminde bulunmak zorunda kalırsınız. Abonelik, kullanım veya hibrit B2B SaaS fiyatlandırma modeli seçseniz de, en güvenli başlangıç küçük ama denetlenebilir bir kayıt setidir.

Açık bir müşteri hiyerarjisi ile başlayın. B2B SaaS'te ödeyen genellikle şirket hesabıdır, ancak kullanım genelde çalışma alanları veya projeler içinde olur ve eylemler bireysel kullanıcılardan gelir. Üç seviyeyi (hesap, çalışma alanı, kullanıcı) saklayın ve kim ne yaptı kaydedin. Fatura anlaşmazlıkları sıklıkla "bu hangi ekip tarafından yapıldı?" olarak döner.

Gerçek faturaları ve temiz soruşturmaları destekleyecek minimum faturalama veritabanı tasarımı:

• Hesaplar ve organizasyon yapısı: hesap, çalışma alanı (veya proje), kullanıcılar, roller, fatura irtibat kişisi ve gerekirse vergi alanları
• Abonelikler: plan, durum, başlangıç/bitiş tarihleri, yenileme ayarları, iptal nedeni ve başlangıçta uygulanan fiyat versiyonu
• Fiyat kataloğu: ürünler, plan bileşenleri (temel ücret, koltuklar, metrikler), seviyeler, para birimi ve yürürlük tarihleri
• Kullanım ölçüm verisi: zaman damgası, çalışma alanı, kullanıcı (varsa), metre adı, miktar ve benzersiz idempotency anahtarı ile değiştirilemez yalnızca eklenen olay günlüğü
• Fatura nesneleri: faturalama dönemi sınırları, satır öğeleri, toplamlar, vergi/indirim ayarlamaları ve kullanılan girdilerin anlık görüntüsü

Sadece toplanmış sayaçlara güvenmeyin. Hız için sayaçlar tutun, ancak olay günlüğünü tek kaynak (source of truth) olarak kabul edin. Basit bir kural: olaylar değiştirilemez olmalıdır, düzeltmeler yeni olaylar olsun (örneğin negatif miktar) ve her olay belirli bir metre tanımına bağlansın.

Örnek: bir müşteri geçen ay "API çağrılarımız iki katına çıktı" derse, günlük veya çalışma alanı bazında ham olayları çekebiliyorsanız zirvenin nereden geldiğini gösterebilir veya bir entegrasyon döngüsünü tespit edebilirsiniz.

Adım adım: kullanım olaylarından faturaya

Zor olan matematik değil. Zor olan sonucu aylar sonra bile açıklanabilir yapmak, planlar, fiyatlar ve müşteriler değişse bile.

1) Zaman yolculuğu yapabilen bir fiyat kataloğu ile başlayın

Ürünleri, planları, metrikleri ve fiyatları yürürlük tarihleriyle ayarlayın. Eski fiyatı asla üzerine yazmayın. Bir müşteri Mart ayında faturalandırıldıysa, Mart için Mart kataloğunu yeniden çalıştırabilmelisiniz.

Örnek: "API Çağrıları" 1 Nisan'dan itibaren her biri 0.002$ olsun. Mart faturaları eski oranı kullanmalıdır.

2) Müşterinin o dönem için neye hak kazandığını anlık görüntüleyin

Her faturalama dönemi başında (veya bir değişiklik olduğunda) bir yetki anlık görüntüsü saklayın: plan, dahil edilen birimler, limitler, seviye kuralları, indirimler ve vergi ayarları. Bunu o dönem için "ne taahhüt ettik" olarak düşünün.

3) Kullanım olaylarını alın ve erken doğrulayın

Kullanım, zaman damgası, müşteri, metre, miktar ve çoğaltmayı önlemek için benzersiz bir id ile değiştirilemez olaylar olarak gelmelidir. Kapıda temel doğrulamayı yapın (eksik metre, negatif miktar, imkansız zaman damgaları) ve ham olayı kaydedin, temizlenmiş bir versiyon da saklasanız bile.

Sonra hesaplamayı iki aşamada yapın:

• Olayları müşteri, metre ve faturalama dönemi bazında toplamlar halinde birleştirin (ve birleştirme versiyonunu saklayın)
• Toplamları kataloğu ve yetki anlık görüntüsünü (dahil edilen birimler, fazlalık fiyatı, seviyeler) kullanarak ücrete çevirin

Fatura satır öğeleri, kullanılan tam girdilere (katalog versiyonu, anlık görüntü id'si, birleştirme id'si) referans vermelidir.

Son olarak faturayı kilitleyin. Hesaplama girdilerini ve çıktısını saklayın, son olarak işaretleyin ve geciken olaylar geldiğinde değişmesini engelleyin. Geç gelen olaylar bir sonraki faturaya (veya ayrı bir düzeltmeye) girmeli ve net bir denet notu olmalıdır.

Müşteri ve iç raporlama ihtiyaçları

Müşteriler abonelik mi yoksa kullanıma-göre faturalama mı olduğuyla ilgilenmez. Önemli olan sayıların kendi kayıtlarıyla eşleşmesi ve bir sonraki ücreti tahmin edebilmeleridir.

Müşteri tarafı raporlama, destek talebi oluşturmadan birkaç soruyu cevaplayan basit bir faturalama ana sayfası şeklinde en iyi çalışır:

• Hangi plandayım ve neleri kapsıyor?
• Bu dönem ne kadar kullandım ve kullanım nasıl sayılıyor?
• Limitlerim neler ve aşarsam ne olur?
• Faturalama dönemi ne zaman bitiyor ve tahmini bir sonraki faturam nedir?
• Geçmiş faturalar ve ödemeler nerede görülebilir?

İçeride, destek ve finans bir sayıyı açıklayabilmeli, sadece gösterememelidir. Bu, yükselişleri tespit etmek, değişiklikleri izlemek ve önizleme hesaplamalarıyla kesin faturaları ayırmak anlamına gelir.

Fatura önizlemelerini faturadan ayrı tutun. Önizlemeler geciken kullanım geldiğinde veya bir metre tanımını değiştirdiğinizde yeniden hesaplanabilir. Faturalar ise yeniden hesaplanmamalıdır.

İç raporlamanız anomalileri (ani kullanım sıçramaları, negatif kullanım, yinelenen olaylar) işaretlemeyi, bir fatura satır öğesini ham kullanım ve kurallardan yeniden üretmeyi ve dönem için plan değişikliklerini ve prorasyon kurallarını görmeyi kolaylaştırmalıdır.

Denet izleri çoğu ekip için beklenenden daha önemli olur. Bir müşteri "12'sinde yükselttik" derse, zaman damgaları, eylemi yapan (kullanıcı, yönetici, otomasyon) ve plan/koltuk/limit/fiyat öncesi/sonrası değerlerini gösteren doğruları sunmanız gerekir.

Saklama için, ham kullanım olaylarını ve kesinleştirilmiş fatura nesnelerini uzun vadede saklayın. Pratik bir kural: eğer bir kayıt faturalanan miktarı değiştirebilir veya bir anlaşmazlıkta savunmaya yardımcı olabiliyorsa, değiştirilemez şekilde saklayın.

Fatura anlaşmazlıklarına neden olan yaygın tuzaklar

Çoğu fatura anlaşmazlığı fiyat hakkında değildir. Bir sayıyı faturada açıklayamamak veya aynı girdilerin daha sonra farklı bir toplam üretmesi yüzünden olur.

Yaygın hata sadece aylık toplamları saklamaktır. Ham olaylar yoksa basit sorulara cevap veremezsiniz: "Hangi gün bizi limite itti?" Olayı saklayın, sonra toplulaştırın.

Bir diğer sık sorun, bir metriğin anlamını izlemeyi bırakmaktır. "Aktif kullanıcı" başlangıçta "en az bir kez giriş yaptı" iken sonra "kayıt oluşturdu" olabilir. Metre tanımlarını versiyonlamazsanız, müşteriler eski faturaları yeni faturalarla karşılaştırır ve hangi kuralın uygulandığını kanıtlayamazsınız.

Anlaşmazlıklar genelde şu kalıplardan çıkar:

• Yetkilendirmeler sadece UI'da uygulanıyor (arka uç hala ekstra kullanımına izin veriyor veya geçerli kullanımı engelliyor)
• Her şey için tek bir zaman damgası alanı kullanılıyor (olay zamanı, alım zamanı, faturalama zamanı aynı alan)
• Zaman dilimleri gözardı ediliyor (00:30 yerel zaman kullanımı yanlış gün/a y düştü)
• Faturalama ankırı unutuluyor (bazı müşteriler 1'de fatura oluyor, bazıları kayıt gününde)
• Plan, fiyat ve limit değişikliklerinin denet izi yok

Örnek: Tokyo'daki bir müşteri yerel saatte 31'inde yükseltme yapar. Sadece UTC zaman damgası ve faturalama ankırı saklanmamışsa, yükseltme sisteminizde 30'una düşebilir ve prorasyon ile kullanım yanlış döneme kayabilir.

Güveni en hızlı kaybetme yolu eski bir fatura hesaplamasını yeniden üretememektir. Girdileri (olaylar, versiyonlar, ankırlar ve uygulanan fiyatlar) saklayın ki aynı mantığı daha sonra yeniden çalıştırıp aynı sonucu alabilesiniz, ürününüz değişse bile.

Faturalamayı yayına almadan önce hızlı kontroller

Yayınlamadan önce bir tatbikat yapın: rastgele bir müşteriyi seçin ve son faturalarını sadece saklanan verilerle yeniden oluşturun. Eğer "o zaman kodun ne yaptığını" bulmanız gerekiyorsa, denet iziniz yok demektir.

Her metrenin net olduğundan emin olun. Bir metre bir cümlede açıklanabilecek bir birime (istekler, koltuklar, GB, dakika), güvenilir kaynağa (hangi servis yayıyor) ve zaman penceresine (gün başına, faturalama dönemi başına, takvim ayı başına) ihtiyaç duyar. Bir metreyi bir cümlede açıklayamıyorsanız, müşteriler de güvenmeyecektir.

Çoğu faturalama sorununu yakalayan hızlı kontroller:

• Bir faturayı girdilerden yeniden oynatabiliyorsunuz: plan versiyonu, fiyatlar, kullanım toplamları, vergiler, indirimler ve prorasyon parametreleri
• Kullanım olayları yalnızca eklenen, değiştirilemez ve çoğaltma önlenmiş (idempotency anahtarı veya olay id'si) şekilde saklanıyor
• Plan ve fiyat değişiklikleri yürürlük tarihleriyle versiyonlanmış (eski fiyatlar üzerine yazılmıyor)
• Prorasyon kuralları açıkça yazılmış ve testlerle kapsanmış
• Destek ekibi "neden ücretlendirildim" sorusunu kaydedilmiş aynı gerçekleri kullanarak hızlıca cevaplayabiliyor

Örnek: bir müşteri 18'inde 10 koltuktan 25'e yükseliyor ve 23'ünde bir kullanım eşiğini aşıyor. Sistemin şu bilgileri göstermesi gerekir: (1) hangi plan versiyonunun hangi tarihte aktif olduğu, (2) zaman damgalı koltuk-değişikliği olayı, (3) kullanılan prorasyon formülü ve (4) final toplama dahil olan kullanım olayları.

Sonraki adımlar: kendinizi çıkmaza sokmadan uygulama

Küçük başlayın, ama belirsiz başlamayın. En güvenli yol, aylar sonra bile şu soruyu yanıtlamanızı sağlayacak en küçük veri modelidir: "Neden bu tutarı tahsil ettik?"

Faturalama şemasını ve yönetici ekranlarını satış öncesi prototipleyin, ilk fiyat değişikliğinizden önce. Satış yeni bir seviye veya dönemin ortasında bir yükseltme istediğinde beklerseniz, mantığı çok fazla yerde yamalamak zorunda kalırsınız.

Pratik bir ayrım: Stripe ödemeleri, makbuzlar ve ödeme yeniden denemelerini ele alsın; fakat rating (kullanımın nasıl satır öğelerine dönüşeceği) kendi sisteminizde kalsın. Bu, ham kullanım olaylarını, fiyat versiyonlarını ve fatura önizlemeleri için kullandığınız hesaplama sonuçlarını sizin sakladığınız anlamına gelir.

Esnek kalan ama hızlı başlatan basit bir yol haritası:

• Güvenilir ölçebileceğiniz 1-2 metre seçin (örneğin günlük aktif koltuklar ve API çağrıları)
• Fiyat kurallarını baştan versiyonlayın ki eski faturalar eski kurallarla eşleşsin
• Kullanım, geçersiz kılmalar, krediler ve anlaşmazlıkları görecek bir iç faturalama yönetici paneli oluşturun
• Basit bir müşteri portal görünümü ekleyin: mevcut plan, dönem içi kullanım, beklenen fatura
• Her faturayı yeniden hesaplanan bir tahmin değil denetlenebilir bir anlık görüntü olarak ele alın

Çok fazla özel arka ofis kodu yazmadan hızlı hareket etmek isterseniz, bu varlıkları AppMaster'da modelleyebilir ve yönetici ile portal ekranlarını görsel araçlarla inşa edebilirsiniz; PostgreSQL ise olaylar ve faturalar için kayıt sistemi olmaya devam edebilir.

Somut örnek: bir koltuk metriği ile başlarsınız. Üç ay sonra depolama GB'si eklersiniz. Metrikler, yetkiler ve fiyat kuralları versiyonlanmışsa, yeni metrik eski faturaları bozmadan eklenebilir ve destek ekibi herhangi bir satır öğesini birkaç dakikada açıklayabilir.