SaaS-Preismodell-Template: Tiers, die verkaufen

Die meisten SaaS-Pricing-Probleme sind keine Pricing-Probleme. Es sind Strukturprobleme — zu viele Pläne, keine klare Wertmetrik, Upgrade-Trigger, die willkürlich wirken, und eine Pricing-Seite, die alles erklärt außer warum jemand mehr zahlen sollte.

Diese Seite gibt dir die Struktur. Ein 3-Tier-SaaS-Preismodell-Template, das du kopieren, anpassen und shippen kannst — mit der Begründung hinter jeder Entscheidung, damit du verstehst, was du ändern musst, wenn dein Produkt nicht zum Standard passt. Für den Kontext zur vollen Bandbreite verfügbarer Preismodelle deckt der minimalistische Leitfaden jeden Ansatz mit realen Beispielen ab.

Das Template: 3-Tier-SaaS-Preismodell

Das ist die minimale tragfähige Preisstruktur für die meisten Self-Serve-SaaS-Produkte.

Preistabelle

Plan	Am besten für	Preis	Kernlimit	Upgrade-Trigger
Starter	Solo-Nutzung / erste Evaluierung	19 €/Mo	Niedriges Volumen-Cap	Erster Nutzungs-Meilenstein erreicht
Growth	Aktive zahlende Nutzer	49 €/Mo	Mittleres Volumen-Cap	Volumenwachstum / mehr Automatisierung
Scale	Teams / intensivere Nutzung	99 €/Mo	Großes Volumen-Cap	Kollaboration / fortgeschrittene Skalierung

Growth als Standard hervorheben. Er sollte visuell hervorstechen — die meisten Besucher, die ernsthaft evaluieren, landen hier. Starter ist der Low-Commitment-Einstieg. Scale ist für Accounts, die bereits Wert gefunden haben und mehr brauchen.

Wie sich die Tiers für Kunden anfühlen sollten

Starter: „Ich kann echten Wert aus dem Produkt ziehen, bevor ich mich entscheide, mehr zu zahlen.” Kein Bestrafungsplan. Keine kastrierte Demo. Genug, um zu beweisen, dass das Produkt funktioniert.

Growth: „Das ist der Plan für jemanden, der das wirklich nutzt.” Der beste Wert pro Einheit. Klar die richtige Wahl für jeden, der es ernst meint. Hierher kommt der Großteil deines Umsatzes.

Scale: „Für wenn ich das auf voller Kapazität betreibe.” Größere Limits, optional Team- oder Kollaborations-Features. Sollte sich wie ein natürlicher nächster Schritt anfühlen, nicht wie ein plötzlicher Preissprung.

Fragst du dich, ob deine letzte Preisänderung ARPU tatsächlich bewegt hat? Sieh die MRR-Aufschlüsselung nach Plan →

Das zugrunde liegende Preismodell: wie man das Template ausfüllt

Die Tabelle oben ist der Output. Die Entscheidungen unten bestimmen, ob sie tatsächlich konvertiert.

Schritt 1: Eine Wertmetrik wählen

Die Wertmetrik ist die Einheit, für die Kunden mehr zahlen, wenn sie mehr Wert bekommen. Sie treibt das Limit, das sich zwischen Tiers ändert, und schafft den Upgrade-Trigger.

Gute SaaS-Pricing-Metrik-Beispiele nach Produkttyp:

Produkttyp	Starke Wertmetrik-Optionen
Analytics / Metriken-Tool	Verbundene Accounts, getrackte Umsätze, Datenquellen
KI / Automatisierungstool	Abgeschlossene Workflows, Automatisierungs-Runs, verarbeitete Dokumente
API / Developer-Tool	API-Requests, Compute-Minuten, Pipeline-Runs
E-Mail / Outreach-Tool	Kontakte, gesendete E-Mails pro Monat
Projekt / Operations-Tool	Aktive Projekte, aktive Seats, Boards
Billing / Finanztool	Gesendete Rechnungen, verwaltete Abonnements

