Berechtigungsmodell für Kundentiers: Pläne, Limits, Flags

Warum Teams ein Berechtigungsmodell brauchen

Wenn du mehr als ein Tier verkaufst, bekommst du früher oder später dasselbe Support-Ticket: „Kunde X hat für Pro bezahlt, kann aber Feature Y nicht nutzen.“ Ohne ein klares System kann der Support das nicht direkt beheben. Eine einfache Zugriffsänderung wird zur Engineering-Aufgabe.

Das größere Problem ist Inkonsistenz. Zugriffsregeln verstreuen sich im Produkt: ein Kontrollkästchen im Admin, eine hartkodierte Prüfung in der API, eine Notiz in einer Tabelle und ein einmaliges DB-Update vom letzten Quartal. Kunden sehen unterschiedliches Verhalten an verschiedenen Stellen, und niemand ist sicher, welche Regel die ausschlaggebende ist.

Ein Berechtigungsmodell gibt dir eine einzige Quelle der Wahrheit dafür, wer was tun darf — basierend auf dem Plan und genehmigten Ausnahmen. Es macht Tiers vorhersehbar (damit Preise glaubwürdig bleiben), lässt aber Platz für reale Fälle: ein temporäres Upgrade, eine Quota-Erhöhung oder ein Pilot-Feature für ein Konto.

„Ohne Engineering anpassen“ sollte konkret sein. In der Praxis:

• Support ändert den Zugriff im Admin-Tool durch Bearbeiten von Daten, nicht durch das Anfordern eines Deploys.
• Das Produkt liest überall dieselben Entitlement-Daten (Backend, Web, Mobile).
• Ausnahmen können zeitlich begrenzt und umkehrbar sein, keine dauerhaften Hacks.
• Änderungen werden protokolliert mit wer, wann und warum.

Zum Beispiel: Ein Business-Kunde erreicht während einer geschäftigen Saison ein Limit für aktive Nutzer. Support sollte +10 Seats für 14 Tage gewähren können, und das System rollt es nach Ablauf automatisch zurück. Engineering ist nur gefragt, wenn wirklich eine neue Fähigkeit hinzukommt, nicht für routinemäßige Zugriffsanpassungen.

Die grundlegenden Bausteine: Kunden, Pläne und Entitlements

Ein gutes Berechtigungsmodell beginnt mit einigen klaren Objekten und eindeutiger Verantwortlichkeit. Wenn diese Basics unklar sind, fragt Support jede Woche Engineering nach „nur einer Ausnahme mehr“.

Hier ist ein einfacher Satz von Bausteinen:

• Customer (Account/Tenant): das Unternehmen oder die Person, die dein Produkt nutzt.
• Subscription: die kommerzielle Beziehung (Trial, aktiv, gekündigt), oft an ein Billing-System gekoppelt.
• Plan: das benannte Tier (Free, Pro, Enterprise), das den Standardzugang definiert.
• Entitlement: das tatsächlich erlaubte Verhalten, abgeleitet vom Plan plus etwaigen Overrides.

Die Entitlement-Auswertung ist nicht Billing. Billing beantwortet „was sollen wir berechnen und wann?“, Entitlements beantworten „was darf dieser Kunde gerade?“. Ein Kunde kann unbezahlte Rechnungen haben, aber noch in einer Nachfrist sein, oder bezahlt, aber vorübergehend wegen Compliance blockiert. Halte diese Entscheidungen getrennt, damit Finance Rechnungen korrigieren kann, ohne versehentlich Produktzugriffe zu verändern.

Mehrere Gruppen verlassen sich auf dieses Setup:

• Product definiert, was Pläne bedeuten.
• Support braucht sichere Kontrollen, um Zugriff zu gewähren oder zu entziehen.
• Sales Ops braucht konsistente Regeln für Deals und Renewals.
• Finance braucht eine verlässliche Abbildung zwischen Verkauf und gewährtem Zugriff.

Setze Grenzen früh. Mach Plan-Inhalte und Kunden-Overrides konfigurierbar (damit Support handeln kann), aber halte Kernverhalten in Code. Beispiele für „Core Behavior“ sind, wie du verbleibende Kontingente berechnest, wie abgelaufene Trials gehandhabt werden und welche Aktionen auditiert werden müssen.

Flags, Limits und Quotas: den richtigen Typ wählen

Die meisten Tiering-Probleme lösen sich leichter, wenn du das Entitlement richtig benennst. Es gibt drei gängige Typen, und jeder beantwortet eine andere Frage:

