Kullanım Bazlı SaaS Faturalama: Önce Ölçüm Sözleşmesini Kurun

Ücretlendirilen birimi açıkça tanımlayın

API isteği mi, başarılı işlem mi, işlenen belge mi, yoksa tamamlanan rapor mu ücretlendirilecek? Aynı kullanıcı işlemi arka planda birkaç çağrı oluşturabilir. Teknik çağrı sayısını doğrudan müşteri kullanımına eşitlemek beklenmedik ücretler doğurabilir. Ölçüm sözleşmesi bu ayrımı yazılı hale getirir.

Başarısız işlem, kullanıcı iptali, sistemin yeniden denemesi ve test hesabı davranışını ayrı belirleyin. Müşterinin kendi hatasıyla sistem hatasının nasıl ele alınacağı da açıklanmalıdır. Gizli ölçüm kuralları yerine örneklerle anlatılabilen bir model kurun.

Olay kaydı ile toplam sayacı ayırın

Toplam kullanım sayısını tutmak hızlıdır ama itiraz geldiğinde neden o rakama ulaşıldığını açıklamayabilir. İşlem kimliği, müşteri bağlamı, birim, miktar, olay zamanı ve kaynak gibi gerekli verileri içeren bir ölçüm kaydı tasarlanabilir. Gereksiz kişisel veri kaydetmeyin.

Stripe kullanım kaydı dokümantasyonu olay alımı ile toplulaştırılmış kullanımın görünmesi arasında gecikme olabileceğini açıklar. [1] Sağlayıcının güncel yöntemi ve önerilen entegrasyon yolu uygulama öncesinde kontrol edilmelidir. Buradaki desen sağlayıcı tavsiyesi veya Türkiye’de kullanılabilirlik iddiası değildir.

Örnek: rapor işi üç kez deneniyor

Varsayımsal müşteri bir rapor oluşturuyor; ilk iki deneme altyapı hatası nedeniyle tamamlanmıyor, üçüncüsü başarılı oluyor. Ticari kural tamamlanan rapor başına ücretse müşteri bir kullanım görmelidir. Her teknik denemeyi bağımsız kullanım olarak saymak sözleşmeyle çelişir.

Örnek fiyat içermez; ücretlendirme politikasını açıklamak için kullanılır. Farklı bir ürün başarısız işlem için de ücret alabilir, ancak bu kural açık ve ölçülebilir olmalıdır.

Dönem sınırında geç gelen kayıtları planlayın

İşlem ayın son anında başlayıp sonraki ay tamamlanabilir. Hangi zamanın esas alındığını belirleyin: başlama, tamamlama veya sağlayıcıya ulaşma zamanı. Saat dilimi ve dönem kapanış politikası yazılı olsun. Geç gelen olayın geçmiş döneme mi, sonraki düzeltmeye mi gideceği belirsiz kalmamalıdır.

Kapanmış dönemin toplamını sessizce değiştirmeyin. Düzeltme gerektiğinde orijinal olay, neden ve uygulanan işlem ilişkilendirilsin. Müşteri paneli ile iç rapor aynı politika üzerinden hesap yapmalıdır; birinde anlık, diğerinde kesinleşmiş veri varsa ayrım görünür olsun.

Yuvarlama ve kademeleri örnekleyin

Kullanım miktarı kesirliyse hangi hassasiyetle tutulduğunu belirleyin. PostgreSQL sayısal türler rehberi kesin ve yaklaşık hesap davranışlarını ayırır. [2] Para ve kullanım hesabında veri türü seçimi, test edilmiş yuvarlama kuralıyla birlikte ele alınmalıdır.

Kademeli fiyat varsa eşik altı, eşit ve eşik üstü örnekleri hazırlayın. Kademenin bütün kullanıma mı yoksa sadece aralık içindeki miktara mı uygulandığını açıklayın. Bu rehber fiyatlandırma veya vergi danışmanlığı değildir; teknik hesap sözleşmesinin belirsizliğini azaltmayı amaçlar.

Müşteri kendi kullanımını araştırabilsin

Panelde toplamın yanında dönem, birim ve güncellik bilgisi gösterin. Müşteri ilgili iş referanslarını görebiliyorsa beklenmedik artışı daha kolay araştırır. İç sistemin hassas günlüklerini açmak yerine gerekli ticari bağlamı sunun.

Teslimde yinelenen olay, eksik olay, geç olay, iptal ve düzeltme senaryolarını çalıştırın. Kaynak kullanım kayıtlarıyla ücretlendirme toplamını karşılaştıran mutabakat raporu bulunsun. Tek sayaç değeri, güvenilir faturalama sisteminin tamamlandığını kanıtlamaz.

Sık sorulan sorular

### Her API isteğini ücretlendirmek yanlış mı? Ürünün açık ticari modeli buysa uygulanabilir. Ancak sistem içi tekrarlar, başarısız istekler ve test kullanımı gibi durumların nasıl sayıldığı müşteri tarafından anlaşılmalıdır.

Gerçek zamanlı gösterge kesin fatura tutarı mıdır?

Her zaman değil. Toplulaştırma, geç gelen veri ve dönem kapanışı nedeniyle farklılaşabilir. Tahmini ve kesinleşmiş rakamlar açıkça ayrılmalıdır.