Müşteri kademeleri için yetkilendirme modeli: planlar, limitler, özellik bayrakları

Takımların neden bir yetkilendirme modeline ihtiyacı var

Birden fazla kademe satıyorsanız er ya da geç aynı destek talebi ile karşılaşırsınız: “Müşteri X Pro için ödedi ama Özellik Y'ye erişemiyor.” Net bir sistem yoksa destek bunu doğrudan düzeltemez. Basit bir erişim değişikliği mühendislik işi haline gelir.

Daha büyük sorun tutarsızlıktır. Erişim kuralları ürünün farklı yerlerine dağılır: admin ekranında bir onay kutusu, API'de sert kodlanmış bir kontrol, bir hesap tablosunda not ve geçen çeyrekte yapılmış tek seferlik bir veritabanı güncellemesi. Müşteriler farklı yerlerde farklı davranış görür ve hangi kuralın geçerli olduğu belirsiz olur.

Bir yetkilendirme modeli, planlarına ve onaylı istisnalara göre kimin ne yapabileceği konusunda tek bir güvenilir kaynak sağlar. Kademeleri öngörülebilir kılar (böylece fiyatlandırma güvenilir kalır) ve gerçek hayata alan bırakır: geçici yükseltme, kota artışı veya tek bir hesap için pilot özellik gibi.

“Mühendislere ihtiyaç duymadan ayarlama” somut olmalı. Pratikte:

• Destek, bir deploy talep etmek yerine bir admin aracında veriyi düzenleyerek erişimi değiştirir.
• Ürün aynı yetkilendirme verisini her yerde okur (backend, web uygulaması, mobil).
• İstisnalar zaman sınırlı ve geri alınabilir olur, kalıcı hackler değil.
• Değişiklikler kim, ne zaman ve neden yaptığıyla birlikte kaydedilir.

Örneğin, Business kademesindeki bir müşteri yoğun sezonda aktif kullanıcı sınırına takılır. Destek 14 gün için +10 koltuğu verebilmeli ve sistem sürenin sonunda otomatik geri almalı. Mühendislik yalnızca yeni bir yetenek eklenirken müdahil olmalı; rutin erişim ayarlarında olmamalı.

Temel parçalar: müşteriler, planlar ve yetkilendirmeler

İyi bir yetkilendirme modeli birkaç net obje ve net sahiplikle başlar. Bunlar bulanıksa destek her hafta mühendislikten “bir istisna daha” ister.

Basit bir yapı taşları seti:

• Customer (account/tenant): ürününüzü kullanan şirket veya kişi.
• Subscription: ticari ilişki (deneme, aktif, iptal), genellikle faturalama sistemine bağlı.
• Plan: varsayılan erişimi tanımlayan adlandırılmış kademe (Free, Pro, Enterprise).
• Entitlement: plan ve varsa override'lardan türetilen gerçek izin davranışı.

Yetkilendirme değerlendirmesi faturalama değildir. Faturalama “ne ücretlendirilmeli ve ne zaman?” sorusunu yanıtlar. Yetkilendirmeler “bu müşteri şu anda ne yapabilir?” sorusunu yanıtlar. Bir müşteri ödenmemiş olabilir ama gracia dönemi içinde veya ödeme sorunları nedeniyle geçici olarak engellenmiş olabilir. Bu kararları ayırın ki finans faturaları düzeltirken istemeden ürün erişimini değiştirmesin.

Bu yapıdan yararlanan gruplar:

• Ürün, planların ne anlama geldiğini tanımlar.
• Destek güvenli kontrollerle erişimi verip kaldırmak ister.
• Satış operasyonları anlaşmalar ve yenilemeler için tutarlı kurallar ister.
• Finans, satılan ile sağlanan erişim arasında güvenilir bir eşleme ister.