• Boolean Flags: ist etwas an oder aus? Beispiel: export_enabled = true.
• Numerische Limits: wie viel ist gleichzeitig erlaubt? Beispiel: max_seats = 10.
• Quotas: wie viel kann im Zeitverlauf verwendet werden? Beispiel: api_calls_per_month = 100000.

Flags sind ideal für Features, die nicht teilweise funktionieren sollten. Ist Export aus, verberge den Button und blockiere auch den Endpoint. Limits eignen sich für Kapazitäts-Einstellungen, die nicht zurückgesetzt werden, wie Seats, Projekte oder gespeicherte Views.

Quotas brauchen besondere Sorgfalt, weil die Zeit wichtig ist. Support-Tickets verschwinden schnell, wenn die Reset-Regel dokumentiert und im Admin-UI sichtbar ist.

Scope ist die andere Entscheidung, die Verwirrung verhindert. Ein Flag wie „SAML SSO enabled“ ist meist Account-weit. „Max projects“ könnte Workspace-weit sein. „Can run reports“ könnte User-level sein, wenn du rollenbasierte Add-ons verkaufst.

Bei Quotas wähle je Quota genau eine Reset-Regel und halte dich daran:

• Nie (lifetime credits)
• Monatlich (Kalendermonat)
• Rollierendes Fenster (letzte 30 Tage)
• Pro Abrechnungsperiode (entspricht dem Rechnungslauf)

Wenn sich die Reset-Regel je nach Plan ändert, behandle die Regel selbst als Teil des Entitlements, nicht als Stammeswissen.

Ein praktisches Datenbankschema für Entitlements

Ein support-freundliches Entitlements-Modell ist oft am besten langweilig: ein paar Tabellen, klare Keys und zeitlich begrenzte Datensätze, die du auditen kannst. Ziel ist, Admins Zugriff durch Bearbeiten von Daten zu erlauben, nicht durch Code-Deploys.

Beginne mit vier Kern-Tabellen: plans, plan_entitlements, customers und customer_overrides.

• Plans beschreiben Tiers (Free, Pro, Enterprise).
• Plan entitlements beschreiben, was jeder Plan beinhaltet.
• Customers verweisen auf einen Plan.
• Overrides decken Ausnahmen für einen einzelnen Kunden ab, ohne den Plan für alle zu ändern.

Eine kompakte relationale Form, die gut funktioniert:

• 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

Die Entitlement-Felder sollten zwischen den Tabellen konsistent sein. Verwende einen stabilen key wie seats, api_calls oder sso_enabled. Nutze type, um die Auswertung einfach zu halten (z. B. flag, limit, quota). Speichere unit explizit (z. B. users, requests, GB). Für Quotas halte reset_policy eindeutig (z. B. monthly, daily, never).

Overrides sollten wie eine Allowlist mit Datumsangaben funktionieren. Hat ein Kunde ein aktives Override für sso_enabled=true, sollte es innerhalb von effective_from und effective_to über dem Planwert stehen. Das ermöglicht Aktionen wie „Gib 10 zusätzliche Seats für 14 Tage“ als Ein-Zeilen-Änderung, die automatisch ausläuft.

Wie die Entitlement-Auswertung arbeiten sollte

Die Entitlement-Auswertung ist das kleine Stück Code (oder Service), das eine Frage beantwortet: „Darf dieser Kunde das gerade?“ Wenn dieser Teil vorhersehbar ist, bleibt alles andere einfacher zu betreiben.

Verwende eine klare Reihenfolge der Priorität und weiche nicht davon ab: customer override > plan value > system default. Das erlaubt Support, temporäre Ausnahmen zu gewähren, ohne den Plan zu ändern, und gibt Engineering sichere Defaults, wenn nichts konfiguriert ist.

Ein praktischer Auswertungsfluss:

• Identifiziere den Kunden/Account aus der authentifizierten Session (nicht aus dem Request-Body).
• Lade den aktiven Plan des Kunden und alle aktiven Overrides.
• Für einen gegebenen Key: gib das Override zurück, wenn vorhanden; sonst den Planwert; sonst den System-Default.
• Wenn der Key nirgends vorhanden ist, fail closed für Zugriffskontrollen (als „nicht erlaubt“ behandeln) und nutze einen sinnvollen Default für UI-only Anzeigen.
• Wenn der Key unbekannt ist (nicht im Registry), behandle es als Konfigurationsfehler, fail closed und logge es zur Nachverfolgung.

Caching ist wichtig, weil Entitlements ständig geprüft werden. Cache die aufgelösten Entitlements pro Kunde mit kurzer TTL und einer expliziten Versionsnummer. Invalidiere, wenn sich eine dieser Dinge ändert: Plan-Zuordnung, Plan-Definition, Kunden-Overrides oder Kundenstatus (Trial, Grace, Blocked). Ein einfaches Muster ist „cache by customer_id + entitlements_version“, wobei Support-Edits die Version hochsetzen, damit Änderungen schnell sichtbar werden.

