Wenn ein SaaS mehrere Tarife einführt, liegt es nahe, jeden Unterschied mit einer Bedingung im Code abzubilden: Hat der Kunde den erweiterten Tarif, wird diese Option angezeigt; andernfalls bleibt sie verborgen. Anfangs funktioniert das, doch mit Änderungen an Abonnements, Zusatzoptionen, befristeten Testphasen und individuellen Vereinbarungen wird der Ansatz zunehmend anfällig. Dann geht es nicht mehr nur darum, welcher Button sichtbar ist, sondern darum, über welche Funktionen ein Konto verfügt, wer sie nutzen darf und unter welchen Bedingungen.
Ein klares Modell trennt geschäftliche Entscheidungen von den Regeln, die das Produkt anwendet. Dadurch lassen sich Angebote leichter ändern, Übergänge testen und einheitliche Abläufe in Benutzeroberfläche, API und internen Prozessen sicherstellen. Dieser Leitfaden zeigt, nach welchen Kriterien Sie ein solches Modell gestalten und erkennen können, wann das bestehende vereinfacht werden sollte.
Der Tarif sollte keine direkte Anwendungsregel sein
Ein Tarif ist eine Möglichkeit, ein Angebot zu beschreiben und zu verkaufen. Er kann Funktionen und Limits bündeln, sollte aber nicht die alleinige Grundlage für jede Entscheidung im Produkt sein. Fragt die Anwendung immer wieder ab, ob ein Konto zum Tarif „Pro“ gehört, ist die Logik an eine Bezeichnung aus dem Marketing gekoppelt. Diese kann sich ändern, obwohl die Funktion selbst bestehen bleibt.
Übersetzen Sie das Abonnement stattdessen in eine explizite Menge tatsächlich geltender Rechte. So kann für ein Konto beispielsweise der Datenexport aktiviert sein, eine maximale Anzahl an Projekten gelten und eine Integration verfügbar sein. Das Produkt prüft diese Rechte und nicht das Etikett des Tarifs. Wird ein Tarif umbenannt oder neu zusammengestellt, müssen Sie deshalb nicht jede Stelle in der Anwendung anpassen, an der sein Name vorkommt.
Diese Entkopplung erleichtert auch individuelle Angebote. Zwei Konten mit unterschiedlichen Tarifen können dieselbe Funktion nutzen; zwei Konten mit demselben Tarif können sich durch eine gebuchte Zusatzoption unterscheiden. Die Lösung besteht nicht darin, immer mehr Bedingungen einzubauen, sondern das vom Produkt benötigte Ergebnis ausdrücklich abzubilden.
Funktionen, Limits und Berechtigungen trennen
Bevor Sie sich für eine Architektur entscheiden, sollten Sie vier häufig vermischte Begriffe auseinanderhalten:
- Tarif: ein einem Konto zugeordnetes kommerzielles Angebot mit bestimmten Bedingungen und einer Gültigkeitsdauer.
- Freigeschaltete Funktion: eine für das Konto verfügbare Möglichkeit, etwa Daten zu exportieren oder eine Integration zu nutzen.
- Nutzungslimit: eine Höchstmenge oder ein Kontingent für eine Ressource, zum Beispiel Nutzer, Projekte oder Speicherplatz.
- Berechtigung: eine Aktion, die eine bestimmte Person innerhalb des Kontos aufgrund ihrer Rolle oder der Kontoeinstellungen ausführen darf.
Eine Funktion kann im Abonnement enthalten sein und trotzdem nicht allen Nutzern offenstehen. Umgekehrt kann eine Person berechtigt sein, Projekte zu verwalten, während das Konto sein Limit bereits erreicht hat. Für die Freigabe einer Aktion müssen daher möglicherweise das Recht des Kontos, die individuelle Berechtigung und der Zustand der betreffenden Ressource gemeinsam geprüft werden.
Legen Sie außerdem genau fest, was jedes Limit bedeutet. „Bis zu zehn Projekte“ kann sich auf aktive Projekte, auf einen bestimmten Zeitraum oder auf alle jemals angelegten Projekte beziehen. Klären Sie, wann ein Zähler zurückgesetzt wird, was beim Erreichen des Höchstwerts geschieht und wie mit bestehenden Daten umzugehen ist, die nach einem Tarifwechsel über dem neuen Limit liegen. Bleiben diese Regeln unausgesprochen, trifft das Team auf verschiedenen Bildschirmen und in unterschiedlichen Abläufen womöglich unterschiedliche Entscheidungen.
Wo die Regeln abgebildet werden
Der geeignete Ort hängt von der Komplexität und davon ab, wer das Angebot ändern muss. Bei einem Produkt mit wenigen Tarifen und seltenen Änderungen kann eine versionierte Konfiguration zusammen mit der Anwendung genügen. Diese Lösung ist einfach zu prüfen und zu testen, solange dieselben Regeln nicht an vielen Stellen unabhängig voneinander umgesetzt werden.
Muss das Geschäftsteam die Zusammensetzung der Tarife ohne eine Code-Auslieferung anpassen können, kann es sinnvoll sein, Katalog und Zuweisungen in einer verwaltbaren Datenquelle zu speichern. Dadurch entstehen zusätzliche Aufgaben: Sie müssen festlegen, wer die Konfiguration bearbeiten darf, Änderungen validieren und einen Verlauf aufbewahren, damit sich nachvollziehen lässt, welche Regeln zu einem bestimmten Zeitpunkt galten. Eine dynamisch bearbeitbare Konfiguration ist kein Vorteil, wenn eine Änderung Konten in widersprüchliche Zustände versetzen kann.
Eine weitere Möglichkeit: Das Abonnementsystem verwaltet Produkte, Laufzeiten und Zusatzoptionen, während das Produkt intern die tatsächlich geltenden Rechte abbildet. Vermeiden Sie, dass jeder Bildschirm direkt das Abrechnungssystem abfragt. Das würde Komponenten eng koppeln und könnte bei Verzögerungen oder Fehlern bei der Synchronisierung zu unterschiedlichen Ergebnissen führen. Legen Sie fest, welches System für welche Daten maßgeblich ist und wie die jeweils andere Darstellung aktualisiert wird.
Bei jeder dieser Varianten sollten Benutzeroberfläche, API und Hintergrundprozesse dieselbe Bedeutung nicht unabhängig voneinander umsetzen. Bündeln Sie die Zugriffsprüfung in einer wiederverwendbaren Schicht und dokumentieren Sie deren Schnittstelle. Die Benutzeroberfläche kann darauf hinweisen, dass eine Option nicht verfügbar ist, aber die API muss die Aktion erneut prüfen. Ein ausgeblendetes Steuerelement ist keine Autorisierung.
Änderungen, Übergänge und Zusatzoptionen abbilden
Abonnements ändern sich im Lauf der Zeit. Ein Wechsel kann zu einem künftigen Stichtag wirksam werden; außerdem kann es eine Testphase, eine ausstehende Verlängerung oder eine geplante Kündigung geben. Speichern Sie den Status und die relevanten Daten und legen Sie fest, welche Rechte vor und nach dem Übergangszeitpunkt gelten. Verlassen Sie sich nicht ausschließlich auf eine aktuelle Tarifbezeichnung, wenn für das Konto bereits ein später wirksamer Wechsel vereinbart wurde.
Beantworten Sie für jeden Tarifwechsel ausdrücklich folgende Fragen:
- Wann wird der Wechsel wirksam: sofort, zum Ende des Abrechnungszeitraums oder zu einem vereinbarten Datum?
- Was geschieht mit Ressourcen, die das neue Limit überschreiten?
- Wird das Erstellen neuer Elemente gesperrt, werden andere Aktionen eingeschränkt oder ist ein Eingreifen erforderlich?
- Wie wird der Kontoadministrator über den Status informiert?
Löschen oder verändern Sie Daten nicht automatisch als pauschale Reaktion auf einen niedrigeren Tarif. Legen Sie fest, welche Aktionen eingeschränkt werden und wie der normale Betrieb wiederhergestellt werden kann. Bilden Sie eine separat gebuchte Funktion als eigenständiges Recht ab, das gegebenenfalls eine eigene Laufzeit hat. So müssen Sie nicht für jede Kombination einen neuen Tarif erstellen.
Kundenspezifische Ausnahmen: ausdrücklich, begrenzt und überprüfbar
Ausnahmen können berechtigt sein, etwa für einen Pilotversuch, eine Kompensation oder eine vertragliche Anforderung. Riskant wird es, wenn sie als Sonderbedingungen an vielen Stellen im Code verteilt oder ohne Zuständigkeit und Prüftermin manuell eingerichtet werden.
Dokumentieren Sie für jede Ausnahme das betroffene Unternehmen oder Konto, die geänderte Funktion oder das angepasste Limit, den Grund, die genehmigende Person und die Gültigkeitsdauer. Ist die Ausnahme befristet, legen Sie von Anfang an fest, wann sie endet und welches Verhalten danach gilt. Eine Ausnahme ohne Enddatum kann dauerhaft Teil des Produkts werden, ohne dass sich noch jemand an ihren ursprünglichen Zweck erinnert.
Prüfen Sie vor einer weiteren Ausnahme, ob dahinter ein allgemeinerer Produktbedarf steckt. Benötigen mehrere Konten dieselbe Zusatzoption, ist es möglicherweise sinnvoller, sie regulär anzubieten. Beruht eine Regel auf einer vertraglichen Verpflichtung, halten Sie sie klar erkennbar und getrennt von der allgemeinen Logik. Das Team sollte den Status eines Kontos erklären und überprüfen können, ohne dafür verstreute Bedingungen zusammensuchen zu müssen.
Tests, Diagnose und Migration
Testen Sie nicht nur die anfängliche Zuweisung, sondern auch Statusänderungen und deren Folgen. Decken Sie mindestens eine freigeschaltete und eine nicht verfügbare Funktion ab, ein Limit unmittelbar vor und nach dem Erreichen, einen ausstehenden Tarifwechsel, eine auslaufende Zusatzoption und eine abgelaufene Ausnahme. Prüfen Sie dieselbe Entscheidung in der Benutzeroberfläche, in der API und in internen Prozessen, die Ressourcen erstellen oder ändern.
Protokollieren Sie genügend Informationen, um nachvollziehen zu können, warum eine Aktion zugelassen oder abgelehnt wurde: das Konto, das geprüfte Recht, das relevante Limit und das Ergebnis. Vermeiden Sie unnötige sensible Daten. Eine verständliche Meldung für Nutzer kann sich von technischen Details unterscheiden, doch beide müssen dieselbe tatsächlich getroffene Entscheidung widerspiegeln.
Es gibt klare Anzeichen dafür, dass das Modell überarbeitet werden sollte: zahlreiche Prüfungen anhand von Tarifnamen, Abweichungen zwischen Benutzeroberfläche und API, Ausnahmen ohne zuständige Person, unklare Limits oder geschäftliche Änderungen, die Anpassungen an vielen Produktstellen erfordern. Für eine Migration sollten Sie zunächst alle vorhandenen Regeln erfassen. Definieren Sie anschließend Rechte und Limits mit stabilen Bezeichnungen, bündeln Sie die Auswertung und vergleichen Sie die Ergebnisse für repräsentative Fälle mit dem bisherigen Verhalten. Migrieren Sie schrittweise und behalten Sie eine Möglichkeit bei, Abweichungen zu erkennen, bevor Sie die alte Logik entfernen.
Entscheidend ist, abzubilden, was das Produkt erlaubt, und nicht, wie das Vertriebsteam ein Angebot nennt. Tarife und Abrechnung können sich ändern. Die tatsächlich verfügbaren Funktionen, Limits und Berechtigungen müssen an allen Zugriffspunkten verständlich, überprüfbar und konsistent bleiben.