Die meisten Pricing-Debatten im SaaS-Umfeld setzen an der falschen Stelle an.
Teams streiten über Tarifstufen. Sie zerbrechen sich den Kopf über Seats versus Nutzungslimits. Sie schauen auf den Wettbewerb. Sie befragen Kunden, was sie zu zahlen bereit wären. Dann geht das Modell live, die Margen schrumpfen – und niemand versteht, warum.
Der Grund ist einfach: Das Pricing-Modell beruht auf Kostenschätzungen, nicht auf der Kostenrealität. Und Schätzungen altern schlecht. Das offene Geheimnis der SaaS-Unit-Economics
Wenn ein VP of Product oder ein Pricing-Berater ein Modell für einen neuen Tarif entwickelt, arbeitet er rückwärts – ausgehend von Annahmen. Infrastrukturkosten werden näherungsweise angesetzt. Der Verbrauch geteilter Ressourcen wird gemittelt. Die KI-Nutzung wird geschätzt. Die Varianz zwischen Kunden wird auf eine einzige Kennzahl geglättet.
Das Modell sagt: Ein Kunde im Growth-Plan sollte 80 $/Monat an Servicekosten verursachen. Verfolgt man die tatsächlichen Kosten durch die reale Infrastruktur zurück, liegen sie für Ihre schwersten Accounts eher bei 190 $ – und für die leichtesten bei 12 $. Der Durchschnitt sieht gesund aus. Der Long Tail bringt Sie klammheimlich um.
Das ist kein Problem der Pricing-Strategie. Es ist ein Datenproblem. Genauer gesagt: das Problem eines fehlenden Datensatzes.
Warum diese Lücke existiert
Klassische Cloud-Cost-Tools wurden für FinOps-Teams gebaut, die Infrastrukturbudgets verwalten. Sie lesen Billing-Exports, parsen CloudTrail-Logs und ordnen Ausgaben nach Account, Region oder Tag. Nützlich für Engineering-Teams, die EC2-Instanzen per Right-Sizing optimieren wollen.
Fürs Pricing bringt das nichts.
Pricing-Teams brauchen Kosten anders geschnitten: pro Kunde, pro Produktlinie, pro Feature, pro der Nutzungseinheit, die sie tatsächlich abrechnen. Ein Billing-Export weiß nicht, welcher Kunde welchen Workload ausgelöst hat. Er weiß nicht, dass ein einzelner Enterprise-Account Scan-Jobs fährt, die 40-mal mehr Compute verbrauchen als alle anderen im selben Plan. Er weiß nicht, dass Ihr KI-Feature bei Power-Usern dreimal so viel kostet wie bei Gelegenheitsnutzern.
Der Billing-Layer hat diesen Kontext nicht. Hatte er nie. Er wurde gebaut, damit Cloud-Provider Ihnen sagen können, wie viel Sie zahlen – nicht, damit Sie wissen, was es kostet, den Workload jedes einzelnen Kunden zu betreiben.
Um diese Frage zu beantworten, brauchen Sie eine völlig andere Datenquelle.
Was sich mit Runtime-Daten ändert
Wenn Sie Ihre Infrastruktur auf Basis von Runtime-Daten instrumentieren – also den tatsächlichen Traffic, die tatsächlichen Service-Calls und den tatsächlichen Ressourcenverbrauch in Echtzeit erfassen –, sieht das Kostenbild völlig anders aus.
Sie sehen, welche Kunden welche Workloads verursachen. Sie können eine Datenbankabfrage bis zu dem Feature zurückverfolgen, das sie ausgelöst hat, und von dort bis zu dem Kunden, der es genutzt hat. Sie können geteilte Ressourcen wie Kafka oder Elasticsearch beobachten und nachvollziehen, welche Tenants wie viel verbrauchen – ohne dass Engineers irgendetwas taggen müssen.
Das ist keine theoretische Fähigkeit. Es gibt sie heute schon, produktiv im Einsatz bei Unternehmen, die genau diese Analyse fahren.
Was finden diese Unternehmen heraus?
Meistens, dass ihr mentales Modell der Kostenverteilung falsch ist. Die Spanne zwischen den leichtesten und schwersten Konsumenten ist breiter als erwartet. Ein kleiner Prozentsatz der Accounts – meist Enterprise, meist mitten im Tarifportfolio – konsumiert in einem Ausmaß, das ihren ARR wie einen Rabatt aussehen lässt.
Ein Unternehmen entdeckte 360 Accounts, bei denen die Cost-to-Serve den Umsatz überstieg. Gesamtrisiko: 1,3 Mio. $ jährliche Verluste – unsichtbar, bis Runtime-Attribution die Kosten den Kunden zuordnete. Diese Verluste steckten nicht in Accounts, die ohnehin als unprofitabel galten. Sie versteckten sich in Tarifen, die nach gesundem ARR aussahen.
Das KI-Pricing-Problem ist ein Vorgeschmack auf das, was kommt
Dieser Margendruck wird nicht besser, sondern schlimmer.
KI-Features verändern die Kostenstruktur eines SaaS-Produkts auf eine Weise, die weder Seat-basiertes noch nutzungsbasiertes Pricing sauber abbildet. Ein KI-Agent, der einen mehrstufigen Workflow ausführt, verbraucht keine feste Menge an Compute. Er verbraucht abhängig von Komplexität, Input-Größe, Anzahl der Tool-Aufrufe und der Menge an Tokens, die dabei verbrannt werden. Zwei Kunden, die dasselbe KI-Feature nutzen, können 10-fach unterschiedliche Kostenprofile haben.
Wenn Ihr Pricing-Modell beide gleich behandelt, subventioniert einer den anderen.
Die Unternehmen, die KI-Pricing richtig hinbekommen werden, sind die, die Token-Verbrauch, Agent-Aktionen und Tool-Call-Volumen auf Kundenebene sehen – und daraus ein Pricing bauen, das dieser Realität entspricht. Nicht pro Seat. Nicht pro tausend Requests. Sondern Pricing-Strukturen, die die tatsächlichen Kostentreiber im Produkt abbilden.
Das erfordert Runtime-Daten. Anders ist diese Granularität nicht zu bekommen.
Was das für Pricing-Teams eröffnet
Sie erkennen margen-negative Segmente, bevor sie in einer Board-Präsentation auftauchen. Sie sehen, welche Tarifstufen die größte Kostenvarianz aufweisen, und können Nutzungslimits oder Add-ons entwerfen, die sich am tatsächlichen Verbrauch orientieren. Sie können die Margenwirkung eines neuen Features testen, bevor Sie es bepreisen und ausrollen – auf Basis realer Daten statt modellierter Annahmen.
Sie können außerdem Pricing-Modelle bauen, die vorher nicht möglich waren. Consumption-based Pricing ist kein Glücksspiel mehr, wenn Sie genau wissen, was jede Verbrauchseinheit in der Bereitstellung kostet. Value-based Pricing wird belastbar, wenn Sie belegen können, was Sie tatsächlich ausgeben, um das Ergebnis zu erzeugen, für das Sie Geld verlangen.
Die Agentic-Ära macht das noch dringlicher. Wenn Sie 250 $ pro erledigter Aufgabe verlangen, müssen Sie wissen, ob diese Aufgabe 80 $ oder 380 $ in der Ausführung gekostet hat. Die Antwort ändert alles: welche Workflows Sie höher bepreisen, welche Sie umbauen, welche Kunden zum aktuellen Preis überhaupt profitabel sind. Ohne Runtime-Daten fliegen Sie bei Ihren wichtigsten Pricing-Entscheidungen blind.
Sie können die Frage beantworten, die Pricing-Teams schon immer beantworten mussten, aber selten konnten: Was kostet es tatsächlich, diesem Kunden diesen Wert zu liefern?
Sobald Sie diese Antwort haben, hört Pricing auf, Rätselraten zu sein. Es wird zum Wettbewerbsvorteil.
Die Frage für Ihr nächstes Pricing-Review
Bevor Sie über Tarifstufen oder Feature-Gating diskutieren, stellen Sie eine vorgelagerte Frage: Wissen wir eigentlich, was es kostet, jeden einzelnen Kunden, jeden Plan, jedes Feature zu bedienen?
Wenn die Antwort aus Spreadsheets und Schätzungen besteht, steht das Pricing-Modell auf einem Fundament, das mit dem Wachstum des Produkts nicht mithalten wird.
Beginnen Sie mit der Kostenrealität. Alles andere folgt daraus.
Attribute™ ordnet Cloud- und KI-Infrastrukturkosten den Kunden, Produkten und Features zu – auf Basis von Runtime-Daten, ganz ohne Tagging. Sehen Sie, wie es für Pricing-Teams funktioniert.