Sınırları erken belirleyin. Plan içeriklerini ve müşteri override'larını yapılandırılabilir yapın (destek müdahale edebilsin), ama temel davranışı koda bırakın. “Temel davranış” örnekleri: kalan kotayı nasıl hesapladığınız, süresi dolmuş denemeleri nasıl ele aldığınız ve hangi işlemlerin denetlenmesi gerektiğidir.

Bayraklar, limitler ve kotalar: doğru türü seçin

Bir yetkilendirmenin doğru adlandırılması çoğu kademe problemini kolaylaştırır. Üç yaygın tür vardır ve her biri farklı bir soruyu cevaplar:

• Boolean bayraklar: bir şey açık mı kapalı mı? Örnek: export_enabled = true.
• Sayısal limitler: bir seferde ne kadar izin veriliyor? Örnek: max_seats = 10.
• Kotalar: zaman içinde ne kadar kullanılabilir? Örnek: api_calls_per_month = 100000.

Bayraklar, kısmi çalışmaması gereken özellikler için en iyisidir. Export kapalıysa butonu gizleyin ve endpoint'i de engelleyin. Limitler, koltuklar, projeler veya kaydedilmiş görünümler gibi sıfırlanmayan “kapasite” ayarları için uygundur.

Kotalar zaman önem taşıdığı için ekstra dikkat ister. Sıfırlama kuralı admin UI'de yazılı ve görünür olduğunda destek talepleri hızlı düşer.

Kapsam (scope) kararı da kafa karışıklığını önler. “SAML SSO enabled” gibi bir bayrak genellikle hesap düzeyindedir. “Max projects” workspace düzeyinde olabilir. “Rapor çalıştırabilir” kullanıcı düzeyinde olabilir eğer rol bazlı eklenti satıyorsanız.

Kotalar için her kota başına bir sıfırlama kuralı seçin ve ona sadık kalın:

• Asla (ömür boyu kredi)
• Aylık (takvim ayı)
• Hareketli pencere (son 30 gün)
• Fatura dönemi başına (fatura döngüsüyle eşleşir)

Eğer sıfırlama kuralı plan bazında değişiyorsa, kuralı da yetkilendirmenin parçası olarak ele alın, kabile bilgisi yerine veriye koyun.

Yetkilendirmeler için pratik bir veritabanı şeması

Destek dostu bir yetkilendirme modeli genellikle sıkıcı kalmalıdır: birkaç tablo, net anahtarlar ve denetlenebilir zaman sınırlı kayıtlar. Amaç, adminlerin kod göndermeden veriyi düzenleyerek erişimi değiştirmesini sağlamaktır.

Dört temel tablo ile başlayın: plans, plan_entitlements, customers ve customer_overrides.

• plans kademeleri tanımlar (Free, Pro, Enterprise).
• plan_entitlements her planın neleri içerdiğini tanımlar.
• customers bir plana işaret eder.
• customer_overrides tek bir müşteri için planı değiştirmeden yapılan istisnaları kapsar.

İyi çalışan kompakt ilişkiselliğe örnek:

• plans: id, name, description, is_active
• plan_entitlements: id, plan_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_by
• customers: id, name, plan_id, status, created_at
• customer_overrides: id, customer_id, key, type, value, unit, reset_policy, effective_from, effective_to, created_by

Yetkilendirme alanları tablolar arasında tutarlı olmalı. seats, api_calls veya sso_enabled gibi sabit bir key kullanın. type değerlendirmeyi basit tutar (örneğin: flag, limit, quota). unit'i açıkça saklayın (users, requests, GB gibi). Kotalar için reset_policy'yi belirsiz bırakmayın (monthly, daily, never gibi).

Override'lar tarihli bir allowlist gibi davranmalıdır. Eğer bir müşterinin aktif sso_enabled=true override'ı varsa, bu plan değerinin üzerinde kazanır, ama yalnızca effective_from ile effective_to aralığında. Bu, “14 gün için 10 ekstra koltuk ver” işlemini tek satırlık bir değişiklikle çözmeyi sağlar.

