Deutsch

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