SaaS-ROI messen: 90 Tage nach dem Kauf
Der CFO hatte beim Neunzig-Tage-Review eine Frage: Funktioniert dieses Tool wirklich?
Die Ops-Direktorin war vorbereitet. Sie hatte eine Präsentation. Sie hatte Screenshots. Sie hatte Testimonials von drei Teammitgliedern, die sagten, sie mochten das Produkt. Was sie nicht hatte, war eine Baseline: eine dokumentierte Aufzeichnung, wie der Prozess vor dem Tool-Einsatz ausgesehen hatte, was er kostete und was er produzierte. Und ohne eine Baseline gab es kein Delta. Ohne ein Delta gab es keine ROI-Zahl. Ohne eine ROI-Zahl gab es keine Antwort auf die Frage des CFO.
Das Tool funktionierte wahrscheinlich. Aber „funktioniert wahrscheinlich" übersteht keinen Budget-Review in einem Jahr, in dem Software-Kosten unter Beobachtung stehen.
Dieser Leitfaden ist der Messrahmen, der dieses Gespräch verhindert. Er beginnt bevor das Tool live geht, verfolgt die Nutzungsrate nach dreißig und sechzig Tagen und liefert nach neunzig Tagen eine CFO-taugliche ROI-Zusammenfassung, die einer Finanzprüfung standhält.
Key Facts: SaaS-ROI-Messung
- Rund 53 % der SaaS-Lizenzen werden in einem durchschnittlichen Monat nicht genutzt (Productiv State of SaaS 2023), was bedeutet, dass mehr als die Hälfte der Software-Ausgaben bereits unterdurchschnittlich abschneidet, bevor ROI überhaupt berechnet wird.
- Gartner schätzt, dass 25 % der Enterprise-SaaS-Ausgaben für shelfware verschwendet werden, also für Lizenzen, die bezahlt, aber nicht aktiv genutzt werden, und diese Zahl steigt bei Unternehmen ohne formellen 90-Tage-Review-Rhythmus.
- Weniger als 30 % der Unternehmen erfassen eine Basis vor der Implementierung (MIT Sloan), was ROI-Ansprüche nach der Einführung mathematisch unhaltbar macht.
- Typische Time-to-ROI-Fenster nach Kategorie: Produktivitätstools 3-6 Monate, CRM und Sales-Tools 6-12 Monate, ERP- und Finanzplattformen 12-24 Monate (Forrester Total Economic Impact Studies, 2022-2024).
- Der Flexera State of ITAM Report 2024 stellte fest, dass 33 % der SaaS-Verträge ohne formellen ROI-Review automatisch verlängert wurden, das größte einzelne Leck in den meisten Software-Budgets.
Warum die ROI-Messung vor dem Go-Live beginnen muss
Der häufigste Fehler bei der SaaS-ROI-Messung ist, die Messung nach der Einführung zu beginnen. Dann ist die Baseline weg. MIT Sloan Management Reviews Forschung zur IT-Investitionsmessung ergab, dass weniger als 30 % der Unternehmen eine Basis vor der Implementierung erfassen, was nachträgliche ROI-Berechnungen nur dem Namen nach vertretbar macht.
Bevor Ihr Team das neue Tool nutzte, tat es irgendetwas. Dieses Etwas hatte Kosten, einen Zeitaufwand, eine Fehlerquote und einen Durchsatz. Wenn Sie diese Zahlen nicht vor dem Go-Live dokumentieren, können Sie nie das Delta nachweisen, das das Tool geschaffen hat, weil der Zustand vor dem Tool nur in den Erinnerungen der Leute existiert, die unzuverlässig und optimistisch sind.
Das gilt besonders für KI-gestützte Tools, bei denen die vom vendor behaupteten Produktivitätssteigerungen (oft 30-50 %) nur überprüfbar sind, wenn Sie den Ausgangspunkt gemessen haben. Für einen Rahmen zur Trennung echter KI-Fähigkeiten von Marketingbehauptungen vor der Verpflichtung, führt KI-fähige SaaS bewerten durch das Hinterfragen von vendor-Benchmarks in der Bewertungsphase.
Der Messrahmen hat drei Phasen: Baseline (Woche 0), Nutzungs-Tracking (Tag 30 und 60) und Wirkungsquantifizierung (Tag 90).
Phase 1: Baseline-Erfassung vor dem Kauf (Woche 0)
Führen Sie das zwei bis vier Wochen vor dem Go-Live durch, idealerweise bevor die Migrationsentscheidung endgültig ist. Das Ziel ist, den aktuellen Zustand mit ausreichender Detailgenauigkeit zu dokumentieren, um später ein aussagekräftiges Delta berechnen zu können.
Das Baseline-Arbeitsblatt
Für jeden Prozess, den das Tool verbessern soll, dokumentieren Sie:
| Messgröße | Wie zu erfassen |
|---|---|
| Zeit pro Aufgabe | Die Tätigkeit direkt messen; Teammitglieder bitten, eine Woche lang die Zeit zu erfassen |
| Aufgaben pro Person pro Woche | Kalender, Tickets oder Output-Zählungen des Vormonats auswerten |
| Fehler- oder Nachbearbeitungsrate | Aus Support-Tickets, Korrekturprotokollen oder Output-Qualitätsüberprüfungen ziehen |
| Kosten pro Output | Zeit pro Aufgabe × Vollkostenstundensatz multiplizieren |
| Durchsatzkapazität | Maximale Outputs pro Person pro Woche im aktuellen Zustand |
| Nutzerzufriedenheits-Score | 1-5-Skala-Umfrage zur Zufriedenheit mit dem aktuellen Tool oder Prozess |
Beispiel-Baseline für einen Kundensupport-Prozess:
| Kennzahl | Basis vor dem Tool |
|---|---|
| Durchschnittliche erste Antwortzeit | 4,2 Stunden |
| Gelöste Tickets pro Agent pro Tag | 12 |
| Lösungsrate (erster Kontakt) | 64 % |
| Agent-Zeit für Ticket-Administration (Tagging, Routing) | 35 % der Schicht |
| Kosten pro Ticket (Vollkosten) | 18,40 US-Dollar |
| Agent-Zufriedenheits-Score | 2,8/5 |
Diese Zahlen brauchten etwa zwei Stunden zum Abrufen aus dem bestehenden Ticketing-System. Sie werden zum Nenner für jede ROI-Behauptung nach neunzig Tagen.
Was zu erfassen ist, wenn Daten nicht sauber sind
Die meisten Mid-Market-Unternehmen haben keine perfekten Prozessdaten. Wenn historische Daten nicht verfügbar oder unzuverlässig sind:
- Zwei bis drei Teammitglieder bitten, fünf Arbeitstage lang die Zeit mit einem einfachen Zeitprotokoll zu erfassen (Stift und Papier genügt)
- Die aktuellsten dreißig Tage Output-Daten aus dem System ziehen, das sie derzeit erfasst
- Die Schätzung des Team-Managers mit expliziten Unsicherheitsgrenzen nutzen („wir schätzen 3-4 Stunden pro Bericht; nehmen wir 3,5 als Baseline")
- Die Schätzmethode dokumentieren, damit Sie sie beim Neunzig-Tage-Review verteidigen können
Das Ziel ist vertretbar, nicht perfekt. Eine geschätzte Baseline mit dokumentierter Methodik ist weitaus nützlicher als gar keine Baseline.
Die ROI-Attributionspflicht-Regel
Jede ROI-Zahl muss vor dem Go-Live einen einzigen benannten Eigentümer haben: Der Business Owner ist für Ergebniskennzahlen zuständig (Zykluszeit, Durchsatz, Umsatzeinfluss, Fehlerquote), weil er den Prozess kontrolliert; IT ist für Nutzungs- und Integrationskennzahlen zuständig (aktive Nutzer, Funktionstiefe, Verfügbarkeit, Datenflusszustand), weil sie die Einführung kontrolliert; Finanzen ist für die Kosten- und Diskontzinssicht zuständig (Lizenzkosten, Implementierungsamortisation, risikoadjustierte Renditen) und für die endgültige ROI-Berechnung. Wenn eine Zahl in Woche null keinen benannten Eigentümer hat, existiert sie an Tag neunzig nicht, die Attributionspflicht fällt immer demjenigen zu, der die Daten hat, und nicht zugeordnete Zahlen werden nie erhoben.
Phase 2: Nutzungs-Tracking (Tag 30 und 60)
Die Nutzungsrate ist der Frühindikator für ROI. Ein Tool, das nicht genutzt wird, kann keine Rendite erzielen. Aber Nutzungsdaten müssen auf der richtigen Ebene erfasst werden. Login-Zählungen sind Aktivitätskennzahlen, keine Nutzungskennzahlen. Gartners Forschung zur Einführung digitaler Arbeitsplatztechnologie zeigt, dass Tools mit geringer Funktionsnutzungstiefe an Tag 30 eine deutlich höhere Wahrscheinlichkeit haben, in Monat 12 unterzugenutzt zu sein. Frühe Nutzungsmuster sind der beste verfügbare Prädiktor für die langfristige Wertrealisierung.
Der 30-Tage-Nutzungs-Scorecard
An Tag dreißig messen Sie, ob das Tool überhaupt genutzt wird und ob die Einführung auf Kurs ist.
| Kennzahl | Zielwert |
|---|---|
| Aktive Nutzer / bereitgestellte Nutzer | >60 % |
| Kernfunktions-Aktivierungsrate | >40 % der erwarteten Funktionen in Nutzung |
| Support-Tickets / Nutzer (tool-bezogen) | <0,5 pro Nutzer |
| Manager-Nutzungsrate (kritisch für Top-down-Tools) | 100 % |
| Trainingsabschlussrate | >80 % |
Red Flags an Tag 30:
- Aktive Nutzerrate unter 40 %: wahrscheinlich ein Change-Management- oder Trainingsproblem
- Hohes Support-Ticket-Volumen: wahrscheinlich ein Implementierungs- oder Konfigurationsproblem
- Kernfunktionsnutzung unter 20 %: wahrscheinlich erfüllt das Tool den Use Case nicht wie erwartet
Gehen Sie bei Red Flags an Tag dreißig sofort vor. Monat zwei ist noch korrigierbar. Monat vier nicht mehr.
Der 60-Tage-Nutzungs-Scorecard
An Tag sechzig messen Sie, ob die Nutzung zunimmt oder stagniert.
| Kennzahl | Zielwert | Wie zu messen |
|---|---|---|
| Aktive Nutzer / bereitgestellt | >75 % | vendor-Dashboard oder Admin-Panel |
| Funktionstiefe (genutzte / verfügbare Funktionen) | >50 % | vendor-Nutzungsanalysen |
| Tägliche aktive Nutzung durch Power Users | 80 %+ bei rollenspezifischen Funktionen | Manager-Bestätigung und vendor-Daten |
| Integrationsnutzung | Integrationen aktiviert und Daten verarbeitend | IT-Bestätigung |
| Nutzerzufriedenheits-Score | >3,5/5 | Kurze Pulsumfrage |
An Tag sechzig sollten Sie auch den ersten Produktivitätsdatenpunkt ziehen: einen vorläufigen Vergleich mit der Baseline aus Woche null bei einer oder zwei Schlüsselkennzahlen. Das zeigt, ob die Neunzig-Tage-Zahlen auf Kurs sind und gibt Zeit zur Kurskorrektur, falls nicht.
Phase 3: Wirkungsquantifizierung (Tag 90)
Nach neunzig Tagen haben Sie genug Daten, um ROI zu berechnen. Der Rahmen misst drei Kategorien von Wirkung: Zeitersparnis, Fehlerreduzierung und Umsatzeinfluss.
Kategorie 1: Zeitersparnis
Zeitersparnis ist der häufigste und meist bedeutendste ROI-Treiber für Produktivitäts- und Workflow-Tools.
Berechnung:
Gesparte Zeit pro Aufgabe × Aufgaben pro Nutzer pro Woche × Anzahl Nutzer × Wochen im Zeitraum = Gesamte gesparte Stunden
Gesamte gesparte Stunden × Vollkostenstundensatz = Dollarwert der Zeitersparnis
Gerechtes Beispiel:
Vor dem Tool: Ein Kundensupport-Agent verbringt 1,4 Stunden pro Tag mit Ticket-Routing und Verwaltungsaufgaben. Nach dem Tool: Automatisches Routing reduziert das auf 0,4 Stunden pro Tag. Gesparte Zeit pro Agent pro Tag: 1 Stunde. Teamgröße: 8 Agents. Wochen im Messzeitraum: 12 (90 Tage). Gesamte gesparte Stunden: 1 × 5 Tage × 8 Agents × 12 Wochen = 480 Stunden. Vollkostenstundensatz: 40 US-Dollar/Stunde. Dollarwert der Zeitersparnis: 19.200 US-Dollar über 90 Tage / 76.800 US-Dollar annualisiert.
Kategorie 2: Fehler- und Nachbearbeitungsreduzierung
Tools, die manuelle Dateneingabe, Übergabefehler oder Prozessvariabilität reduzieren, erzeugen Einsparungen durch Nachbearbeitungsreduzierung.
Berechnung:
(Fehlerquote vor dem Tool − Fehlerquote nach dem Tool) × Aufgabenvolumen × Kosten pro Nachbearbeitung = Einsparungen durch Fehlerreduzierung
Gerechtes Beispiel:
Vor dem Tool: 8 % der Rechnungen erforderten manuelle Korrektur (Dateneingabefehler). Nach dem Tool: 2 % erfordern Korrektur. Monatliches Rechnungsvolumen: 300. Monatliche Fehlerreduzierung: (8 % - 2 %) × 300 = 18 weniger Korrekturen pro Monat. Durchschnittliche Korrekturzeit: 45 Minuten. 18 Korrekturen × 45 Min × 35 US-Dollar/Stunde Vollkosten = 472 US-Dollar/Monat / 5.664 US-Dollar/Jahr.
Kategorie 3: Umsatzeinfluss
ROI durch Umsatzeinfluss gilt für Tools, die direkt die Vertriebskapazität, Pipeline-Geschwindigkeit oder Kundenbindung beeinflussen.
Berechnung (Vertriebskapazität):
Gesparte Zeit pro Rep pro Woche × Anzahl Reps × Win Rate × durchschnittlicher Deal-Wert = Umsatzeinfluss
Gerechtes Beispiel:
CRM-Automatisierungs-Tool spart jedem Vertriebsmitarbeiter 3 Stunden/Woche Dateneingabe. Team: 6 Reps. Win Rate: 25 %. Durchschnittlicher Deal: 15.000 US-Dollar. Verfügbare Stunden: 3 × 6 = 18 Stunden/Woche zusätzliche Verkaufszeit. Bei 2 Demos pro Stunde und 25 % Win Rate: 18 Stunden × 2 Demos × 25 % × 15.000 US-Dollar = 135.000 US-Dollar zusätzlicher Pipeline-Einfluss pro Woche.
Hinweis: Umsatzeinfluss ist am schwierigsten sauber zuzuordnen. Verwenden Sie konservative Zahlen und dokumentieren Sie Ihre Annahmen. Forresters Total Economic Impact Methodology verlangt, dass alle umsatzzugeordneten Vorteile für Risiko diskontiert werden (mit einem risikoangepassten Faktor zwischen 0,5 und 1,0), genau weil kausale Zuordnung schwierig ist. Einen ähnlichen Diskontfaktor zu übernehmen macht Ihr ROI-Modell glaubwürdiger für Finanzteams. Ein CFO akzeptiert eine konservative Umsatzeinfluss-Berechnung mit klaren Annahmen. Bei einer aggressiven mit unscharfer Methodik wird er widersprechen. Und wenn es zur Verlängerung kommt, werden diese ROI-Daten zu Ihrem primären Hebel. Das Verlängerungs-Verhandlungs-Playbook zeigt, wie Sie Neunzig-Tage-Ergebnisdaten nutzen, um einen fairen Preis auszuhandeln.
Das CFO-Zusammenfassungs-Template (1 Seite)
SaaS-ROI-Zusammenfassung, [Tool-Name]
Zeitraum: [Go-Live-Datum] bis [90-Tage-Datum]
Erstellt von: [Name]
INVESTITION
Jährliche Lizenzkosten: [X] Euro
Implementierung (einmalig): [X] Euro
Integration und Setup: [X] Euro
Gesamtkosten 90 Tage: [X] Euro
Annualisierte Gesamtkosten: [X] Euro
RENDITE (annualisiert)
Zeitersparnis: [X] Euro ([X] Stunden × [X] Euro/Std Vollkosten)
Fehler-/Nachbearbeitungsreduktion: [X] Euro ([Annahmen])
Umsatzeinfluss: [X] Euro ([konservative Annahme])
Gesamte annualisierte Rendite: [X] Euro
NUTZUNGSRATE
Aktive Nutzer: [X] / [X] bereitgestellt ([X] %)
Funktionstiefe: [X] % der erwarteten Funktionen in aktiver Nutzung
Nutzerzufriedenheit: [X]/5
BASELINE-VERGLEICH
[Kennzahl 1]: [Vorher] → [Nachher] ([X] % Verbesserung)
[Kennzahl 2]: [Vorher] → [Nachher] ([X] % Verbesserung)
ROI (annualisiert): ([Rendite - Kosten] / Kosten) × 100 = [X] %
Amortisationszeitraum: [X] Monate
EMPFEHLUNG
[Weiterführen / Erweitern / Umfang reduzieren / Einstellen], [1-2 Sätze Begründung]
Wie Rework Work Ops den ROI-Rhythmus und Verlängerungs-Reviews verfolgt
Die meisten ROI-Daten gehen nicht verloren, weil der Rahmen falsch ist, sondern weil der Rhythmus zusammenbricht. Baseline-Erfassungen in Woche null werden vorgenommen, 30-Tage-Check-ins werden übersprungen, und an Tag neunzig baut die Ops-Direktorin die Zahlen aus der Erinnerung zusammen. Rework Work Ops (ab 6 US-Dollar/Nutzer/Monat) wurde entwickelt, um diesen Rhythmus über das gesamte Tool-Portfolio aufrechtzuerhalten, nicht lizenzweise.
Jedes SaaS-Abonnement lebt in Work Ops als verfolgtes Element mit seinen Baseline-Kennzahlen, Eigentümer, Verlängerungsdatum und dem Neunzig-Tage-Review, der als wiederkehrende Aufgabe zwölf Wochen vor der nächsten Vertragsentscheidung festgelegt ist. Die Plattform erinnert den Business Owner automatisch an Tag dreißig und sechzig, Nutzungs- und vorläufige Ergebnisdaten gegen die Baseline einzutragen, sodass bei der Verlängerung nichts rekonstruiert werden muss. Wenn ein Vertrag innerhalb von sechzig Tagen vor dem Ablauf liegt, blendet Work Ops den vollständigen Baseline-bis-aktuell-Vergleich neben dem Kosten- und Nutzungsprotokoll ein, genau die einseitige CFO-Zusammenfassung, die dieser Leitfaden beschreibt, automatisch aus den Feldern erstellt, die Ihr Team bereits eingepflegt hat. Teams, die den gesamten Rework Stack nutzen, verwenden das, um jede SaaS-Verlängerungsentscheidung an einen dokumentierten Ergebnisnachweis statt an ein Bauchgefühl zu knüpfen.
Häufige Messfehler
Aktivität statt Ergebnisse messen. Login-Zählung ist kein ROI. Feature-Klicks sind kein ROI. ROI ist eine Veränderung in einem Geschäftsergebnis (Zeit, Kosten, Umsatz, Fehlerquote) mit einem beigefügten Dollarwert.
Die Baseline nicht vor dem Go-Live erfassen. Das ist der fatale Fehler. Wenn die Baseline-Daten weg sind, können Sie noch einen Vergleich zwischen dem aktuellen Zustand und dem geschätzten Zustand davor ausführen, aber der CFO wird wissen, dass es eine Schätzung ist, und sie entsprechend behandeln.
Korrelation mit Attribution verwechseln. Der Umsatz des Unternehmens stieg in Q1, und Sie haben das Sales-Tool in Q1 eingeführt. Die Umsatzsteigerung ist ohne eine sorgfältigere Analyse nicht dem Tool zuzuordnen. Beanspruchen Sie keine Attribution, die Sie nicht belegen können.
Nur die positiven Kennzahlen berichten. Ein CFO, der eine ROI-Zusammenfassung ohne Einschränkungen, ohne Verfehlungen und ohne Verbesserungsbereiche sieht, wird skeptischer sein, nicht weniger. Fügen Sie hinzu, was nicht funktioniert hat und was Sie dagegen tun. Das ist operative Glaubwürdigkeit. Wenn das Tool den Neunzig-Tage-Review nicht besteht, behandelt SaaS-Konsolidierung den Entscheidungsrahmen „behalten oder streichen" und wie die Außerbetriebnahme sequenziert werden kann, ohne das Team zu stören.
Häufig gestellte Fragen
Mehr erfahren
- TCO-Modellierung für SaaS: Jenseits des Sticker-Preises: wie die Kostenseite der ROI-Gleichung vor dem Kauf modelliert wird
- SaaS-Konsolidierung: Wann ein Tool streichen vs. behalten?: was mit Tools zu tun ist, die den 90-Tage-ROI-Review nicht bestehen
- Verlängerungsverhandlung: Wie Sie einen fairen Preis ohne Wechsel erzielen: ROI-Daten als Hebel bei der Verlängerung nutzen
- Der SaaS-Entscheidungsbaum: Wann kaufen, bauen oder ergänzen?: der Rahmen, der vor dem Kauf realistische ROI-Erwartungen setzt
- KI-Bereitschafts-Assessment-Templates: Baseline-Assessment-Tools für die Messung von Ausgangspunkt-Kennzahlen vor dem Einsatz von KI-SaaS
- Produktivitätstools im Vergleich: Vergleichskontext zur Benchmark-Setzung von Produktivitätssteigerungen gegenüber Kategorie-Durchschnittswerten

Head of Enterprise Solutions
On this page
- Warum die ROI-Messung vor dem Go-Live beginnen muss
- Phase 1: Baseline-Erfassung vor dem Kauf (Woche 0)
- Das Baseline-Arbeitsblatt
- Was zu erfassen ist, wenn Daten nicht sauber sind
- Die ROI-Attributionspflicht-Regel
- Phase 2: Nutzungs-Tracking (Tag 30 und 60)
- Der 30-Tage-Nutzungs-Scorecard
- Der 60-Tage-Nutzungs-Scorecard
- Phase 3: Wirkungsquantifizierung (Tag 90)
- Kategorie 1: Zeitersparnis
- Kategorie 2: Fehler- und Nachbearbeitungsreduzierung
- Kategorie 3: Umsatzeinfluss
- Das CFO-Zusammenfassungs-Template (1 Seite)
- Wie Rework Work Ops den ROI-Rhythmus und Verlängerungs-Reviews verfolgt
- Häufige Messfehler
- Häufig gestellte Fragen
- Mehr erfahren