Yetkilendirme değerlendirmesi nasıl çalışmalı

Yetkilendirme değerlendirmesi, “Bu müşteri şu anda buna izinli mi?” sorusunu yanıtlayan küçük kod parçasıdır (veya servis). Bu parça öngörülebilir olduğunda geri kalan her şey işletmesi daha kolay olur.

Net bir öncelik sırası kullanın ve sapmayın: customer override > plan değeri > sistem varsayılanı. Bu, desteğe geçici istisnalar verme esnekliği sağlar ve hiçbir şey yapılandırılmamışsa mühendisliğe güvenli varsayılanlar verir.

Pratik bir değerlendirme akışı:

• Kimlik doğrulanmış oturumdan müşteri/hesabı belirleyin (istek gövdesinden değil).
• Müşterinin aktif planını ve aktif override'larını yükleyin.
• Belirli bir key için override varsa onu döndürün; yoksa plan değerini; yoksa sistem varsayılanını döndürün.
• Anahtar her yerde eksikse, erişim kontrolleri için reddet (not allowed) ve sadece gösterim amaçlı UI için makul bir varsayılan kullanın.
• Anahtar bilinmiyorsa (kataloğunuzda yoksa), konfigürasyon hatası gibi davranın, reddedin ve takip için loglayın.

Önbellekleme önemlidir çünkü yetkilendirmeler sürekli kontrol edilir. Müşteri bazlı çözülmüş yetkilendirmeleri kısa TTL ve açık bir sürüm numarası ile cacheleyin. Değişiklik olduğunda önbelleği geçersiz kılın: plan ataması, plan tanımı, müşteri override'ları veya müşteri durumu değiştiğinde. Basit bir desen: “customer_id + entitlements_version ile cachele”, destek düzenlemesi sürümü artırır, böylece değişiklikler hızla görünür.

Çok kiracılı (multi-tenant) güvenlik vazgeçilmezdir. Her sorgu geçerli müşteri/hesap id ile filtrelenmeli ve her cache girdisi o id ile anahtarlanmalıdır. Erişimleri yalnızca e-posta, domain veya plan adıyla aramayın.

Adım adım: destek için erişimi ayarlama iş akışı

Destek dostu iş akışı modeli esnek tutar ama her sınır durumunu mühendislik işine dönüştürmez. Amaç: değişiklikleri güvenli yapmak, bir iz bırakmak ve müşteri deneyimini doğrulamaktır.

Güvenli bir destek akışı

Doğru müşteri kaydını bulun ve ne istediklerini ve nedenini doğrulayın. “Bir hafta için iki koltuk daha lazım” ile “daha yüksek kademe için bir ek protokol imzaladık” farklıdır. İyi bir admin UI, mevcut planı, müşteri durumunu ve aktif override'ları tek bir yerde açıkça göstermelidir.

Herhangi bir şeyi değiştirmeden önce, ilgili limit veya kota karşısında gerçek kullanımı kontrol edin. Birçok istek, hesabın aslında kotada olmadığını gören destekle kaybolur (örneğin, kullanım takibi güncellenmiyor olabilir).

Erişimi ayarlamanız gerektiğinde, planı düzenlemek yerine açık bir override tercih edin. Override'ları dar tutun (tek bir bayrak veya tek bir limit), bir sahip ve sebep ekleyin ve varsayılan olarak bir sona erme tarihi koyun. Geçici istisnalar yaygındır ve unutulması kolaydır.

Admin aracınızda basit bir kontrol listesi genelde yeterlidir:

• Müşteri kimliğini, mevcut planı ve istek sebebini doğrulayın.
• Güncel kullanım ile ilgili limit/kota karşılaştırmasını gözden geçirin.
• Kapsamlı bir override uygulayın ve bir sona erme tarihi belirleyin.
• Not ekleyin ve ilgili ticket/case referansını bağlayın.
• İmpersonasyon veya test hesabı kullanarak ürün UI'sinde sonucu doğrulayın.