Der Test: Kannst du diesen Satz vervollständigen? „Wir berechnen mehr, wenn Kunden [mehr X tun], weil [mehr X mehr Wert bedeutet].” Wenn nicht, ist die Metrik nicht klar genug.

Für das vollständige Framework zur Wahl einer Wertmetrik, siehe den dedizierten Leitfaden zur Wahl einer Einheit, die alles klar macht.

Schritt 2: Limits setzen, die natürliche Upgrade-Momente schaffen

Die Limits in jedem Tier sollten so kalibriert sein, dass:

Starter genug ist, um ein erstes echtes Ergebnis zu erreichen (nicht nur den Account einzurichten)
Growth zu einem Kunden passt, der das Produkt im normalen Tempo aktiv nutzt
Scale dort ist, wo Kunden natürlich landen, wenn ihr Geschäft wächst

Eine nützliche Heuristik: schau dir deine aktiven Nutzerdaten an und finde die natürlichen Nutzungscluster. Starter sollte das untere Quartil der aktiven Nutzung abdecken. Growth sollte den Median abdecken. Scale deckt das Top ab.

Vermeide Limits, die willkürlich aussehen (warum genau 1.000?) oder die Angst erzeugen (Kunden in der Nähe des Limits hören auf, das Produkt zu nutzen, um das Cap nicht zu erreichen, statt zu upgraden). Sichtbarkeit im Produkt — aktuelle Nutzung und aktuelles Tier anzeigen — beseitigt den Großteil dieser Angst.

Laut OpenView Partners SaaS-Pricing-Benchmarks sehen Produkte mit sichtbaren In-Product-Nutzungsanzeigen deutlich höhere Upgrade-Raten bei ihren Einstiegsplänen.

Schritt 3: Entscheiden, welche Features sich zwischen Plänen ändern

Die Wertmetrik treibt die primäre Progression. Feature-Unterschiede sollten sekundär sein. Eine Pricing-Seite, deren Hauptunterschied zwischen Tiers eine Checkliste von 20 Feature-Toggles ist, ist schwer zu parsen — Kunden können nicht schnell erkennen, wofür sie tatsächlich zahlen.

Features, die sich zu tiern lohnen:

Kollaboration / Team-Seats — wenn Teamarbeit Teil des Produktwerts ist, ist Seats-Tiering natürlich
Reporting-Tiefe oder Exports — erweiterte Analytics, Kohorten-Views oder Datenexporte können in Growth/Scale leben
Integrationen — wenn du mehrere Integrations-Ziele hast, ist Begrenzung auf Kern in Starter vertretbar
Support-Level — Priority Support in Scale ist erwartet; grundlegende Hilfe nicht hinter einer Paywall

Features, die in allen Tiers bleiben sollten:

Kernprodukt-Funktionalität — kritische Features in Starter zu sperren trainiert Kunden, dem Produkt nicht zu vertrauen
Sicherheits-Basis — erstelle keine „sichere Version” des Produkts
Basic Onboarding — wenn du Starter-Nutzern zum Erfolg hilfst, upgraden sie; wenn nicht, churnen sie

Schritt 4: Einen klaren Upgrade-Trigger pro Tier setzen

Jede Plan-Grenze sollte einen offensichtlichen, selbsterklärenden Grund haben aufzusteigen. Das Upgrade sollte sich verdient anfühlen, nicht erzwungen.

Starter → Growth: Nutzungslimit erreicht, oder bereit, das Produkt ernsthaft zu nutzen. In dem Moment, in dem ein Kunde denkt „das ist tatsächlich nützlich für meine echte Arbeit”, sollte er einen Klick von Growth entfernt sein.

Growth → Scale: Teamwachstum, höheres Volumen oder komplexere Operationen. Der Trigger sollte etwas sein, das der Kunde gewählt hat (einen Mitarbeiter einstellen, ein neues Produkt launchen, Nutzung skalieren) — nichts Willkürliches.

