Guides / SaaS-Preisgestaltung im Wandel: Verwaltung von Bestandsplänen, Bestandsschutz und Migrationen

SaaS-Preisgestaltung im Wandel: Verwaltung von Bestandsplänen, Bestandsschutz und Migrationen

Eine Frau und ein Mann stehen in einem Büro und betrachten Haftnotizen an einer Glaswand.

Häufige Änderungen an SaaS-Preismodellen führen oft zu Problemen mit bestehenden Verträgen und Berichten. Anstatt Produkte zu „klonen“ (z. B. Gold_Plan_v2 zu erstellen), sollten Betriebsteams das Stichtagsprinzip nutzen, um eine Art „Zeitmaschine“ für ihren Produktkatalog zu schaffen. Statt Produkte zu klonen (z. B. Gold_Plan_v2), sollten Betriebsteams auf stichtagsbasierte Abonnementgebühren-Segmente und, sofern verfügbar, Dynamic Pricing setzen. So kann ein einzelnes Produkt mit einer Tarifstruktur verschiedene Preise über die Zeit abbilden und gleichzeitig die Historie im Abonnement erhalten – das ermöglicht reibungsloses Grandfathering und automatisierte Preisanpassungen ohne Datenfragmentierung.

Wichtige Erkenntnisse:

  • Keine SKU-Klone mehr: Das Duplizieren von Produkten bei jeder Preisänderung zerstört historische Analysen und fragmentiert die Datenbasis.

  • Stichtagsprinzip nutzen: Weisen Sie Gebühren „Start“- und „End“-Daten zu, um Preise dynamisch zu versionieren.

  • Grandfathering über Verfügbarkeit: Halten Sie Alttarife für Verlängerungen aktiv, blenden Sie diese aber für neue Vertriebskanäle aus, um „Zombie-SKUs“ zu vermeiden.

Die Lösung: Wirksamkeitsdaten (Die Zeitmaschine)

Der grundlegende Fehler der meisten Abrechnungssysteme besteht darin, dass sie Preise als statisch betrachten. In Wirklichkeit sind Preise jedoch zeitabhängig. Ein Preis ist nur für einen bestimmten Zeitraum gültig.

Ein zukunftssicherer Produktkatalog nutzt das Management von Gültigkeitsdaten, um diese zeitliche Dimension abzubilden. In Zuora definiert der Katalog die Standarddaten und Preise, während Segmentierungen von Abonnement-Preisplänen und Dynamic Pricing-Tabellen den tatsächlichen Verlauf der Preisänderungen im Zeitverlauf abbilden.

Der „Time Machine“-Workflow: Ein Migrationsbeispiel

Angenommen, Sie müssen den Preis Ihres „Pro Monthly“-Tarifs ab dem 1. Januar für alle neuen Kunden von 50 $ auf 60 $ erhöhen.

Der falsche Weg (Klonen):

  • Erstellen Sie Pro_Monthly_v2 zu 60 $.
  • Blenden Sie Pro_Monthly_v1 im Vertriebssystem aus.
  • Ergebnis: Das Reporting ist fehlerhaft; das System geht davon aus, dass Sie ein völlig neues Produkt eingeführt haben.

Der richtige Weg (Versionierung):

  1. Zugriff auf den Produkt-Preisplan: Navigieren Sie im Katalog zum bestehenden „Pro Monthly“-Preisplan.
  2. Alten Preis beenden: Wählen Sie die bestehende 50 $-Gebühr aus. Setzen Sie das Gültigkeitsendedatum auf 31. Dezember 2024. Damit teilen Sie dem System mit: „Nach diesem Datum existiert dieser Preis für neue Verkäufe nicht mehr.“
  3. Neuen Preis einführen: Am oder vor dem 1. Januar 2025 aktualisieren Sie den Listenpreis der Produkt-Preisplan-Gebühr auf 60 $. Neue Abonnements, die nach dieser Änderung erstellt werden, übernehmen den Listenpreis von 60 $. Bestehende Abonnements behalten ihren bisherigen Preis über die Segmentierung der Abonnementgebühr; ein Klonen ist nicht erforderlich. Wenn Sie möchten, dass Verlängerungen automatisch den aktuellen Preis übernehmen, stellen Sie die Preisänderungsoption der Gebühr auf „Aktuelle Produktkatalog-Preisgestaltung verwenden“ (optional unterstützt durch Dynamic Pricing).

 