Multi-Tenant-Sicherheit ist unverhandelbar. Jede Abfrage muss nach der aktuellen customer/account id filtern, und jeder Cache-Eintrag muss mit dieser id als Key versehen sein. Schau nicht nach Entitlements nur über Email, Domain oder Plan-Name.

Schritt-für-Schritt: ein support-freundlicher Workflow zur Anpassung von Zugriff

Ein support-freundlicher Workflow hält das Modell flexibel, ohne jede Randbedingung zur Engineering-Aufgabe zu machen. Ziel ist, Änderungen sicher vorzunehmen, eine Spur zu hinterlassen und das Kundenerlebnis zu bestätigen.

Ein sicherer Support-Flow

Beginne damit, den richtigen Kunden-Datensatz zu finden und zu bestätigen, was genau gewünscht ist und warum. „Brauchen zwei zusätzliche Seats für eine Woche“ ist anders als „wir haben einen Nachtrag für ein höheres Tier unterschrieben“. Ein gutes Admin-UI macht es einfach, Plan, Kundenstatus und aktive Overrides an einem Ort zu sehen.

Prüfe vor Änderungen die tatsächliche Nutzung gegen das aktuelle Limit oder die Quota. Viele Anfragen verschwinden, wenn klar ist, dass das Konto das Cap nicht erreicht oder das Problem woanders liegt (z. B. Usage-Tracking, das nicht aktualisiert wird).

Wenn du den Zugriff anpassen musst, bevorzuge ein explizites Override statt das Bearbeiten des Plans. Halte Overrides eng gefasst (ein Flag oder ein Limit), füge einen Owner und einen Grund hinzu und setze standardmäßig ein Ablaufdatum. Temporäre Ausnahmen sind üblich und werden leicht vergessen.

Eine einfache Checkliste im Admin-Tool reicht meist aus:

• Bestätige Kunden-Identität, aktuellen Plan und den Grund der Anfrage.
• Prüfe aktuelle Nutzung vs. das relevante Cap.
• Setze ein gezieltes Override und lege ein Ablaufdatum fest.
• Füge Notizen und eine Ticket-/Case-Referenz hinzu.
• Verifiziere das Resultat in der Produkt-UI per Impersonation oder Test-Account.

Verifiziere die Änderung immer so, wie der Kunde sie erleben wird. Wenn du Impersonation unterstützt, mach deutlich sichtbar, wenn sie aktiv ist, und logge sie.

Upgrades, Downgrades, Trials und Grace-Perioden

Die meisten Entitlement-Probleme zeigen sich bei Änderungen: Kunde upgradet während einer Abrechnungsperiode, eine Karte schlägt fehl oder ein Trial endet am Wochenende. Wenn Regeln vage sind, rät Support und Engineering wird reingeholt.

Bei Upgrades: halte es einfach — Zugriff sollte in der Regel sofort wechseln, Gelddetails bleiben im Billing. Dein Entitlements-System sollte auf ein Billing-Ereignis wie „plan changed“ hören und die neuen Plan-Entitlements sofort anwenden. Wenn Billing Proration macht, ist das gut, aber packe keine Prorationsrechnung in die Entitlements-Logik.

Downgrades sind oft problematisch. Wähle ein klares Downgrade-Verhalten und mache es für Support sichtbar:

• Grace period: behalte höheren Zugriff bis zum Ende der bezahlten Periode.
• Nur lesen: erlauben, Daten zu sehen/exportieren, aber keine neuen Schreibvorgänge.
• Sofortiger Stopp: Feature sofort sperren (für risikoreiche Features empfohlen).
• Über-Limit-Verhalten: Nutzung erlauben, aber Erstellen blockieren, wenn Kunde über dem Quota liegt.
• Datenaufbewahrung: Daten behalten, aber Zugriff deaktivieren bis Upgrade.

Trials funktionieren am besten als eigener Plan, nicht als Boolean auf dem Kunden. Gib dem Trial-Plan explizite Flags und Limits sowie eine Auto-Expire-Regel. Wenn das Trial endet, verschiebe den Kunden auf einen Default-Plan (oft „Free“) und wende das definierte Downgrade-Verhalten an.

Grace-Perioden sind nützlich bei Billing-Ausfällen. Ein kurzes „past due“-Fenster (z. B. 3–7 Tage) gibt Zeit, Zahlungen zu fixen ohne mitten im Arbeitstag den Zugriff zu verlieren. Behandle eine Grace-Periode als zeitgebundenes Override, nicht als eigenen Plannamen.