Für die Packaging-Struktur, die Upgrade-Trigger sichtbar macht und Entscheidungsmüdigkeit reduziert, deckt der 3-Tier-System-Leitfaden das im Detail ab.

SaaS-Subscription-Preismodelle: Die richtige Struktur wählen

Das 3-Tier-Template oben ist Packaging. Das zugrunde liegende Subscription-Preismodell ist eine separate Wahl — es bestimmt, wie Umsatz mit Kundenwachstum skaliert.

Flat-Rate-Tier-Pricing (was das Template zeigt): fester Preis pro Tier mit definierten Limits. Vorhersagbar für Kunden, leicht zu erklären, gut für Self-Serve. Das häufigste Modell für gebootstrappte und Indie-SaaS.

Nutzungsbasiertes Pricing: Kunden zahlen pro verbrauchter Einheit, entweder mit einer Grundgebühr oder reinem Pay-as-you-go. Stimmt Kosten mit Wert ab, kann aber Abrechnungsangst erzeugen, wenn die Metrik schwer vorherzusagen ist. Funktioniert gut für API-Tools und Infrastrukturprodukte, wo Nutzung sichtbar und schätzbar ist. Stripe Atlas Billing-Guides behandeln die Implementierungsmechanik für nutzungsbasierte Abrechnung.

Per-Seat-Pricing: Preis skaliert mit der Anzahl der Nutzer. Natürlich für Kollaborationstools und Team-Software. Schwächer, wenn ein Power-User den Großteil des Werts generiert.

Hybrid: eine Plangrundgebühr, die ein Nutzungskontingent enthält, plus eine Per-Einheit-Kosten über diesem Schwellenwert. Reduziert Abrechnungsangst bei gleichzeitiger Nutzungsausrichtung. Häufig bei E-Mail-Tools (Basis + per Versand über inkludiertem Limit).

Für die meisten Solo-Gründer- und Kleinteam-SaaS-Produkte, die den Indie-Hacker- und Frühphasen-Markt ansprechen: Flat-Rate-Tier-Pricing ist der reibungsärmste Startpunkt. Es ist vorhersagbar, vergleichbar und unkompliziert zu kommunizieren.

SaaS-Revenue-Modell-Template in JSON

Für Builder, die das Preismodell in Code oder internen Docs dokumentieren wollen — etwas, das tatsächlich eine Billing-Config, Pricing-Seite oder Onboarding-Logik treiben kann:

{
  "pricing_model": {
    "structure": "tiered_flat_rate",
    "primary_metric": "workflows_completed",
    "billing_intervals": ["monthly", "annual"],
    "annual_discount_pct": 20,
    "plans": [
      {
        "id": "starter",
        "name": "Starter",
        "price_monthly": 19,
        "price_annual_per_month": 15,
        "included_units": 200,
        "best_for": "Solo-Gründer / erste Evaluierung",
        "upgrade_trigger": "Nutzungslimit erreicht oder bereit für ernsthafte Nutzung"
      },
      {
        "id": "growth",
        "name": "Growth",
        "price_monthly": 49,
        "price_annual_per_month": 39,
        "included_units": 2000,
        "best_for": "Aktive zahlende Nutzer",
        "upgrade_trigger": "Volumenwachstum oder Team-Kollaboration nötig",
        "highlighted": true
      },
      {
        "id": "scale",
        "name": "Scale",
        "price_monthly": 99,
        "price_annual_per_month": 79,
        "included_units": 10000,
        "best_for": "Teams / intensivere Operationen"
      }
    ],
    "overage_policy": "prompt_to_upgrade",
    "downgrade_policy": "allowed_at_renewal"
  },
  "value_metric": {
    "name": "workflows_completed",
    "visible_in_product": true,
    "usage_warning_threshold_pct": 80
  }
}

