KI-Pricing · 6 Min. Lesezeit
Outcome-based Pricing: wann sich ein Preis pro Ergebnis lohnt
Das Wichtigste in Kürze
- Outcome-based Pricing, also ein Preis pro Ergebnis, lohnt sich für Software nur bei messbaren, zurechenbaren, wertvollen und häufigen Ergebnissen. Sonst passen Hybrid oder Credits besser.
- Bei Outcome-based Pricing für Software steht von Anfang an fest, was als gelöst zählt. Sonst zahlt der Kunde auch, wo ein Mensch eingreifen musste.
- Mindestabnahme, Kostenobergrenze, ein paralleler Verbrauchspreis und eine klar definierte Einheit machen Outcome-based Pricing für Softwareanbieter und Kunden planbar.
- Laut SaaS & AI Pricing Report von hy setzen nur 8 % der Software- und KI-Anbieter bei KI-Agenten heute oder künftig auf Outcome-based Pricing.
Outcome-based Pricing heißt, euer Kunde zahlt nur für ein erreichtes Ergebnis, etwa eine gelöste Supportanfrage, eine besetzte Stelle oder eine zurückgeholte Zahlung. Für Softwareanbieter lohnt sich das, wenn das Ergebnis eindeutig messbar ist, eurem Produkt klar zugerechnet werden kann und so oft vorkommt, dass sich Ausreißer ausgleichen. Für die meisten Produkte ist ein Ergebnisanteil in einem hybriden Modell sicherer als ein reiner Preis pro Ergebnis.
Viel diskutiert, selten umgesetzt
Für unseren SaaS & AI Pricing Report 2027 haben wir 153 Software- und KI-Anbieter online befragt. Als künftige Hauptmetrik gewinnt das Ergebnis dort 20 Prozentpunkte, mehr als jede andere Metrik. Bei Agenten setzen aber nur 8 % der Befragten heute oder künftig auf ergebnisbasierte Preise. 31 % packen Agenten in bestehende Pakete, weitere 31 % sind unsicher. Wir erwarten deshalb, dass sich Preise pro Agent, Task oder Workflow deutlich schneller durchsetzen als Preise pro Ergebnis.

Auf unserem Panel habe ich es so zusammengefasst: „wird ganz viel über Outcome-based Pricing geredet, aber keiner macht's“. Oliver Pabst von Redalpine sieht darin nur einen kleinen Teil des Markts: „das wird ein kleiner Teil sein, weil das heißt wirklich eine echte Differenzierung“. Seine Hypothese habe ich einmal so wiedergegeben: maximal 5 % der Tech-Unternehmen schaffen Outcome-based Pricing, wahrscheinlich sogar weniger.
In unseren Interviews und Projekten kommt das Thema trotzdem oft sehr früh auf den Tisch. Sobald wir prüfen, ob es technisch machbar ist und ob die Kunden nicht lieber Stabilität wollen, verfliegt der Glanz meist schnell.
Vier Bedingungen, alle müssen erfüllt sein
Wir nennen drei Bedingungen: Das Ergebnis ist klar messbar, der Anteil der Software daran ist nachvollziehbar, und beide Seiten sehen den wirtschaftlichen Wert. Ich ergänze eine vierte: Ihr braucht einen sehr spitzen Anwendungsfall, der sich oft wiederholt, weil ihr euch am Ende nicht darüber streiten wollt, ob das Problem gelöst ist. Malte Kosub von Parloa sieht es genauso: Outcome-based Pricing ist für ihn „ein sehr relevanter Pricing-Mechanismus für Anbieter, die ein sehr repetitives und sehr klare Value Proposition haben“.
| Bedingung | Prüffrage | Passt gut | Passt schlecht |
|---|---|---|---|
| Messbar | Gibt es ein eindeutiges Ja oder Nein, ohne Diskussion? | Rückbuchung gewonnen, entschieden von Visa und Mastercard | Bessere Entscheidungen im Team |
| Zurechenbar | Ist das Ergebnis ohne eure Software nicht passiert? | Agent beantwortet die Anfrage abschließend | Umsatzplus nach einer Vertriebsschulung |
| Wert für beide | Gewinnt der Ansprechpartner beim Kunden mit, wenn ihr verdient? | Besetzte Stelle, bezahlt erst bei Vertragsunterschrift | Einkaufssoftware, die sich an Einsparungen beteiligt |
| Häufig | Gleichen sich lange und kurze Fälle über den Monat aus? | Tausende Supportanfragen | Wenige große Projekte im Jahr |
Die dritte Zeile ist leicht zu übersehen. Fabian Heinrich von Mercanis beschreibt den Konflikt so: Im Einkauf hängt der Bonus eines Mitarbeiters an den Einsparungen. Beansprucht die Software einen Anteil davon, gibt der Käufer einen Teil seines eigenen Erfolgs ab. Mercanis versteht sich deshalb lieber als Anbieter, der den Käufer glänzen lässt.
Was in der Praxis schiefgeht
Das bekannteste Beispiel ist Intercom. Fin startete mit 0,99 US-Dollar pro Ergebnis und ist heute ein Hybrid aus Seats und einem Preis pro gelöster Anfrage, weil die „angenommene Lösung“ auch dann kostete, wenn ein Mensch zu Recht eingriff. Die Lehre daraus: Die Regeln, was als gelöst zählt, gehören von Anfang an ins Modell. Intercom hat sie inzwischen öffentlich aufgeschrieben. Eine Lösung zählt, wenn der Kunde nach Fins letzter Antwort bestätigt, dass sie geholfen hat, oder das Gespräch verlässt, ohne weitere Hilfe anzufragen. Kommt er später ins selbe Gespräch zurück, weil er doch Hilfe braucht, wird die Lösung wieder abgezogen. Andere folgen: Zendesk berechnet seit Mai 2026 1,50 US-Dollar pro gelöster Anfrage mit drei klar definierten Stufen. Die ganze Geschichte von Intercom und das Beispiel Chargeflow gehören zur Frage, wie man KI-Agenten bepreist.