Değişikliğin müşterinin yaşadığı şekilde doğrulandığından emin olun. İmpersonasyon destekliyorsanız, bunun etkin olduğunu görünür kılın ve loglayın.

Yükseltmeler, düşürmeler, denemeler ve gracia dönemleri

Çoğu yetkilendirme problemi değişim sırasında ortaya çıkar: müşteri dönem ortasında yükseltir, kart düşer veya deneme hafta sonuna denk gelir. Kurallar belirsizse destek tahmin yapmak zorunda kalır ve mühendislik devreye girer.

Yükseltmeler için basit tutun: erişim genellikle hemen değişmeli, para detayları faturalamaya kalsın. Yetkilendirme modeli bir “plan değişti” gibi faturalama olayını dinlemeli ve yeni plan yetkilendirmelerini hemen uygulamalıdır. Eğer faturalama prora­tasyonu yapıyorsa, bu iyi; ama prora­tasyon hesaplarını yetkilendirmeye sokmayın.

Düşürmeler sürprizlerin olduğu yerdir. Net bir düşürme davranışı seçin ve bunu destek ekibine görünür yapın:

• Gracia dönemi: ücretli dönemin sonuna kadar daha yüksek erişimi koru.
• Salt görüntüleme: veriyi görebilir/dışa aktarabilir ama yeni yazma işlemleri engellenir.
• Sert durdurma: özelliği hemen engelle (riskli özellikler için).
• Limit aşımı davranışı: kullanımına izin ver, fakat kota üstündeyken yeni oluşturmayı engelle.
• Veri saklama: veriyi tut, ama erişimi devre dışı bırak.

Denemeler (trials) genelde bir boolean yerine kendi planı olarak daha iyi çalışır. Deneme planına açık bayraklar ve limitler verin, artı otomatik sona erme kuralı. Deneme bittiğinde müşteriyi varsayılan bir plana (çoğunlukla “Free”) taşıyın ve tanımladığınız düşürme davranışını uygulayın.

Fatura hataları için kısa bir "geçmiş due" (örneğin 3–7 gün) pencere kullanıcıların ödeme düzeltmesi için zaman verir. Gracia dönemini zaman sınırlı bir override olarak ele alın, özel bir plan adı gibi değil.

Pratik bir ipucu: yetkilendirmeleri pazarlama isimlerine (Pro, Enterprise gibi) bağlamayın. İçeride stabil plan kimlikleri kullanın (örneğin plan_basic_v2) ki kademe adını değiştirseniz bile kurallar bozulmasın.

Denetlenebilirlik ve güvenlik kontrolleri

Destek mühendisliğe ihtiyaç duymadan erişimi değiştirebiliyorsa, bir iz bırakmanız gerekir. İyi bir yetkilendirme modeli her değişikliği kaydedilmiş bir karar olarak ele alır, sessiz bir düzeltme olarak değil.

Her override için aktörü, iş sebebini ve zaman damgalarını yakalayın. Eğer organizasyonunuz gerekiyorsa hassas değişiklikler için onay adımı ekleyin.

Her değişiklik için ne kaydedilmeli

Kullanılabilir olması için kayıtları basit tutun:

• created_by ve created_at
• approved_by ve approved_at (isteğe bağlı)
• reason (kısa metin: “ödemeli eklenti” veya “olay kredisi” gibi)
• previous_value ve new_value
• expires_at

Güvenlik kontrolleri kazaları üretime ulaşmadan önce durdurur. Admin UI'de ve veritabanında korumalar koyun: maksimum değerleri sınırla, negatif sayıları engelle, büyük değişikliklerde (örneğin API çağrılarını 10x artırma) bir sona erme tarihi zorunlu kıl.