Das usage_warning_threshold_pct-Feld zählt: Kunden zu zeigen, dass sie bei 80 % ihres Plans sind, schafft einen natürlichen, druckarmen Upgrade-Moment statt einer plötzlichen Wand.

NoNoiseMetrics als Live-Beispiel

NoNoiseMetrics nutzt dieselbe 3-Tier-Struktur wie oben beschrieben, mit verbundenen Stripe-Accounts als primärer Wertmetrik:

Plan	Preis	Stripe-Accounts	Für wen
Free	0 €/Mo	1	Solo-Gründer unter 10K € MRR
Indie	19 €/Mo	3	Aktive Indie-SaaS-Produkte
Pro	49 €/Mo	Unbegrenzt	Multi-Produkt-Portfolios und Teams

Der Upgrade-Trigger von Free zu Indie ist das Hinzufügen eines zweiten Stripe-Accounts — natürlich für Gründer, die ein zweites Produkt launchen oder Umgebungen trennen wollen. Der Trigger von Indie zu Pro ist, mehr als 3 Accounts zu brauchen — was passiert, wenn das Produkt gut genug funktioniert, um zu expandieren.

Lifetime Access bei 299 € sitzt außerhalb der wiederkehrenden Struktur und erfasst eine spezifische Käuferpsychologie: Gründer, die Eigentum gegenüber Subscription bevorzugen und bereit sind, vorab für permanenten Zugang zu zahlen.

SaaStrs Pricing-Research bestätigt, dass ein sichtbarer, produktnativer Upgrade-Trigger signifikant besser konvertiert als abstrakte Plan-Vergleiche — was genau das ist, was die Accounts-Connected-Metrik hier erreicht.

Häufige Preismodell-Fehler

Zu viele Pläne. Sechs Tiers erzeugt Vergleichsparalyse. Drei Tiers deckt die volle Bandbreite von Kunden — Einstieg, aktiv, Power — ab, ohne Besucher zu bitten, mehr Optionen zu evaluieren, als sie im Arbeitsgedächtnis halten können.

Keine klare Wertmetrik. Wenn Kunden nicht erkennen können, was sich zwischen Starter und Growth ändert, ohne eine Vergleichstabelle zu lesen, fehlt dem Preismodell ein Rückgrat. Eine klare Einheit der Progression behebt das.

Feature-Suppe statt Limit-Progression. Vierzig Häkchen auf einer Preistabelle verschleiern den Hauptgrund zu upgraden. Mit der Metrik führen; Feature-Unterschiede als sekundären Kontext hinzufügen.

Starter als Bestrafungs-Tier machen. Wenn der niedrigste Plan keinen echten Produktwert demonstrieren kann, haben Kunden keinen Grund, dem Upgrade-Pfad zu vertrauen. Starter sollte Wert schaffen. Growth sollte ihn erweitern.

Upgrade-Trigger, die sich strafend anfühlen. Ein Limit, das willkürlich oder unfair niedrig wirkt, trainiert Kunden, Pricing zu resenten statt in es hineinzuwachsen. Die besten Upgrades fühlen sich verdient an.

Keine In-Product-Nutzungssichtbarkeit. Kunden, die ihre Nutzung gegen ihr Plan-Limit sehen können, upgraden proaktiv. Kunden, die unerwartet ein Limit entdecken, werden verärgert. Das ist eine Engineering-Investition, die sich in Conversion auszahlt.

Vom Template zur Pricing-Seite

Das Modell treibt die Seite. Sobald das Modell steht, ist die Seite selbst relativ mechanisch.

Headline: für wen es ist und der primäre Nutzen. Produktspezifisch halten, nicht generisch („einfach” und „mächtig” sind keine Nutzen).

Pricing-Grid: Plan-Namen, Monatspreis, primäres Limit, 3–5 Feature-Unterschiede, Jahresabrechnungsoption, ein hervorgehobener Standard-Plan.