Das Ergebnis:

  • Vertriebsmitarbeitende: Am 1. Januar erstellen Vertriebsmitarbeitende Angebote über Zuora CPQ (oder Ihr CPQ), das nur den aktuellen Preis (60 $) anzeigt, da der 50 $-Preis abgelaufen ist.
  • Bestandskunden: Ihre Abonnements sind an die spezifische Version der Gebühr gebunden, die sie gekauft haben. Sie zahlen weiterhin 50 $, bis Sie sie explizit migrieren.

 

Datenanalyse: Ihr Dashboard zeigt das Umsatzwachstum von „Pro Monthly“ mit einer klaren historischen Trendlinie.

Die „Bestandsschutz“-Strategie: Innovation ohne Reibungsverluste

Bestandskundenschutz (d. h. bestehende Kunden behalten ihren ursprünglichen Tarif, während neue Kunden auf Markttarife umgestellt werden) ist die gängigste Strategie zur Kundenbindung im SaaS-Bereich. Operativ führt dies jedoch häufig zu „Zombie-SKUs“, die dauerhaft im System verbleiben und den Angebotsprozess unnötig verkomplizieren.

Best Practice: Verfügbarkeit steuern, nicht nur den Preis

Um Bestandskundenschutz erfolgreich umzusetzen, müssen Sie die Produktdefinition vom Verkaufszeitraum trennen.

Kataloge auf höchstem Niveau ermöglichen es Ihnen, den Lebenszyklusstatus eines Tarifplans zu steuern:

  • „Aktiv für Neukunden“: Der Tarif ist im CPQ und auf der Website sichtbar.
  • „Inaktiv für Neukunden/Aktiv für Verlängerungen“: Der Tarif ist im CPQ ausgeblendet, aber für Abrechnung und Verlängerungen voll funktionsfähig.

 

Das „Zombie“-Bereinigen:

Sobald Sie Ihre Preisstruktur versionieren, schalten Sie die Altversion sofort auf „Inaktiv für Neukunden“. So wird sichergestellt, dass kein Vertriebsmitarbeiter versehentlich den alten Preis anbietet, während das Abrechnungssystem weiterhin die zahlreichen Verlängerungen zu diesem alten Preis abwickeln kann.

Fortgeschrittener Ansatz: Automatisierte Preisanpassungen

Unternehmen, die Bestandskunden behutsam auf Markttarife umstellen möchten, setzen häufig auf automatisierte Preisänderungen. Anstatt Kunden manuell zu migrieren, konfigurieren Sie den Katalog so, dass bei der Verlängerung eine Logikregel angewendet wird:

  • Regel: „Bei Verlängerung wählen: Keine Änderung, Erhöhung um einen festen Prozentsatz oder Verwendung des aktuellen Produktkatalogpreises. Für CPI-basierte Anpassungen richten Sie einen Workflow oder eine Integration ein, um CPI-Indizes in Zuora (z. B. als Attribute) zu übergeben, und nutzen Sie optional Dynamic Pricing, um diese CPI-basierten Anpassungen bei der Verlängerung automatisch anzuwenden.“
  • Regel: „Verwende den aktuellen Produktkatalogpreis.“ (Dadurch wird das Abonnement bei Verlängerung auf den aktuellen „Straßenpreis“ umgestellt).

 

Mit dieser Funktion können Sie eine Migrationsstrategie umsetzen, ohne einen einzigen Kundendatensatz manuell bearbeiten zu müssen. Für noch mehr Präzision können Sie Dynamic Pricing nutzen, um den Listenpreis zur Laufzeit anhand von Attributen (Kundensegment, Region, Vertriebskanal) und Stichtagen zu berechnen. So lassen sich kontextspezifische Anpassungen während der Verlängerung automatisch und ohne manuelles Eingreifen anwenden.

DevOps für Preisgestaltung: Der Deployment-Manager

In Unternehmen gilt eine Preisänderung als Deployment. Sie beeinflusst die Umsatzrealisierung, die Steuerberechnung und die Vertriebsvergütung. „Hotfixes“ von Preisen direkt in der Produktivumgebung verstoßen gegen bewährte Governance-Praktiken (und stellen häufig einen SOX-Compliance-Verstoß dar).

Führende Organisationen setzen einen Deployment Manager ein, um die Preisgestaltung mit derselben Sorgfalt zu behandeln wie Software-Code.

