Eine Process Map ist nur dann operativ brauchbar, wenn zwei Personen denselben Fall unabhängig gleich bearbeiten würden. Eine Abfolge bunter Kästen reicht dafür nicht. Teams müssen erkennen können, welches Ereignis den Ablauf startet, welche Information vollständig sein muss, wer arbeitet, wer entscheiden darf und wo das Ergebnis gespeichert wird.
Die fünf Beispiele auf dieser Seite bilden einen möglichen B2B-SaaS-Lebenszyklus ab. Sie sind keine vorgeschriebene RevOps-Taxonomie. Salesforce weist in seiner offiziellen Anleitung selbst darauf hin, dass Opportunity-Stufen je Unternehmen variieren. Übernehmen Sie deshalb die Felder der Vorlage, aber passen Sie Prozesse, Stufen und Begriffe an Ihr Geschäftsmodell an. Salesforce Trailhead: Opportunity-Stufen.
Die kopierfertige RevOps-Process-Map
Kopieren Sie den folgenden Block für jede relevante Übergabe. Schreiben Sie konkrete Zustände und Feldnamen statt abstrakter Verben wie „bearbeiten“ oder „optimieren“.
Prozessname: [Startzustand] → [Endzustand]
Trigger: Welches beobachtbare Ereignis startet den Prozess?
Input: Welche Felder, Nachweise oder Freigaben müssen vorliegen?
Output: Welcher prüfbare Zustand beendet den Prozess?
Swimlanes: Welche Rollen führen welche Schritte aus?
Owner: Wer hält Definition, Datenqualität und Ablauf aktuell?
Entscheidungsrecht: Wer darf freigeben, ablehnen oder priorisieren?
System of Record: In welchem System gilt Status oder Nachweis als verbindlich?
Ausnahmeweg: Wohin geht ein unvollständiger, verspäteter oder strittiger Fall?
Messung: Welche Qualitäts-, Zeit- oder Ergebniskennzahl prüft den Prozess?
| Feld | Prüffrage | Schwache Formulierung | Prüfbare Formulierung |
|---|---|---|---|
| Trigger | Ist der Start im System erkennbar? | Wenn ein Lead interessant ist | Lifecycle Stage wechselt auf „MQL“ |
| Output | Ist das Ende eindeutig? | Lead wurde geprüft | Status ist „akzeptiert“, „recycelt“ oder „disqualifiziert“ |
| Owner | Ist eine Rolle accountable? | Sales und Marketing | Revenue Operations Manager |
| Messung | Lässt sich Ausführung prüfen? | Schnelle Bearbeitung | Medianzeit vom Trigger bis zum ersten qualifizierten Ergebnis |
Schritt 1: Den tatsächlichen Ist-Prozess aufnehmen
Wählen Sie eine einzelne Übergabe mit erkennbarem Problem, zum Beispiel MQL → Sales-Akzeptanz. Lassen Sie je eine ausführende Person vor und nach der Übergabe einen realen Fall erklären. Prüfen Sie parallel den Datensatz im System. So werden Unterschiede zwischen Dokumentation und tatsächlicher Arbeit sichtbar.
- Fall auswählen: einen normalen, einen abgelehnten und einen verspäteten Fall.
- Handlungen protokollieren: Schritt, Rolle, System, Eingabe und Ergebnis.
- Wartezeiten markieren: besonders an Team- und Systemgrenzen.
- Entscheidungen markieren: inklusive Person, Kriterien und möglicher Ausgänge.
- Ausnahmen sammeln: Workarounds, Rückfragen und manuelle Datenkorrekturen.
Zeichnen Sie erst danach Swimlanes. Eine Lane steht für eine Rolle oder ein System mit eigenem Arbeitsanteil; sie ist kein Ersatz für die Benennung des Process Owners. Das Diagramm visualisiert den Fluss, während die neun Felder die Betriebsregeln festhalten.
Fünf RevOps-Prozessbeispiele zum Anpassen
Die folgenden Maps sind Startpunkte. Begriffe wie MQL, Opportunity oder Activation müssen vor der Nutzung intern definiert werden. Wenn Ihr Go-to-Market-Modell keine MQL-Stufe verwendet, ersetzen Sie sie durch den tatsächlichen qualifizierten Zustand.
Map 01
Lead → qualifizierte Marketing-Übergabe
- Trigger
- Ein Kontakt erfüllt die dokumentierten Fit- und Intent-Kriterien.
- Input
- Quelle, Einwilligungsstatus, Konto, relevante Fit-Felder und beobachtetes Signal.
- Output
- Qualifiziert, für Nurturing zurückgestellt oder mit Grund disqualifiziert.
- Swimlanes / Owner
- Marketing Operations führt aus; RevOps besitzt Definition und Datenvertrag.
- Entscheidungsrecht
- Marketing-Leitung genehmigt die Qualifikationslogik gemeinsam mit Sales.
- System of Record
- Marketing-Automation für Signale; CRM für den freigegebenen Lifecycle-Status.
- Ausnahmeweg
- Fehlende Firmendaten in eine Enrichment-Queue; strittige Kriterien in das Definitions-Review.
- Messung
- Annahmequote nach Quelle sowie Anteil fehlender Pflichtfelder.
Map 02
Qualifizierte Übergabe → Opportunity
- Trigger
- Der freigegebene Qualifikationsstatus wird im CRM gespeichert.
- Input
- Kontaktweg, Geschäftskontext, Qualifikationsgrund und zuständige Person.
- Output
- Opportunity mit definiertem nächsten Schritt oder dokumentierter Recycling-/Disqualifizierungsgrund.
- Swimlanes / Owner
- Sales Development bearbeitet; Sales Operations verantwortet Routing und Statuslogik.
- Entscheidungsrecht
- Die zuständige Sales-Rolle akzeptiert oder lehnt anhand der vereinbarten Kriterien ab.
- System of Record
- CRM.
- Ausnahmeweg
- Nicht zuordenbare Fälle in eine Routing-Queue; Meinungsverschiedenheiten mit Grundcode an RevOps.
- Messung
- Zeit bis zum Ergebnis, Annahmequote und Verteilung der Ablehnungsgründe.
Map 03
Opportunity → Closed Won oder Closed Lost
- Trigger
- Eine Opportunity erfüllt das dokumentierte Eintrittsgate der ersten aktiven Stage.
- Input
- Käuferproblem, Stakeholder, Wertdefinition, nächster Schritt und erwartete Periode.
- Output
- Unterzeichneter Auftrag oder Closed-Lost-Status mit standardisiertem Grund.
- Swimlanes / Owner
- Account Executive, Sales Engineering, Legal und Finance; Sales Operations besitzt Stage-Definitionen.
- Entscheidungsrecht
- Sales-Führung entscheidet Forecast-Kategorie; definierte Funktionen geben Preis, Recht und Risiko frei.
- System of Record
- CRM für Stage und Forecast; Vertragsplattform für Freigabe und Signatur.
- Ausnahmeweg
- Preis-, Rechts- oder Sicherheitsabweichungen in die jeweils benannte Approval-Queue.
- Messung
- Stage-Konversion, Verweildauer je Stage und Anteil ohne bestätigten nächsten Schritt.
Map 04
Closed Won → Onboarding abgeschlossen
- Trigger
- Auftrag ist gültig, Abrechnungsstatus und Startbedingungen sind bestätigt.
- Input
- Kaufmotiv, gewünschtes Ergebnis, Stakeholder, Scope, Zusagen und technische Voraussetzungen.
- Output
- Intern definierter Aktivierungsnachweis und bestätigter nächster Erfolgsmeilenstein.
- Swimlanes / Owner
- Sales, Finance, Implementation und Customer Success; CS Operations besitzt die Handoff-Regel.
- Entscheidungsrecht
- Customer Success bestätigt die Vollständigkeit; Fachverantwortliche entscheiden über Scope-Ausnahmen.
- System of Record
- CRM für Account-Status; Projekt- oder CS-System für Onboarding-Meilensteine.
- Ausnahmeweg
- Unvollständige Übergabe zurück an Sales; Scope-Konflikt in dokumentierte Freigabe.
- Messung
- Zeit bis zum definierten Aktivierungsereignis und Anteil blockierter Onboardings nach Ursache.
Map 05
Nutzungssignal → Renewal- oder Expansion-Entscheidung
- Trigger
- Renewal-Fenster beginnt oder ein vorher definiertes Nutzungs-/Bedarfssignal tritt ein.
- Input
- Vertrag, Nutzung, Support-Historie, Zielerreichung, Stakeholder und Zahlungsstatus.
- Output
- Renewal-/Expansion-Opportunity, Maßnahmenplan oder dokumentierter Churn-/No-fit-Grund.
- Swimlanes / Owner
- Customer Success, Account Management und Finance; CS Operations besitzt Regeln und Routing.
- Entscheidungsrecht
- Commercial Owner führt die Kaufentscheidung; Preis- oder Risikoausnahmen folgen der Approval-Matrix.
- System of Record
- CRM für Opportunity; Billing für Vertrag und Zahlung; CS-System für Nutzung und Maßnahmen.
- Ausnahmeweg
- Unklare Nutzungssignale in manuelle Prüfung; Vertragskonflikte an Finance oder Legal.
- Messung
- Renewal-Entscheidungen vor Vertragsende, Expansion-Konversion und Outcome-Abdeckung.
Schritt 2: Owner, Ausführung und Entscheidungsrecht trennen
„Sales & Marketing“ ist kein Owner. Benennen Sie eine Rolle, die Prozessdefinition, Datenvertrag und Änderungslog verantwortet. Die ausführende Person kann eine andere sein. Auch das Entscheidungsrecht kann getrennt liegen: Ein SDR bearbeitet den Lead, Sales Operations besitzt das Routing und die Sales-Leitung entscheidet über Qualifikationskriterien.
| Verantwortung | Leitfrage | Dokumentierter Output |
|---|---|---|
| Process Owner | Wer hält Definition und Kontrolle funktionsfähig? | Name der Rolle, Review-Auslöser, Versionsstand |
| Ausführende Rolle | Wer erledigt den jeweiligen Schritt? | Rolle je Swimlane und Schritt |
| Decision Owner | Wer darf zwischen möglichen Ausgängen entscheiden? | Entscheidungsregel und erforderlicher Nachweis |
| System Owner | Wer setzt Feld-, Routing- oder Validierungslogik um? | Change-Prozess und Testnachweis |
Schritt 3: SLAs als interne Kontrollen definieren
Eine Frist wie „innerhalb von 24 Stunden“ ist ohne Kontext nicht belastbar. Kanal, Kaufabsicht, Geschäftszeiten, Teamabdeckung und Fehlerkosten unterscheiden sich. Messen Sie zunächst die Zeit vom Trigger bis zum gewünschten Output und segmentieren Sie nach relevanten Falltypen. Wählen Sie danach eine interne Kontrollgrenze, die eine konkrete Eskalation auslöst.
Ein vollständiger SLA-Eintrag enthält:
- Start- und End-Timestamp inklusive Zeitzone und Geschäftszeit-Regel,
- einbezogene und ausgeschlossene Falltypen,
- verantwortliche Rolle und Vertretung,
- Eskalationsstufe bei drohender und eingetretener Verletzung,
- Messgröße für Ergebnis und Arbeitslast nach der Änderung.
Eine SLA-Verletzung erklärt nicht automatisch einen Conversion-Verlust. Sie zeigt zunächst, dass eine intern vereinbarte Prozesskontrolle nicht eingehalten wurde. Prüfen Sie Wirkung und mögliche Nebenfolgen mit den eigenen Daten.
Schritt 4: System of Record und Datenvertrag festlegen
Für jedes Statusfeld und jeden Nachweis muss genau ein System verbindlich sein. Das Wiki erklärt die Regel; das System of Record speichert den operativen Zustand. Wenn CRM und Spreadsheet widersprechen, muss vorab feststehen, welcher Wert gilt und wie die Abweichung korrigiert wird.
Minimaler Datenvertrag
Feldname → Definition → erlaubte Werte → erzeugende Rolle → Aktualisierungsereignis → Validierung → nachgelagerte Verwendung.
Versionieren Sie Änderungen. Sonst kann ein Reporting-Sprung wie eine Prozessverbesserung aussehen, obwohl sich nur die Definition geändert hat.
Schritt 5: Prozessleistung ohne Scheinpräzision messen
Verbinden Sie eine Ausführungskennzahl mit einer Ergebniskennzahl. Bearbeitungszeit oder Pflichtfeld-Vollständigkeit zeigen, ob der Prozess wie geplant läuft. Annahmequote, Stage-Konversion oder Aktivierung zeigen, ob der gewünschte Zustand eintritt. Die Verbindung ist zunächst eine Hypothese, keine garantierte Kausalität.
| Messart | Beispiel | Entscheidung |
|---|---|---|
| Qualität | Anteil vollständig übergebener Datensätze | Pflichtfelder, Training oder Definition anpassen |
| Zeit | Median und obere Verteilung der Durchlaufzeit | Kapazität, Routing oder Ausnahmepfad prüfen |
| Ausnahme | Anteil je Rückgabe- oder Eskalationsgrund | Wiederkehrende Ausnahme in Standardprozess überführen |
| Ergebnis | Konversion in den definierten Endzustand | Qualifikations- oder Gate-Hypothese neu testen |
Die Map in sechs kontrollierten Schritten einführen
- Scope begrenzen: eine Übergabe und ein klarer Problemindikator.
- Ist-Prozess validieren: reale Fälle mit ausführenden Rollen und Systemdaten nachzeichnen.
- Soll-Regeln entwerfen: neun Vorlagenfelder inklusive Ausnahmen ausfüllen.
- Entscheidungsrechte freigeben: betroffene Funktionsleitungen bestätigen Kriterien und Eskalation.
- Systemänderung testen: Felder, Routing und Automationen in kontrollierter Umgebung prüfen.
- Wirkung beobachten: Baseline und Messfenster vorab dokumentieren; Nebenfolgen mitprüfen.
Der Revenue-Operations-Leitfaden ordnet diese Arbeit in Operating Model, Datenvertrag und Planungskadenz ein. Das RevOps-Maturity-Modell hilft anschließend zu beurteilen, welche Governance-Fähigkeit als Nächstes aufgebaut werden sollte. Diese Seite bleibt bewusst auf die ausführbare Prozessvorlage fokussiert.
Process Maps als kontrollierte Betriebsdokumente führen
Hinterlegen Sie je Map Owner, Freigabedatum, Versionsnummer und Änderungsgrund. Ein Review wird durch Änderungen an Rollen, Systemen, Definitionen oder wiederkehrende Ausnahmen ausgelöst. Eine zusätzliche feste Kadenz kann sinnvoll sein, wenn Prozesse häufig wechseln oder Fehler hohe Auswirkungen haben.
- Änderungslog: Was wurde geändert, warum und durch wen freigegeben?
- Testfall: Welcher normale und welcher Ausnahmefall beweist die neue Regel?
- Rollback: Wie wird eine fehlerhafte Automation oder Definition zurückgenommen?
- Kommunikation: Welche Rollen müssen vor Inkrafttreten informiert oder geschult werden?
Häufige Fragen zu RevOps Process Mapping
Was muss eine RevOps Process Map enthalten?
Mindestens Trigger, Input, Output, beteiligte Swimlanes, einen verantwortlichen Owner, das Entscheidungsrecht, ein System of Record, den Ausnahmeweg und eine Messgröße. Fehlt eines dieser Felder, bleibt oft unklar, wann der Prozess startet, wer entscheiden darf oder woran die Ausführung geprüft wird.
Ist ein SLA von 24 Stunden für jede Lead-Übergabe richtig?
Nein. Ein SLA ist eine intern gewählte Kontrollgrenze. Es sollte zum Kanal, zur Kaufabsicht, zur Teamabdeckung und zum möglichen Schaden einer Verzögerung passen. Messen Sie zunächst die eigene Baseline und testen Sie dann, ob eine veränderte Frist Ergebnis und Arbeitslast verbessert.
Wo sollte die verbindliche Process Map gespeichert werden?
Das freigegebene Prozessdokument gehört in ein versioniertes Operations-Wiki. Status, Pflichtfelder und operative Nachweise gehören in das jeweils benannte System of Record, häufig CRM, Marketing-Automation, Support- oder Abrechnungssystem. Das Diagramm allein ist keine Datenquelle.
Wann muss eine RevOps Process Map aktualisiert werden?
Aktualisieren Sie die Map, wenn sich Rollen, Systeme, Definitionen oder Entscheidungsrechte ändern oder wenn eine wiederkehrende Ausnahme den dokumentierten Standardprozess widerlegt. Eine feste Review-Kadenz kann zusätzlich helfen, sollte aber aus der Veränderungsrate und dem Risiko des Prozesses abgeleitet werden.
