TL;DR
- — 5 Kernprozesse: Lead-to-MQL, MQL-to-Opportunity, Opportunity-to-Close, Close-to-Onboarding, Onboarding-to-Expansion
- — Swim-Lane-Diagramme visualisieren Verantwortlichkeiten und Übergaben zwischen Funktionen
- — Jeder Prozess braucht definierte Eintritts- und Ausgangsbedingungen, SLAs und Eskalationsregeln
- — Häufigste Bottlenecks: MQL-Follow-up-SLA, Deal-Stagnation, Onboarding-Completion
- — Process Maps sind Dokumentation — ihre Nützlichkeit entsteht durch regelmäßige Überprüfung
RevOps Process Mapping ist der Ausgangspunkt für jede systematische Verbesserung im Revenue-Bereich. Ohne eine dokumentierte Darstellung der fünf Kernprozesse ist es schwierig zu bestimmen, wo Leads verloren gehen, wo Übergaben scheitern und wo Kapazität verschwendet wird. Dieses Rahmenwerk gibt RevOps-Teams eine strukturierte Vorlage für die Kartierung und einen Schritt-für-Schritt-Prozess für die Umsetzung.
Was Process Mapping im RevOps-Kontext bedeutet
Process Mapping bedeutet im RevOps-Kontext, die Abläufe zu dokumentieren, die einen Lead durch den gesamten Kundenlebenszyklus führen — von der ersten Kontaktaufnahme bis zur Expansion. Das Ziel ist nicht, schöne Diagramme zu erstellen — es ist, Verantwortlichkeiten, Übergaben und Bottlenecks so transparent zu machen, dass sie verbessert werden können.
Eine vollständige RevOps Process Map besteht aus fünf Kernprozessen, die den gesamten Revenue-Lebenszyklus abdecken. Jeder Prozess hat eine definierte Übergabe zwischen zwei Funktionen und messbare Qualitätskriterien an dieser Übergabe. RevOps-Teams, die diese fünf Prozesse vollständig kartiert haben, können Conversion-Raten je Stufe messen und gezielt verbessern.
Wie Swim-Lane-Diagramme RevOps-Prozesse visualisieren
Swim-Lane-Diagramme sind das Standard-Visualisierungsformat für RevOps-Prozesse, weil sie Verantwortlichkeiten explizit machen. Jede horizontale Spur (Lane) entspricht einer Funktion: Marketing, Sales Development, Account Executives, Customer Success und Operations. Aktivitäten werden in der Spur der verantwortlichen Funktion platziert. Übergaben zwischen Funktionen werden durch Pfeile dargestellt, die Spur-Grenzen überqueren.
Der Vorteil gegenüber einfachen Flowcharts: Swim-Lane-Diagramme zeigen auf einen Blick, welche Funktion an jedem Punkt des Prozesses verantwortlich ist. Wenn ein Bottleneck sichtbar wird, ist sofort klar, welchem Team es gehört. Das vermeidet die häufige Diskussion, ob ein Problem im Marketing, Vertrieb oder CS liegt.
Swim-Lane-Struktur: RevOps-Prozessvorlage
Marketing
Sales Development
Account Executives
Customer Success
Operations / RevOps
Prozess 1: Lead-to-MQL (Lead-Qualifizierung)
Der erste Kernprozess beschreibt, wie rohe Leads zu Marketing Qualified Leads (MQL) werden. Dieser Prozess gehört primär dem Marketing-Team, aber RevOps definiert die Qualifikationskriterien und überwacht die Übergabe-Qualität.
Was dieser Prozess kartieren muss:
- — Eintrittsbedingung: Wann wird ein Kontakt als Lead erfasst? (Formular, Import, Enrichment)
- — Scoring-Kriterien: Welche Aktionen und Attribute erhöhen den Score? (BANT, Engagement, Firmographics)
- — MQL-Definition: Ab welchem Score oder welchen Kriterien gilt ein Lead als MQL?
- — Ausgangsbedingung: Was passiert bei der Übergabe? Wer wird benachrichtigt, welche Datenfelder müssen befüllt sein?
- — SLA: Innerhalb welcher Frist muss ein MQL vom SDR-Team aufgenommen werden?
Häufiges Bottleneck: Unklare oder veraltete MQL-Definition. Wenn Marketing und Vertrieb unterschiedliche Vorstellungen davon haben, was einen MQL qualifiziert, entstehen reibungsreiche Übergaben und geringe Conversion-Raten. RevOps-Teams sollten die MQL-Definition quartalsweise gemeinsam mit Marketing und Vertrieb überprüfen.
Prozess 2: MQL-to-Opportunity (Sales-Qualifizierung)
Der zweite Prozess beschreibt, wie das Sales-Development-Team MQLs in qualifizierte Opportunities umwandelt. Dieser Prozess ist der häufigste Ort für SLA-Verletzungen und Conversion-Verluste.
Was dieser Prozess kartieren muss:
- — SLA für erstes Follow-up: Maximale Frist zwischen MQL-Status und erstem SDR-Kontaktversuch (Richtwert: 24 Stunden)
- — Qualifizierungsrahmen: BANT, MEDDIC oder equivalent — welche Felder müssen beim Discovery-Call befüllt werden?
- — SQL-Definition: Welche Mindestbedingungen müssen erfüllt sein, bevor ein Lead als SQL an den AE übergeben wird?
- — Disqualifizierungspfade: Was passiert mit Leads, die nicht qualifiziert werden? Nurturing, Recycling oder Archiv?
- — Übergabedokumentation: Welche Informationen übergibt der SDR an den AE? Discovery-Notizen, Budget, Timeline, Entscheidungsträger
Häufiges Bottleneck: SLA-Verletzung beim ersten Follow-up. Studien zeigen, dass die Kontaktwahrscheinlichkeit nach mehr als 5 Stunden um über 80% sinkt. RevOps-Teams sollten automatische Eskalationsregeln im CRM einrichten, die bei SLA-Verletzungen sofort benachrichtigen. Fairviews Pipeline-Visibility-Funktion zeigt überfällige MQLs in Echtzeit.
Prozess 3: Opportunity-to-Close (Abschluss)
Der dritte Prozess beschreibt den Vertriebsprozess von der qualifizierten Opportunity bis zum Vertragsabschluss. Dieser Prozess ist am engsten mit dem Forecast verbunden — jede Abweichung hier wirkt sich direkt auf die Planungsgenauigkeit aus.
Was dieser Prozess kartieren muss:
- — Stage-Definitionen: Was muss eingetreten sein, damit ein Deal von Stage 2 auf Stage 3 wechselt?
- — Required Activities je Stage: Demo, Proposal, Executive Sponsor-Identifikation, Vertragsversand
- — Deal-Stagnations-Schwellenwert: Ab wie vielen Tagen ohne Aktivität wird ein Deal als stagnierend markiert?
- — Abschlussbedingungs-Checkliste: Was muss vor dem Abschluss vorliegen? Signierte Order Form, IT-Security-Review, Legal-Freigabe
- — Verlust-Analyse-Pflicht: Bei Verlust eines Deals — wird die Verlustursache im CRM erfasst? Nach welchen Kategorien?
Häufiges Bottleneck: Fehlende Stage-Übergangsdefinitionen führen zu Deals, die im CRM manuell in höhere Stages befördert werden, ohne dass die entsprechenden Aktivitäten stattgefunden haben. Das korrumpiert die Pipeline-Daten und führt zu Forecast-Bias. RevOps-Teams sollten CRM-Validierungsregeln einrichten, die Stage-Wechsel nur erlauben, wenn Pflichtfelder befüllt sind.
Prozess 4: Close-to-Onboarding (Kundenstartphase)
Der vierte Prozess beschreibt die Übergabe vom Vertrieb an Customer Success und den Onboarding-Prozess bis zur ersten aktiven Nutzung. Dieser Prozess ist direkt mit Early-Churn verbunden — schlechtes Onboarding ist die häufigste Ursache für Kundenverluste in den ersten 90 Tagen.
Was dieser Prozess kartieren muss:
- — Übergabe-Protokoll: Welche Informationen übergibt der AE an den CSM? Success-Plan, technische Anforderungen, Stakeholder-Map
- — Kickoff-SLA: Innerhalb welcher Frist muss das Kickoff-Meeting stattfinden? (Richtwert: 5 Werktage)
- — Onboarding-Milestones: Welche messbaren Schritte definieren erfolgreiches Onboarding? (z.B. erste Integration verbunden, erster Report erstellt)
- — Health-Score-Monitoring: Wie wird der Fortschritt des Onboardings gemessen? Welche Signale deuten auf At-Risk-Status hin?
- — Onboarding-Completion-Definition: Wann gilt das Onboarding als abgeschlossen? Welche Aktionen hat der Kunde selbst durchgeführt?
Häufiges Bottleneck: Unvollständige Übergabe-Dokumentation vom Vertrieb. CSMs erhalten häufig Kunden ohne ausreichenden Kontext über Kaufmotive, technische Anforderungen und intern zugesagte Feature-Roadmap-Punkte. RevOps sollte ein standardisiertes Übergabe-Dokument definieren, das der AE vor Abschluss ausfüllen muss.
Prozess 5: Onboarding-to-Expansion (Kundenwachstum)
Der fünfte Prozess beschreibt, wie Customer Success Expansion-Möglichkeiten identifiziert, qualifiziert und abschließt. Dieser Prozess ist der direkteste Hebel für Net Revenue Retention und wird in vielen Unternehmen am wenigsten systematisch kartiert.
Was dieser Prozess kartieren muss:
- — Expansion-Signal-Definition: Welche Aktivitätsmuster oder Nutzungssignale deuten auf Expansion-Bereitschaft hin?
- — Qualifizierungs-Rahmen: Wie wird ein Expansion-Signal zu einer qualifizierten Expansion-Opportunity?
- — Verantwortlichkeit: Liegt die Expansion-Verantwortung beim CSM oder beim AE? (Klärung vermeidet Reibung)
- — QBR-Prozess: Wie ist das Quarterly Business Review strukturiert? Welche Expansion-Gespräche werden dort geführt?
- — Renewal-Prozess: Wie weit vor dem Renewal-Datum beginnt der Verlängerungsprozess? Wer ist verantwortlich?
Häufiges Bottleneck: Expansion-Opportunities werden reaktiv statt proaktiv identifiziert. RevOps-Teams, die Health-Score-Monitoring und Nutzungsdaten mit CRM-Daten verbinden, können Expansion-Signale früh erkennen. Fairviews Churn-Detection und Pipeline-Visibility unterstützen diesen Prozess direkt.
Die 4 Schritte des Process-Mapping-Projekts
Ein Process-Mapping-Projekt für alle fünf Kernprozesse dauert typischerweise 4–6 Wochen und folgt einer strukturierten Abfolge.
Ist-Zustand dokumentieren
Interviews mit Vertretern aller beteiligten Funktionen: Marketing, SDR, AE, CS, Ops. Fragen Sie nach dem tatsächlichen Prozess — nicht dem offiziellen. Dokumentieren Sie Abweichungen, workarounds und informelle Übergaben.
Swim-Lane-Diagramme erstellen
Erstellen Sie für jeden der fünf Prozesse ein Swim-Lane-Diagramm mit einer Lane je Funktion. Markieren Sie Übergabepunkte explizit. Identifizieren Sie Punkte, an denen Verantwortlichkeiten unklar oder überlappend sind.
Bottlenecks und Gaps identifizieren
Überlagern Sie die Prozessdiagramme mit Conversion-Daten: Wo gehen Leads verloren? Wo verlängern sich Durchlaufzeiten? Priorisieren Sie die drei Bottlenecks mit dem größten Einfluss auf Revenue und beginnen Sie dort.
Soll-Zustand definieren und implementieren
Definieren Sie den verbesserten Prozess mit klaren Stage-Definitionen, SLAs und Pflichtfeldern. Implementieren Sie Validierungsregeln im CRM. Schulen Sie alle Beteiligten. Prüfen Sie die Auswirkungen auf Conversion-Raten nach 6–8 Wochen.
Process Maps als lebendes Dokument führen
Der größte Fehler nach einem Process-Mapping-Projekt ist, die erstellten Diagramme als statische Dokumentation zu behandeln. RevOps-Prozesse ändern sich, wenn sich das Unternehmen ändert — neue Produkte, neue Segmente, neue CRM-Konfigurationen. Eine Process Map, die 18 Monate nach ihrer Erstellung nicht aktualisiert wurde, beschreibt oft nicht mehr die Realität des Teams.
Legen Sie einen festen Rhythmus für die Überprüfung fest: vollständige Überprüfung aller fünf Prozesse einmal im Jahr; ad-hoc-Updates bei signifikanten Änderungen (CRM-Migration, neue Stage-Definitionen, Teamumstrukturierung). Weisen Sie jedem der fünf Prozesse einen Process Owner zu — eine Person, die für die Dokumentation, Überprüfung und Verbesserung verantwortlich ist.
Wenn Process Maps Teil der RevOps-Standarddokumentation werden — verlinkt aus dem CRM, referenziert in Onboarding-Materialien und regelmäßig in Reviews zitiert — entwickeln sie sich von einem einmaligen Projekt zu einem operativen Asset, das die gesamte GTM-Funktion transparenter und skalierbarer macht.
Häufige Fragen zu RevOps Process Mapping
Was ist Process Mapping im RevOps-Kontext?
Process Mapping im RevOps-Kontext bedeutet, die Abläufe zu dokumentieren, die einen Lead durch den gesamten Kundenlebenszyklus führen. Das Ziel ist, Verantwortlichkeiten, Übergaben und Bottlenecks sichtbar zu machen und dadurch gezielt verbessern zu können.
Was ist ein Swim-Lane-Diagramm?
Ein Swim-Lane-Diagramm visualisiert einen Prozess in horizontalen oder vertikalen Spuren, wobei jede Spur einer Funktion oder einem Team entspricht. In RevOps werden typischerweise Marketing, Vertrieb, Customer Success und Operations als separate Lanes dargestellt.
Welches ist das häufigste Bottleneck zwischen MQL und Opportunity?
Das häufigste Bottleneck ist die SLA-Verletzung beim Lead-Follow-up. Wenn qualifizierte MQLs nicht innerhalb von 24–48 Stunden kontaktiert werden, sinkt die Conversion-Rate signifikant. RevOps-Teams sollten automatische SLA-Überwachung und Eskalationsregeln einrichten.
Welche Tools eignen sich für RevOps Process Mapping?
Für einfache Prozessdiagramme eignen sich Lucidchart, Miro oder FigJam. Die eigentliche Prozessdokumentation sollte im CRM und im Ops-Wiki hinterlegt werden — nicht nur als Diagramm, das niemand mehr findet.
Wie oft sollten RevOps-Prozesse neu kartiert werden?
RevOps-Prozesse sollten jährlich vollständig überprüft und bei signifikanten Änderungen ad hoc aktualisiert werden. Häufige Auslöser: neues CRM, neues Segment, Umstrukturierung, neue Qualifizierungskriterien.
Verwandte Themen
Ihre fünf RevOps-Prozesse brauchen verlässliche Datenbasis.
Fairview verbindet CRM-, Finanz- und Werbedaten und zeigt, wo Leads verloren gehen, wo Pipeline stagniert und welche Übergaben verbessert werden müssen.