Die These, über die sich erfahrene Gründer streiten: Nutzungsbasierte Preise sind bei AI-SaaS fast immer ein Fehler – nicht weil Kunden sie hassen, sondern weil sie deine Marge an die Volatilität deiner Inference-Kosten koppeln, obwohl dein Value-Delivery-Mechanismus damit gar nichts zu tun hat. Die Gegenposition kennt jeder: "Aber wir zahlen ja auch pro Token, also muss der Kunde auch pro Nutzung zahlen." Das klingt fair. Es ist trotzdem falsch, und zwar aus einem strukturellen Grund, den die meisten Teams erst nach zwei bis drei Preiserhöhungsrunden verstehen.
Der Denkfehler: Kosten-Pass-Through ist keine Preisstrategie, sondern eine Buchhaltungsentscheidung. Wenn du deine Marge definierst als "Preis minus variable Inference-Kosten", hast du dein Geschäftsmodell an die Kostenkurve von OpenAI, Anthropic oder deiner eigenen GPU-Auslastung gekettet. Steigt dein Cache-Hit-Rate, steigt deine Marge scheinbar grundlos. Sinkt sie, sieht es aus wie ein Produktproblem, obwohl es ein reines Infrastrukturproblem ist. Kunden merken diese Volatilität nicht – aber du spürst sie in jedem Board-Meeting.
Das Rechenbeispiel
Nehmen wir ein reales Muster: ein AI-SaaS-Tool für automatisierte Vertragsanalyse, verkauft an mittelständische Kanzleien. Modellarchitektur: GPT-4-Klasse-Modell für die Extraktion, kleineres Modell für Klassifizierung, Embedding-Suche für Retrieval.
Ausgangslage bei Launch:
- Preis: 0,08 € pro analysiertem Dokument
- Durchschnittliche Kosten pro Dokument: 0,019 € (Inference + Retrieval + Storage)
- Bruttomarge: ca. 76 %
Das sieht gesund aus. Jetzt skaliert das Produkt. Nach sechs Monaten:
- Durchschnittliche Dokumentlänge steigt um 40 %, weil die größten Kunden (die profitabelsten Logos) komplexere Verträge hochladen
- Retry-Rate wegen Halluzinationen bei Randfällen: 12 % aller Requests laufen doppelt
- Ein neues Feature (Vergleich mehrerer Vertragsversionen) verdreifacht den Context-Window-Bedarf für 18 % der Nutzung
Neue Kostenrechnung pro Dokument: 0,051 €. Der Preis ist gleich geblieben, weil niemand ihn angefasst hat – Preisänderungen sind unangenehm und die Sales-Pipeline war zu voll, um das Thema anzufassen. Bruttomarge: 36 %.
Das ist der Punkt, an dem Teams typischerweise zwei falsche Reflexe haben. Erster Reflex: Modell downgraden, um Kosten zu senken. Ergebnis: Qualität sinkt, Churn bei den margenstärksten Enterprise-Kunden steigt, weil genau die die komplexen Fälle brauchten, für die das teure Modell überhaupt existierte. Zweiter Reflex: Preis pro Dokument erhöhen. Ergebnis: Kunden mit niedrigem Dokumentvolumen aber hoher Kontaktfrequenz (die eigentlich profitabel waren) beschweren sich am lautesten, weil sie die Preiserhöhung pro Einheit am stärksten spüren, obwohl sie in absoluten Zahlen am wenigsten zahlen.
Die eigentliche Lösung war eine dritte Option, die fast niemand zuerst in Betracht zieht: Die Preisachse vom Kostentreiber entkoppeln. Statt pro Dokument abzurechnen, wurde auf ein Tiering nach Outcome-Metrik umgestellt – "Anzahl abgeschlossener Vertragsprüfungen pro Monat" in Bändern, mit einem Soft-Cap für Ausreißer-Nutzung, die separat nachverhandelt wird. Die Kostenkurve bleibt volatil. Die Preiskurve wird stufig und vorhersagbar. Die Marge schwankt dann innerhalb eines Bandes von vielleicht 10 Prozentpunkten statt 40.
Der Failure Mode, den fast jeder übersieht
Der eigentliche Fehler passiert nicht bei der ersten Preisgestaltung – der ist fast immer vernünftig, weil er unter Unsicherheit mit wenig Daten getroffen wird. Der Fehler passiert bei der Nicht-Reaktion auf Kostendrift.
AI-Infrastrukturkosten verhalten sich nicht wie klassische Cloud-Kosten. Bei klassischem SaaS sinken Infrastrukturkosten pro Nutzer tendenziell mit der Zeit (bessere Caching-Strategien, Skaleneffekte, reifere Codebasis). Bei AI-SaaS ist das Gegenteil oft der Fall: Nutzung wird komplexer, weil die profitabelsten Kunden die anspruchsvollsten Use Cases bringen, Modelle werden zwar pro Token billiger, aber Kontext-Fenster und Multi-Step-Agentic-Workflows wachsen schneller als die Preissenkung der Anbieter. Das Ergebnis ist eine leise, sich langsam verschlechternde Unit Economics, die in keinem Dashboard rot aufleuchtet, weil Umsatz und Kundenzahl gleichzeitig wachsen. Wachstum maskiert Margenerosion – das ist der eigentliche Failure Mode.
Die Teams, die das übersehen, checken ihre Kohorten-Marge nicht granular genug. Sie schauen auf Blended Gross Margin über alle Kunden, während die Marge einzelner High-Usage-Kohorten bereits negativ ist, querfinanziert von neuen Kunden mit geringer Nutzung. Das funktioniert so lange, wie das Wachstum neuer, margenstarker Kunden schneller ist als das Wachstum der margenschwachen Bestandsnutzung. Sobald sich das umdreht – typischerweise, wenn der Sales-Funnel sättigt und die Bestandskunden ihre Nutzung intensivieren, weil sie das Produkt in mehr Workflows integrieren – kippt die Blended Margin plötzlich und wirkt wie ein Schockereignis, obwohl sie sich seit Monaten angekündigt hatte.
Die Gegenmaßnahme ist unspektakulär, aber wirksam: Kostentransparenz pro Kohorte, nicht pro Gesamtunternehmen, verbunden mit einer Preisarchitektur, die Nutzungsspitzen abfedert, bevor sie die Marge auffressen. Das bedeutet konkret: Preisbänder mit klaren Fair-Use-Grenzen, Overage-Gebühren, die tatsächlich kostendeckend kalibriert sind (nicht symbolisch), und eine vierteljährliche Repricing-Routine statt einer "wir fassen das nicht an, solange niemand sich beschwert"-Haltung.
Wer diese Mechanik systematisch durchrechnen will – inklusive der Kohortenmodelle, Tiering-Formeln und der Repricing-Trigger, die ich oben nur skizziert habe – hat mir das in einem kompakten Field Memo zusammengefasst, das genau auf dieses Problem
Top comments (0)