Ein praktischer Tipp: binde Entitlements nicht an Marketing-Tier-Namen wie „Pro“ oder „Enterprise“. Nutze stabile interne Plan-IDs (z. B. plan_basic_v2), sodass du Tiers umbenennen kannst, ohne Regeln zu brechen.

Auditierbarkeit und Sicherheitskontrollen

Wenn Support Zugriff ohne Engineering ändern kann, brauchst du eine Dokumentation. Ein gutes Entitlements-Modell behandelt jede Änderung als aufgezeichnete Entscheidung, nicht als stillschweigende Anpassung.

Für jedes Override erfasse den Handelnden, den geschäftlichen Grund und Zeitstempel. Falls deine Organisation es benötigt, füge einen Genehmigungsschritt für sensible Änderungen hinzu.

Was bei jeder Änderung zu protokollieren ist

Halte das Log simpel, damit es genutzt wird:

• created_by und created_at
• approved_by und approved_at (optional)
• reason (kurzer Text wie „paid add-on“ oder „incident credit“)
• previous_value und new_value
• expires_at

Sicherheitskontrollen verhindern Unfälle vor Auslieferung. Baue Guardrails im Admin-UI und in der Datenbank: begrenze Maximalwerte, blockiere negative Zahlen und erfordere ein Ablaufdatum bei großen Änderungen (z. B. API-Calls 10x erhöhen).

Rollback und Audit-Bereitschaft

Support wird Fehler machen. Gib ihnen eine einzelne „auf Plan-Defaults zurücksetzen“-Aktion, die Kunden-Overrides löscht und das Konto auf den zugewiesenen Plan zurücksetzt.

Für Audits mache die History einfach exportierbar nach Kunde und Zeitraum. Ein CSV-Export mit Grund und Genehmiger beantwortet die meisten Fragen, ohne Engineering einzubeziehen.

Beispiel: Ein Pro-Kunde braucht 30 zusätzliche Seats für eine Woche. Support setzt seats_override=60 mit expires_at nächsten Freitag, fügt Grund „Event“ und Manager-Approval hinzu. Nach Ablauf kehrt das System automatisch auf 30 zurück, und die vollständige Spur ist bei späteren Abrechnungsfragen verfügbar.

Häufige Fehler, die Entitlements schmerzhaft machen

Der schnellste Weg, ein Entitlements-Modell zu ruinieren, ist gewähren, dass es versehentlich wächst. Ein paar frühe Abkürzungen werden zu Monaten voller Support-Tickets und „Warum kann dieser Kunde das?“-Feuerwehrarbeit.

Ein häufiges Problem ist, Zugriffsprüfungen über das Produkt zu verstreuen. Wenn unterschiedliche Teile der App Zugriff unterschiedlich entscheiden, wirst du Widersprüche ausliefern. Zentralisiere die Entitlement-Auswertung hinter einer Funktion oder einem Service und mache alle UI- und API-Aufrufe davon abhängig.

Eine weitere Falle ist, Billing-State mit Zugriff zu vermischen. „Bezahlt“ ist nicht gleich „erlaubt“. Billing hat Retries, Chargebacks, Trials und später abgeglichene Rechnungen. Halte Billing-Ereignisse getrennt und übersetze sie mit klaren Regeln (inkl. Grace-Perioden) in Entitlements, damit Randfälle Benutzer nicht unabsichtlich aussperren oder dauerhaft hereinlassen.

Vermeide es, dich nur auf einen Tier-String wie „basic“ oder „pro“ als einzig wahre Quelle zu verlassen. Tiers ändern sich, und Ausnahmen passieren. Speichere explizite Flags und Limits, damit Support eine Fähigkeit gewähren kann, ohne alle Funktionen eines Tier-Labels zu vergeben.

Unbegrenzte Overrides ohne Guardrails werden unsichtbare Schulden. Verlange Owner, Grund und Ticket-Referenz. Fördere Ablauf- oder Review-Daten. Halte Overrides eng (jeweils ein Key) und leicht auditierbar.

Quotas scheitern auch, wenn Reset-Regeln vage sind. Definiere, was „pro Monat“ heißt (Kalendermonat vs. rollierende 30 Tage), was bei Upgrade passiert und ob nicht genutztes Kontingent übertragen wird. Erzwinge diese Regeln im Backend, nicht nur in der UI, damit Support-Änderungen nicht zu inkonsistentem Verhalten zwischen Web und Mobile führen.

Schnelle Checkliste vor dem Rollout