Upgrade-Logik-Copy: eine Zeile pro Übergang. „Wechsel zu Growth, wenn du mehr als 200 Workflows/Monat brauchst.” Nicht vager als das.

FAQ oder Trust-Block: was zum Nutzungslimit zählt, was passiert wenn du es erreichst, ob Downgrade verfügbar ist, und was die Jahresabrechnungsbedingungen sind. Diese vier Fragen machen den Großteil der Pricing-bezogenen Support-Tickets in früher Phase aus.

CTA-Copy auf jedem Plan: Verben, keine Substantive. „Kostenlos starten” schlägt „Kostenloser Plan”. „Loslegen” auf Growth. „Kontaktiere uns” nur wenn Scale wirklich Enterprise ist — wenn es Self-Serve ist, gib ihm einen echten CTA.

FAQ

Was ist ein SaaS-Preismodell-Template?

Ein SaaS-Preismodell-Template ist eine wiederholbare Struktur dafür, wie ein Subscription-Produkt bepreist wird — seine Pläne, die Wertmetrik, die die Tier-Progression treibt, die Limits, die jeden Plan definieren, und die Upgrade-Logik. Es ist die wirtschaftliche Architektur hinter der Pricing-Seite, nicht nur das visuelle Layout.

Wie viele Pricing-Tiers sollte ein SaaS-Produkt haben?

Drei Tiers ist der Standard für Self-Serve-SaaS: ein Low-Commitment-Einstiegs-Tier, ein Standard-Growth-Tier und ein höheres Nutzungs- oder Team-Tier. Weniger als drei begrenzt die Fähigkeit, verschiedene Segmente zu erfassen; mehr als drei erzeugt Vergleichsmüdigkeit.

Was ist das beste Subscription-Preismodell für SaaS?

Für die meisten gebootstrappten und Indie-SaaS-Produkte ist Flat-Rate-Tier-Pricing — fester Preis pro Plan mit definiertem Nutzungslimit — der reibungsärmste Startpunkt. Nutzungsbasiertes Pricing funktioniert gut für API- und Infrastrukturprodukte, wo Kunden ihren Verbrauch schätzen können. Per-Seat-Pricing funktioniert am besten, wenn Kollaboration der Kernwerttreiber ist.

Was sollte sich zwischen Pricing-Tiers ändern?

Primär das Wertmetrik-Limit (mehr von dem, wofür Kunden zahlen, wenn sie mehr Wert bekommen), sekundär eine kleine Anzahl von Feature-Unterschieden. Der Hauptgrund zu upgraden sollte in einem Satz klar sein.

Was ist ein SaaS-Revenue-Modell-Template?

Ein SaaS-Revenue-Modell-Template dokumentiert, wie wiederkehrender Umsatz strukturiert ist — Pricing-Tiers, die Wertmetrik, Abrechnungsintervalle (monatlich vs. jährlich), Überschreitungsrichtlinie und Upgrade-Trigger. Es ist die zugrunde liegende Logik, die eine Pricing-Seite Kunden präsentiert und die ein Billing-System implementiert. Die JSON-Struktur in diesem Artikel ist ein praktischer Startpunkt.

Was sollte man auf einer Pricing-Seite vermeiden?

Vage Plan-Namen (Basic, Pro, Enterprise, wenn du gar kein Enterprise verkaufst), unerklärte Limits, Upgrade-Trigger, die sich willkürlich anfühlen, und Pricing-Tabellen mit zu vielen Häkchen, die die primäre Progression verschleiern. Das Ziel ist, dass ein neuer Besucher „wofür zahle ich und wann sollte ich mehr zahlen” in unter 30 Sekunden verstehen sollte.

Nachdem du deinen Preis gesetzt hast, musst du wissen, ob er funktioniert. NoNoiseMetrics trackt ARPU und MRR nach Plan automatisch. Stripe verbinden →

Free Tool
Try the SaaS Pricing Calculator →
Interactive calculator — no signup required.