Eine Azure-Rechnung von 40.000 € im Monat sagt Ihnen wenig. Erst wenn Sie wissen, was davon auf welchen Kunden, welches Produkt oder welche Transaktion entfällt, wird aus einer Zahl eine Entscheidungsgrundlage.
Series-B-SaaS-Unternehmen kennen das Muster: Der Board-Deck verlangt Unit Economics, aber die Zahlen, die geliefert werden können, stoppen bei Total Cloud Spend. Die Lücke dazwischen ist kein Reporting-Problem — sie ist ein Cost-Allocation-Problem, das ohne saubere Datenbasis nicht zu schließen ist.
Unit Economics verknüpft Kosten mit einer Geschäftseinheit — einem Kunden, einer Transaktion, einem aktiven Nutzer. Der Unterschied zu reinem Cost Monitoring ist die Bezugsgröße: Statt "Wie viel geben wir aus?" fragt Unit Economics "Wie viel kostet uns eine Einheit unseres Geschäfts, und verändert sich das mit Skalierung in die richtige Richtung?"
Für ein SaaS-Unternehmen ist das keine akademische Übung. Es ist die einzige verlässliche Methode, um zu beantworten, ob ein wachsender Kundenstamm auch wachsende Marge bedeutet — oder ob Sie mit jedem neuen Kunden mehr Geld verlieren, ohne es zu merken.
Einige Metriken decken die meisten Fälle ab. Keine davon ist kompliziert zu berechnen — vorausgesetzt, die zugrunde liegende Cost Allocation stimmt.
| Metrik | Formel | Aussage |
|---|---|---|
| Cost per Customer | Total SaaS Cost / Anzahl aktiver Kunden | Steigt dieser Wert, verlieren Sie Marge je Kunde |
| Cost per Transaction | SaaS-TCO / Anzahl Transaktionen | Kernmetrik für transaktionale Plattformen |
| Cost per Active User | Gesamtkosten / aktive Nutzer | Inaktive User verzerren diesen Wert nach oben |
| License Utilisation Rate | (Assigned / Purchased Licenses) × 100 | Unter 80 % deutet auf Over-Subscribing hin |
Ein einfaches Rechenbeispiel zur Einordnung: Eine Function App kostet 100 € im Monat und bedient 100 Kunden gleichmäßig. Cost per Customer liegt bei 1 €. Trivial auf dieser Stufe — aber genau dieses Prinzip, konsequent über die gesamte Azure-Umgebung angewendet, ist der Unterschied zwischen Kostenkontrolle und Kosten-Bauchgefühl.
Das Beispiel oben funktioniert, weil alle 100 Kunden die Ressource gleich nutzen. In der Realität tun sie das nicht. Ein Enterprise-Kunde verursacht über API-Calls, Storage und Compute-Zeit ein Vielfaches der Last eines kleinen Kunden — auf derselben geteilten Infrastruktur. Even-Spread-Allocation (Kosten gleich verteilt über alle Kunden) ist in diesem Fall systematisch falsch und führt zu Fehlentscheidungen bei Pricing und Kundenfokus.
Die Lösung liegt in einem stufenweisen Vorgehen, das vom groben Schätzwert zu präzisen, verbrauchsbasierten Metriken führt:
Wichtig: Dieser letzte Schritt ist kein FinOps-Projekt im engeren Sinne, sondern eine Engineering-Voraussetzung. FinOps Practitioner können die Notwendigkeit aufzeigen und das Framework liefern — implementiert wird das Metering von Engineering.
Der State of FinOps Report zeigt für EMEA ein klares Muster: FinOps-Teams berichten überwiegend an CTO oder CIO, aber der Druck auf belastbare Unit Economics kommt strukturell von Finance und Board. Für ein Series-B-Unternehmen heißt das konkret: Die Frage "Was kostet uns Kunde X?" wird im nächsten Board-Meeting gestellt, unabhängig davon, ob die Datenbasis dafür bereitsteht.
Ein CFO erwartet dabei nicht nur eine Zahl, sondern Konsistenz über Zeit. Eine einmalige Cost-per-Customer-Berechnung für ein Board-Deck ist ein Reporting-Artefakt. Ein funktionierendes Unit-Economics-Framework liefert diese Zahl jeden Monat automatisiert, ohne dass jemand erneut tagelang CSV-Exporte durchforstet.
Viele interne Versuche scheitern, weil sie bei der Kennzahl ansetzen, bevor die Datenbasis steht. Ein Cost-per-Customer-Dashboard ist nur so genau wie die Tagging-Coverage darunter. Wenn 70 % des Spends keinem Kunden zugeordnet werden können, ist jede Unit-Economics-Zahl, die daraus berechnet wird, eine Schätzung mit großer Unsicherheit — präsentiert mit der Präzision einer exakten Kennzahl. Das ist gefährlicher als gar keine Zahl zu haben, weil es falsches Vertrauen erzeugt.
Der kostenlose Health Check zeigt Ihnen, welcher Anteil Ihres Azure-Spends heute keinem Kunden zugeordnet werden kann — als Grundlage für belastbare Unit Economics.
Health Check anfragen →Bevor Unit Economics belastbar werden, muss die Frage geklärt sein, warum der Allocation Gap überhaupt entsteht und wie groß er typischerweise ist. Genau das behandelt der nächste Artikel.