SaaS ve Güvenlik / Uygulama ve satın alma rehberi

SaaS Abonelik Yönetimi: Paket ile Özellik Yetkisini Ayırın

Bir müşterinin abonelik paketini bilmek, yazılımda hangi işlemleri yapabileceğini tek başına açıklamaz. Paket, ödeme durumu, özellik yetkisi ve kullanım kotası ayrı kavramlar olarak modellenmelidir.

Paket adını kodun her yerine yaymayın

Uygulamanın farklı noktalarında “paket Profesyonel ise izin ver” kontrolleri birikirse yeni paket eklemek riskli hale gelir. Özellikleri ayrı tanımlayıp paketleri bu özelliklerle eşleştiren bir model değerlendirilebilir. Böylece rapor indirme, ekip üyesi ekleme ve entegrasyon kullanma gibi haklar açıkça yönetilir.

Stripe entitlements dokümantasyonu da ürün özelliklerine erişimin verilmesi ve geri alınmasını ayrı bir konu olarak ele alır. [1] Burada sağlayıcı bir teknik örnektir; ülke uygunluğu veya ödeme sağlayıcısı seçimi önerilmemektedir. Kullanılacak ürünün güncel ticari ve teknik koşulları ayrıca incelenmelidir.

Ödeme durumu ile erişim kararını eşitlemeyin

Başarısız ödeme, deneme süresi, iptal talebi ve dönem sonu farklı durumlar olabilir. İlk başarısız tahsilatta bütün müşteri verisini kapatmak işletmenizin politikası olmayabilir. Buna karşılık ödeme bekleyen bir müşteriye sınırsız yeni kullanım açmak da istenmeyebilir. Geçiş kurallarını ürün ve finans ekipleri birlikte belirlemelidir.

Erişim kararı bir politika tablosunda yer alsın. Hangi durumda sadece okuma, hangi durumda yeni işlem ve hangi durumda dışa aktarma mümkün? Müşteri hesabının kapanması ile verinin silinmesi aynı işlem değildir. Saklama ve hukuki gereksinimler ayrı değerlendirilmelidir.

Örnek: paket düşüren müşteri sınırı aşıyor

Varsayımsal müşteri yüksek pakette on ekip üyesiyle çalışıyor, sonra beş kullanıcı sınırı olan pakete geçiyor. Sistem beş kişiyi rastgele silmemelidir. Yeni üye eklemeyi durdurmak, yöneticiye seçim yaptırmak veya geçişi dönem sonuna planlamak gibi seçenekler değerlendirilebilir. Doğru tercih iş modeline bağlıdır.

Örnek karar ve kabul kontrolleri
OlayVerilecek ürün kararıKullanıcıya açıklama
Paket yükseltmeHakların başlama anıYeni özelliklerin durumu
Paket düşürmeMevcut fazla kullanımYapılması gereken işlem
Ödeme gecikmesiKısıtlama ve toleransSon tarih ve kapsam
İptalDönem sonu veya anlık etkiErişimin biteceği an

Bu tablo ticari politika önerisi değil, kararlaştırılması gereken ayrımların örneğidir. Paket isimleri veya kullanıcı sınırları gerçek Ganz hizmet tarifesi değildir.

Erişimi yalnızca arayüzde kapatmayın

Düğmenin gizlenmesi, API işlemini engellemez. Özellik yetkisi ilgili sunucu işleminde de doğrulanmalıdır. Uzun süren arka plan işi başlatılırken ve kritik çıktı teslim edilirken hangi yetkinin kontrol edildiği belirlenmelidir. Paket değişikliği sırasında bekleyen işlerin davranışı açık olsun.

API sözleşmesinde erişim hatalarını tutarlı gösterin. Microsoft API tasarım rehberi, kaynak ve yanıt davranışlarının açık tasarlanması için temel bir çerçeve sunar. [2] Müşteri “yetkiniz yok” mesajını görünce bunun rol mü, paket mi, kota mı olduğunu anlayabilmelidir; gereksiz iç ayrıntılar açığa çıkarılmamalıdır.

Önbellek ve olay gecikmesini hesaba katın

Paket güncellemesi farklı servislere geç yansıyabilir. Erişim kararının hangi kaynaktan okunduğunu ve önbelleğin ne zaman yenilendiğini belirleyin. Kritik yetki geri alımlarında uzun süre eski hakların kalması istenmeyebilir. Her özellik için aynı gecikme toleransı uygun olmayabilir.

Geciken veya tekrar gelen abonelik olayları yeni durumu geriye çekmemelidir. Olay kimliği, güncellik ve kaynak doğrulama stratejisi kullanın. Yönetim panelinde müşterinin paket adıyla gerçek etkin hakları karşılaştırılabilsin; çelişkiler destek ekibine açıklanabilir olsun.

Kabul testleri ürün yaşam döngüsünü kapsasın

Denemeden ücretliye geçiş, dönem sonu iptal, başarısız ödeme, yükseltme, düşürme ve yeniden etkinleştirme senaryolarını çalıştırın. Aynı kullanıcı farklı tarayıcı ve API yolundan aynı haklara sahip olmalıdır. Mevcut verinin paket değişiminde korunup korunmadığını kontrol edin.

Teslimde özellik sözlüğü, paket eşleştirmesi, durum geçiş tablosu ve destek yönergesi isteyin. Yeni paket oluşturmak için kodun birçok noktasının elle değiştirilmesi gerekiyorsa bakım yükü teklifin önemli bir parçasıdır.

Sık sorulan sorular

### Paket ile kullanıcı rolü aynı şey mi? Hayır. Paket şirketin hangi ürün özelliklerine sahip olduğunu, rol ise kullanıcının bu şirket içinde hangi işlemleri yapabileceğini belirleyebilir.

İptal isteği geldiğinde hesabı hemen silmeli miyim?

Bu otomatik bir sonuç olmamalıdır. Abonelik bitişi, erişim kısıtı, dışa aktarma ve veri silme ayrı politikalara bağlıdır; koşullar açıkça tanımlanmalıdır.

Teknik kaynaklar

  1. Stripe: özellik erişimi yönetimi
  2. Microsoft: API tasarım ilkeleri

Kaynaklar teknik kavramları destekler. Örnek tablolar ve senaryolar önerilen çalışma araçlarıdır; gerçek müşteri sonucu, bağımsız denetim veya platform garantisi değildir. Uygulama öncesinde kullanılan ürünün güncel koşulları kontrol edilmelidir.

Bu ihtiyacı çalışan bir sisteme dönüştürelim.

Mevcut sisteminizi, sorun yaşadığınız iş akışını ve beklediğiniz sonucu paylaşın. Ganz Dijital ile projenizin kapsamını ve kabul koşullarını netleştirin.

İlgili hizmeti inceleWhatsApp üzerinden görüşelim →

Hazırlama notu: İçerik, belirtilen kaynaklar ve özgün örnek senaryolar kullanılarak yapay zekâ desteğiyle hazırlanmıştır. Sayısal örnekler aksi belirtilmedikçe varsayımsaldır. İşletmeye özel güvenlik, hukuki ve operasyonel gereksinimler ayrıca değerlendirilmelidir.