Bevor du ein Entitlements-Modell ausrollst, mach einen letzten Abgleich mit den Leuten, die es täglich nutzen: Support, Customer Success und die Bereitschaftsperson.

Stelle sicher, dass jedes Feature einem stabilen Entitlement-Key mit klarem Owner zugeordnet ist. Vermeide Duplikate wie reports_enabled vs. reporting_enabled. Sorge dafür, dass jeder Plan explizite Defaults für die Keys hat, die du auslieferst. Wenn ein Key fehlt, fail safe (normalerweise Zugriff verweigern) und alarmiere intern, damit es behoben wird.

Für den Betrieb bestätige, dass der Workflow tatsächlich nutzbar ist:

• Support kann den effektiven Zugriff (Plan-Default plus Override) ohne SQL einsehen.
• Overrides werden protokolliert mit wer, was, warum und wann es ausläuft.
• Quotas haben eine sichtbare Reset-Regel und eine klare Möglichkeit, aktuelle Nutzung anzuzeigen.

Ein Realitäts-Test: Bitte Support, einem Kunden ein 14-tägiges Add-on zu gewähren und es wieder zu entfernen. Wenn sie das sicher in unter zwei Minuten tun können, bist du nah dran.

Beispiel-Szenario: Tiers mit temporärer Ausnahme

Stell dir drei Tiers vor, die jeweils ein paar klare Entitlements setzen, die in der Produkt-UI erscheinen und vom Backend durchgesetzt werden:

• Free: 1 Projekt, 3 Nutzer, 200 Exporte/Monat, Basis-API-Rate-Limit, 7 Tage Audit-Logs.
• Team: 10 Projekte, 25 Nutzer, 2.000 Exporte/Monat, höheres API-Rate-Limit, 30 Tage Audit-Logs.
• Business: unbegrenzte Projekte, 200 Nutzer, 10.000 Exporte/Monat, höchstes API-Rate-Limit, 180 Tage Audit-Logs, SSO enabled.

Nun sagt ein Team-Kunde: „Wir haben Ende Quartal einen Push und brauchen diesen Monat 8.000 Exporte. Könnt ihr für 30 Tage helfen?“ Genau hier ist ein temporäres Override besser als ein Plan-Wechsel.

Support öffnet den Kunden-Datensatz, fügt ein Override wie export_monthly_limit = 8000 hinzu und setzt expires_at auf 30 Tage ab heute. Sie notieren: „Approved by Alex (Sales), 30-day exception for Q4 reporting."

Aus Kundensicht sollten zwei Dinge passieren:

• Die UI zeigt das neue Limit an (z. B. die Nutzungsskala und das Label „Exports remaining“ werden aktualisiert).
• Exporte funktionieren weiter, bis sie 8.000 für den Monat erreichen.

Wenn sie darüber hinausgehen, sehen sie eine klare Meldung wie: „Export-Limit erreicht (8.000/Monat). Kontaktiere Support oder upgrade, um dein Limit zu erhöhen."

Nach Ablauf des Datums endet das Override automatisch und der Kunde fällt ohne manuelles Eingreifen wieder auf das Team-Plan-Limit zurück.

Nächste Schritte: implementieren und iterieren, ohne Support zu verlangsamen

Beginne damit, „Features" in einen kleinen Entitlement-Katalog zu überführen. Gib jedem Item einen klaren Key, einen Typ (Flag vs Limit vs Quota) und einen Default-Wert pro Plan. Dieser Katalog wird zur gemeinsamen Sprache zwischen Product, Support und Engineering — wähle daher spezifische und stabile Namen.

Entscheide, wo die Durchsetzung stattfindet. Eine sichere Regel ist: Durchsetzen in der API für alles, was Daten verändert oder Geld kostet; Hintergrundjobs nutzen, um lang laufende Arbeiten zu stoppen, wenn Limits überschritten werden; und die UI als Orientierung (deaktivierte Buttons, hilfreiche Meldungen) behandeln, aber nicht als einziges Gate.

Halte die erste Version schlank. Konzentriere dich auf die Entitlements, die die meisten Fragen erzeugen, füge Prüfungen an den risikoreichsten Aktionen hinzu und liefere ein Admin-View, das Kunde, Plan, Overrides und History an einem Ort zeigt.

Wenn du das Admin-Panel und die zugrundeliegende Logik schnell bauen willst, ohne alles händisch zu implementieren, ist AppMaster (appmaster.io) eine praktische Wahl für diese Art von Arbeit: Du kannst Pläne und Overrides als Daten modellieren, Prüfungen als Business-Prozesse implementieren und ein Support-UI ausliefern, das Backend und Apps konsistent hält.