Der Governance-Workflow:

  1. Sandbox-Umgebung: Das Product Ops-Team entwickelt die neue „Pricing-Strategie 2025“ in einer sicheren Sandbox. Es werden Edge Cases getestet: Was passiert, wenn ein Nutzer mitten im Monat ein Upgrade durchführt? Wird die Steuer in Deutschland korrekt berechnet?
  2. Vergleich & Differenz: Das Deployment Manager-Tool vergleicht den Sandbox-Katalog mit dem Produktionskatalog und hebt exakt hervor, was sich geändert hat (z. B. „Gebühr A um 10 $ erhöht“).
  3. Audit-Log: Die Finanzabteilung prüft die „Differenz“ und genehmigt die Änderung.
  4. Promotion: Die genehmigten Änderungen werden in die Produktion übernommen.

 

Dieser Prozess bietet eine gesteuerte Rollback-Option. Sollte ein Katalog-Deployment einen Checkout-Prozess stören, kann dieser Deployment-Lauf kontrolliert und nachvollziehbar zurückgesetzt werden – etwas, das Tabellenkalkulationen und fest codierte Anwendungen nicht leisten können.

Secureframe hat einen codelosen Produktkatalog eingeführt, um schnelle Anpassungen der Pakete zu ermöglichen. Damit wurden „engere Leitplanken“ für ihre Vertriebsangebote geschaffen, sodass jede Angebotsversion an potenzielle Kunden stets die aktuellste und konforme Produktdefinition widerspiegelt.

Technischer Einblick:

Der Deployment Manager von Zuora bietet einen gesteuerten, nachvollziehbaren Prozess für die Übernahme von Katalogänderungen (Vergleich, Deployment, Rollback).

Strategische Agilität mit Zuora

Ihre Fähigkeit, Preisgestaltungen flexibel anzupassen, ist ein entscheidender Wettbewerbsvorteil. Wenn Sie ein neues Preismodell innerhalb weniger Wochen testen können, während Ihr Wettbewerber dafür Monate benötigt, sind Sie klar im Vorteil.

Das Product Catalog von Zuora wurde entwickelt, um technische Altlasten aus der Preisstrategie zu eliminieren.

  • Interne Fallstudie (Z-on-Z): Zuora hat seinen eigenen Produktkatalog umstrukturiert, um „automatisierte Vertragsänderungen“ zu ermöglichen. Dadurch kann das Team nicht-standardisierte Angebote und komplexe hybride Bündelungen deutlich schneller abwickeln.
  • Secureframe: Durch die Einführung eines codelosen Katalogs hat Secureframe „engere Leitplanken“ für ihre Angebotsprozesse geschaffen. So wird sichergestellt, dass bei jeder Preisiteration jedes Angebot an potenzielle Kunden stets die aktuellste und konforme Produktdefinition widerspiegelt.

 

Lassen Sie nicht zu, dass Ihre Datenbank Ihre Strategie bestimmt. Entkoppeln Sie Ihre Preisgestaltung von Ihrem Code und iterieren Sie ohne Angst.

Erleben Sie den Deployment Manager von Zuora in Aktion

Häufig gestellte Fragen (FAQ)

1. Was ist der Unterschied zwischen SKU-Klonen und Versionierung? 

Beim Klonen wird ein vollständig neuer Datenbankeintrag (SKU) für eine Preisänderung erstellt, wodurch der Datenverlauf fragmentiert wird. Bei der Versionierung bleibt die gleiche SKU erhalten, es wird jedoch ein neuer „Preiseintrag“ hinzugefügt, der nur für einen bestimmten Zeitraum gültig ist. 

2. Wie können Bestandskunden übernommen werden, ohne neue SKUs zu erstellen? 

Hierfür wird das „Stichtagsprinzip“ (Effective Dating) verwendet, um den alten Preis für neue Bestellungen ablaufen zu lassen, während er für bestehende Abonnements weiterhin aktiv bleibt. Anschließend werden die Einstellungen zur „Produktverfügbarkeit“ so gesteuert, dass Vertriebsmitarbeiter nur den aktuellen Marktpreis sehen können. 

3. Was ist ein Deployment Manager im SaaS-Pricing? 

Ein Deployment Manager ist ein Governance-Tool, mit dem Sie Preisänderungen in einer Sandbox-Umgebung erstellen und testen und diese anschließend in die Produktivumgebung „überführen“ können. So wird die Nachvollziehbarkeit gewährleistet und Fehler werden vermieden.