Geri alma ve denetime hazır olma

Destek hata yapacaktır. Onlara tek tıklamayla “plana geri dön” eylemi verin; bu, müşteri düzeyindeki override'ları temizler ve hesabı atanan plana döndürür.

Denetimler için geçmişi müşteri ve tarih aralığına göre dışa aktarmayı kolaylaştırın. Sebep ve onaycıyı içeren temel bir CSV dışa aktarımı çoğu soruya mühendislik müdahalesi olmadan cevap verir.

Örnek: Pro müşterisi bir haftalık etkinlik için 30 ekstra koltuğa ihtiyaç duyuyor. Destek seats_override=60 olarak ayarlar, expires_at önümüzdeki Cuma olur, sebep olarak “etkinlik” yazılır ve yönetici onayı alınır. Süre dolduğunda sistem otomatik olarak 30'a döner ve tam izleme geçmişi faturalama anlaşmazlıkları için hazırdır.

Yetkilendirmeyi zorlaştıran yaygın hatalar

Yetkilendirme modelini bozmanın en hızlı yolu onun kazara büyümesine izin vermektir. İlk birkaç kısa yol oradan aylarca süren destek biletleri ve “bu müşteri bunu nasıl yapabiliyor?” soruşturmasına dönüşebilir.

Sık yapılan hata, özellik kontrollerini farklı yerlere dağıtmaktır. Eğer uygulamanın farklı bölümleri erişime farklı şekilde karar veriyorsa çelişkiler ortaya çıkar. Yetkilendirme değerlendirmesini tek bir fonksiyon veya servisin arkasına merkezi bir şekilde koyun ve tüm UI ile API çağrılarının bunu kullanmasını sağlayın.

Diğer tuzak, faturalama durumu ile erişimi karıştırmaktır. “Ödendi” erişime eşit değildir. Faturalama yeniden denemeler, iade işlemleri, denemeler ve sonradan netleşen faturalar içerir. Faturalama olaylarını yetkilendirmelere açık kurallarla çevirin (gracia dönemleri dahil) ki kenar durumlar kullanıcılara erişim kaybettirmesin veya sınırsız erişim vermesin.

Tek bir “tier” metnine (örneğin “basic” veya “pro”) yalnızca güvenmekten kaçının. Kademe zamanla değişir ve istisnalar olur. Destek bir yeteneği vermek için bütün kademeyi değiştirmeye zorlanmamalı; bunun yerine açık bayraklar ve limitler saklayın.

Sınırsız override'lar görünmez borca dönüşür. Sahip, sebep ve ticket referansı zorunlu kılın. Süre sonu veya gözden geçirme tarihleri isteyin. Override'ları dar tutun (her seferinde tek bir anahtar) ve denetlenmesini kolaylaştırın.

Kotaları da sıfırlama kuralları belirsiz olduğunda yanlış gidebilir. “Aylık”ın ne anlama geldiğini (takvim ayı mı yoksa son 30 gün mü), yükseltme sırasında ne olduğunu ve kullanılmayan kotanın devredilip devredilmediğini tanımlayın. Bu kuralları yalnızca UI'da değil backend mantığında zorunlu kılın.

Yayına almadan önce kısa kontrol listesi

Bir yetkilendirme modelini dağıtmadan önce, onu her gün kullanacak kişilerle (destek, müşteri başarı, on-call) hızlıca gözden geçirin.

Her özelliğin tek bir stabil yetkilendirme anahtarına ve net bir sahibine eşlendiğinden emin olun. reports_enabled ile reporting_enabled gibi çoğaltmalardan kaçının. Gönderdiğiniz her anahtar için planların açık varsayılanları olduğundan emin olun. Bir anahtar eksikse güvenli davranış (genelde erişimi reddet) uygulanmalı ve içsel bir uyarı oluşturulmalı.

Operasyonlar için iş akışının gerçekten kullanılabilir olduğunu doğrulayın:

• Destek, etkili erişimi (plan varsayılanı artı override) SQL yazmadan görebilmeli.
• Override'lar kim neyi, neden ve ne zaman değiştirdiğini kaydediyor olmalı.
• Kotaların görünür bir sıfırlama kuralı ve mevcut kullanımı gösteren bir yolu olmalı.

Gerçeklik testi: desteğe tek bir müşteriye 14 günlük eklenti verme ve sonra kaldırma görevi verin. İki dakikadan kısa sürede güvenle yapabiliyorlarsa doğru yoldasınız.

Örnek senaryo: zamanlı istisna ile kademeler

Üç kademeniz olduğunu ve her kademenin ürün içinde görünen ve backend'de zorlanan birkaç net yetkilendirme belirlediğini varsayalım.

• Free: 1 proje, 3 kullanıcı, ayda 200 dışa aktarma, temel API hız limiti, 7 günlük denetim kayıtları.
• Team: 10 proje, 25 kullanıcı, ayda 2.000 dışa aktarma, daha yüksek API limiti, 30 günlük denetim kayıtları.
• Business: sınırsız proje, 200 kullanıcı, ayda 10.000 dışa aktarma, en yüksek API limiti, 180 günlük denetim kayıtları, SSO etkin.

Şimdi bir Team müşterisi der ki: “Bu ay son çeyrek işi için 8.000 dışa aktarmaya ihtiyacımız var. 30 gün yardımcı olur musunuz?” Bu durumda geçici bir override onları yeni plana taşımaktan daha uygundur.

Destek müşteri kaydını açar, export_monthly_limit = 8000 gibi bir override ekler ve expires_at tarihini 30 gün sonrası yapar. Not ekler: “Alex (Satış) onayladı, Q4 raporlama için 30 günlük istisna.”

Müşteri tarafında iki şey olmalı:

• UI yeni limiti yansıtmalı (kullanım göstergesi ve “Kalan dışa aktarma” etiketi güncellenir).
• Dışa aktarımlar ay boyunca 8.000'e ulaşana kadar çalışmaya devam eder.

Eğer aşarlarsa, şu tarz net bir mesaj görmeliler: “Dışa aktarma limiti aşıldı (8.000/ay). Destek ile iletişime geçin veya limiti arttırmak için yükseltin.”

Süre dolduğunda override otomatik olarak durur ve müşteri müdahale gerekmeden Team plan limitine geri döner.

Sonraki adımlar: uygulayın ve desteği yavaşlatmadan yineleyin

İlk olarak “özellikleri” küçük bir yetkilendirme kataloğuna dönüştürün. Her öğeye net bir anahtar, bir tip (bayrak vs limit vs kota) ve plan başına varsayılan bir değer verin. Bu katalog ürün, destek ve mühendislik arasında ortak bir dil olur; isimleri spesifik ve stabil tutun.

Zorlamanın nerede olacağına karar verin. Güvenli bir kural: veri veya para değiştiren her şeyi API'de zorlayın, uzun süren işler limit aşıldığında arka plan işleriyle durdurun ve UI'yı (devre dışı bırakılmış butonlar, yardımcı mesajlar) yalnızca rehber olarak görün; tek kapı UI olmasın.

İlk versiyonu dar tutun. En çok soru yaratan yetkilendirmelere odaklanın, en yüksek riskli işlemlere kontroller ekleyin ve müşteri, plan, override ve geçmişi tek yerde gösteren bir admin görünümü yayınlayın.

Kod yazmadan yönetici panelini ve mantığı hızlıca kurmak istiyorsanız, AppMaster (appmaster.io) bu tür işler için pratik bir uyum sunar: planları ve override'ları veri olarak modelleyebilir, kontrolleri iş süreçleri olarak uygulayabilir ve backend ile uygulamalarda tutarlı bir destek UI'si yayınlayabilirsiniz.