Arne Wolter von Appinio bringt das Grundproblem auf eine Frage: „Das Problem ist zu definieren, was ist denn jetzt ein Erfolg und wie bepreise ich den?“ Dazu kommt die Streuung. Malte Kosub beschreibt, dass ein Gespräch in 40 Sekunden gelöst sein kann und ein anderes in zwölf Minuten. Ein fester Preis pro Lösung muss dieses Risiko einpreisen, und am Ende verliert eine Seite.
Vier Bausteine, die einen Ergebnispreis absichern
Ein Preis pro Ergebnis allein reicht selten. Vier Bausteine bringen die Planbarkeit zurück:
- Mindestabnahme. Bleibt das Ergebnis aus, fehlt euch der Umsatz. Eine Mindestmenge statt einer Grundgebühr schützt euch, darüber wird nach Ergebnis abgerechnet. Intercom verlangt rund 50 Lösungen im Monat.
- Kostenobergrenze. Variable Kosten ohne Deckel kann der Kunde nicht budgetieren. Ein Deckel schützt ihn, ihr liefert darüber hinaus weiter.
- Paralleler Verbrauchspfad. Was sich nicht klar als Ergebnis definieren lässt, bliebe unbezahlt. Ein zweiter Preis nach Verbrauch läuft daneben.
- Definitionsebene. Statt am Preis dreht ihr an der Einheit: Eine enge Definition von „gelöst“ schützt den Kunden, eine weite schützt euch.

Rechenbeispiel: ein Preis pro gelöster Anfrage
Ein Supportmitarbeiter kostet ein Unternehmen 30 € pro Stunde und löst vier Anfragen pro Stunde, also 7,50 € pro Anfrage. Ein Agent, der Anfragen abschließend löst, nimmt sich 20 % dieses Werts: 1,50 € pro gelöster Anfrage. So habe ich die Logik im Podcast skizziert: Die Arbeitskosten pro Fall sind der Maßstab, ein Anteil davon ist der Preis.
Abgesichert sieht das Angebot so aus: mindestens 1.000 gelöste Anfragen im Monat, also 1.500 € Mindestumsatz für euch. Ein Deckel bei 6.000 € im Monat für den Kunden. Und 0,20 € für jede Anfrage, die der Agent bearbeitet und an einen Menschen weitergibt, als paralleler Verbrauchspfad. Löst der Agent 3.000 Anfragen und gibt 1.000 weiter, zahlt der Kunde 4.700 €. Die 3.000 gelösten Anfragen hätten mit Personal 22.500 € gekostet. Nach Abzug der 4.700 € bleiben dem Kunden 17.800 €, also rund 80 % des Werts. Die Zahlen sind ausgedacht, die Bausteine stammen aus unserem Report.

Was ihr am Montag tun könnt
Schreibt eure drei wichtigsten Anwendungsfälle auf und geht für jeden die vier Zeilen der Tabelle durch. Fällt ein Fall bei einer Zeile durch, gehört er in ein hybrides Modell aus Grundgebühr plus Nutzung oder in ein Modell mit Credits. Besteht ein Fall alle vier, rechnet ihn wie oben durch und testet ihn mit wenigen Kunden, bevor er auf die Preisseite kommt. In unserem Vorgehen ist das die Frage nach der Preismetrik, die vor jedem Preisniveau beantwortet sein muss.
Fazit: Erst die Definition, dann der Preis
Ein Preis pro Ergebnis lohnt sich nur, wenn das Ergebnis eindeutig messbar, eurer Software zurechenbar, für beide Seiten wertvoll und häufig ist. Das trifft auf wenige Anwendungsfälle zu, etwa Support, Rückbuchungen oder Recruiting. Für alle anderen ist ein Ergebnisanteil mit Mindestabnahme, Kostendeckel und parallelem Verbrauchspfad sicherer als ein reiner Preis pro Ergebnis.
Wie euer heutiges Preismodell von außen wirkt, zeigt der kostenlose Pricing-Audit auf pricing-friends.de in rund einer Minute. Er liest eure Preisseite live und prüft Preismodell, Paketierung und Preispunkte nach dem Vorgehen, das die hy Consulting Group in mehr als 600 Pricing-Projekten entwickelt hat.
Quellen
- SaaS & AI Pricing Report 2027 von hy, S. 32, 47, 55, 56, 57, 58, 59, 83
- Intercom: Fin outcomes, Definition einer Resolution, abgerufen am 17.10.2026
- Pricing Friends, Folge 84: KI und Pricing mit Dr. Oliver Pabst: Warum gelingt echtes Value-Based Pricing nur 5 % der Softwareanbieter?
- Pricing Friends, Folge 89: AI Agents und Pricing mit Malte Kosub: Welches Preismodell funktioniert wirklich für KI-Telefonassistenten?
- Pricing Friends, Folge 99: Sonderfolge: SaaS-Pricing, AI und die Zukunft der Preismodelle, Dr. Sebastian Voigt bei Julius Göllner
- Pricing Friends, Folge 143: SaaS- und AI-Pricing mit Arne Wolter: Wird KI zur Commodity?
- Pricing Friends, Folge 144: SaaS & AI Pricing Report mit Arne Wolter, Benedikt Böringer, Felix Rahlmeyer, Melanie Riebel & Norman Nielsen: Wie verändert KI das Pricing von morgen?