Revenue Funnel Stages: Eine vollständige Lifecycle-Karte vom Lead bis zur Expansion

Revenue-Funnel-Stufen definieren, wie sich eine Person, ein Account, eine Opportunity und ein Kunde durch das Revenue-System bewegen.

Eine Sales-Pipeline ist nur ein Teil dieser Karte. RevOps braucht den vollständigen Lifecycle: Lead-Erfassung, Qualifizierung, Sales-Annahme, Opportunity-Erstellung, Closed-Won, Onboarding, Verlängerung und Expansion.

Forresters Modell der RevOps-Verantwortlichkeiten ist hier hilfreich, weil es RevOps über den gesamten kommerziellen Motor hinweg einordnet, nicht nur im Sales-Reporting. McKinseys Forschung zu B2B-Wachstum bekräftigt zudem die Notwendigkeit verbundener kommerzieller Systeme, da Käuferverhalten und Wachstumsbewegungen komplexer werden.

Die Funnel-Stufenkarte ist die operative Sprache für dieses System.

Wichtige Fakten für den Betrieb

• Revenue-Funnel-Stufen sollten den vollständigen Lifecycle abdecken: Demand, Qualifizierung, Opportunity, Kunden-Onboarding, Verlängerung und Expansion.
• Fügen Sie eine Stufe nur hinzu, wenn sie Ownership, erforderliche Aktion, Reporting, Kundenstatus oder eine Management-Entscheidung verändert.
• Jede Stufe braucht Eintritts- und Austrittskriterien, einen Owner, erwartete Alterung, erforderliche Daten und einen Ausnahmepfad.
• Stufennamen sind weniger wichtig als Evidenz. Eine Stufe ist nur nützlich, wenn Manager prüfen können, ob ein Datensatz dort tatsächlich hingehört.

Eine praktische Stufenkarte

Jede Stufe braucht Eintritts- und Austrittskriterien, einen Owner, Pflichtfelder und ein SLA. Ohne diese ist die Stufe nur ein Etikett.

Warum Lifecycle-Stufen wichtig sind

Lifecycle-Stufen sind nicht nur CRM-Status. Sie definieren, wer den Datensatz besitzt, welche Aktion als Nächstes folgen sollte und welchen Kennzahlen Führungskräfte vertrauen können.

Sind Lifecycle-Stufen schwach:

• Streiten Marketing und Sales über die Lead-Qualität.
• Sind SDRs unsicher, welche Datensätze sie bearbeiten sollen.
• Erstellt Sales Opportunities zu früh.
• Enthalten Forecast-Reports Deals mit schwacher Evidenz.
• Erhält CS Kunden ohne Kontext zum Ergebnis.
• Kann Finance Funnel-Annahmen nicht mit der Umsatzplanung verknüpfen.

Sind Lifecycle-Stufen klar, weiß jedes Team, was ein Datensatz bedeutet und was als Nächstes passieren sollte.

Designprinzipien für Stufen

Nutzen Sie diese Prinzipien beim Gestalten der Karte:

Das Ziel ist nicht, jede Nuance abzubilden. Das Ziel ist, Stufen zu schaffen, die Entscheidungen unterstützen.

Wann eine Stufe hinzugefügt oder entfernt wird

Fügen Sie keine Stufen hinzu, nur weil Teams mehr Reporting-Detail wollen. Fügen Sie eine Stufe hinzu, wenn das Geschäft eine andere operative Aktion braucht.

Gute Gründe für eine neue Stufe:

• Die Ownership wechselt zwischen Teams.
• SLA oder Reaktionserwartung ändert sich.
• Erforderliche Daten ändern sich.
• Forecast- oder Planungsbehandlung ändert sich.
• Der Kundenstatus ändert sich.
• Die Manager-Prüfung braucht einen eigenen Checkpoint.

Schwache Gründe:

• Ein Team möchte mehr Aktivitätsetiketten sehen.
• Eine CRM-Vorlage enthält die Stufe.
• Eine Führungskraft möchte einen Dashboard-Ausschnitt ohne Workflow-Änderungen.
• Reps nutzen informelle Sprache, die die Ownership nicht beeinflusst.

Stufen sollten auch entfernt werden. Verändert eine Stufe keine Aktion mehr, erzeugt sie Verwirrung oder hat sie Daten geringer Qualität, führen Sie sie in ein einfacheres Modell zusammen. Ein einfacherer Lifecycle, den Manager durchsetzen, ist besser als ein detaillierter Lifecycle, dem niemand vertraut.

Ownership-Modell für Stufen

Jede Stufe sollte einen primären operativen Owner haben, auch wenn mehrere Teams beitragen.

Dieses Ownership-Modell verhindert, dass Lifecycle-Stufen zu Etiketten ohne Verhalten werden. Besitzt niemand die Bewegung, bleiben veraltete Datensätze veraltet. Besitzt niemand die Kriterien, werden Stufenwechsel subjektiv. Besitzt niemand die Reporting-Auswirkung, driften Dashboards.

RevOps sollte das Ownership-Modell zusammen mit der Stufenkarte veröffentlichen. Manager sollten wissen, welches Team handelt, welche Felder wichtig sind und welcher Ausnahmepfad gilt, wenn ein Datensatz nicht in den Standardablauf passt.

Lead- und Demand-Stufen

Lead-Stufen sollten rohe Nachfrage von qualifizierter Nachfrage trennen.

Häufige Stufen:

Die wichtigste Regel ist, dass MQL nicht bedeuten sollte „Marketing mag diesen Lead". Es sollte bedeuten, dass der Datensatz eine vereinbarte Schwelle für die Sales-Prüfung erreicht.

Für tieferes Übergabe-Design siehe Lead to Opportunity Process.

Stufen der Sales-Pipeline

Opportunity-Stufen sollten den Kaufprozess beschreiben, nicht die Verkäuferaktivität.

Schwache Stufen klingen wie:

• Kontaktiert
• Follow-up
• Demo durchgeführt
• Angebot gesendet

Das können nützliche Aktivitäten sein, aber sie belegen nicht immer die Deal-Qualität.

Stärkere Stufen nutzen Evidenz:

Jedes Unternehmen benennt Stufen unterschiedlich. Wichtig ist, dass Bewegung Evidenz erfordert.

Kunden-Lifecycle-Stufen

Unternehmen mit wiederkehrendem Umsatz brauchen Stufen nach Closed-Won.

Häufige Kundenstufen:

Das verknüpft Revenue-Stufen mit RevOps and Customer Success. Ohne diese Stufen feiert das Unternehmen möglicherweise neue Bookings, während es Risiken im Kundenbestand übersieht.

Account- vs. Personen- vs. Opportunity-Stufen

Viele Teams verwechseln Objektstufen.

Eine Person kann ein Lead sein. Ein Account kann Ziel, aktiv, Kunde oder abgewandert sein. Eine Opportunity kann qualifiziert, spätphasig, Closed-Won oder Closed-Lost sein. Ein Kunde kann Onboarding, aktiv, Verlängerungsrisiko oder Expansionskandidat sein.

RevOps sollte definieren, welches Objekt welche Stufe besitzt:

Das ist wichtig, weil Reporting bricht, wenn Teams Objekte vermischen. Ein Lead-Konversionsbericht sollte nicht als Account-Fortschrittsbericht genutzt werden. Ein Opportunity-Forecast sollte nicht die Verlängerungsgesundheit ersetzen.

Pflichtfelder nach Stufe

Jede Stufe sollte eine kleine Anzahl an Pflichtfeldern haben.

Beispiele:

Halten Sie Pflichtfelder schlank. Zu viele Pflichtfelder erzeugen schlechte Daten. Nutzen Sie Required Fields vs Useful Fields für die Field Governance.

Rhythmus der Stufenüberprüfung

Überprüfen Sie Stufen vierteljährlich oder wenn sich die GTM-Bewegung ändert.

Auslöser für die Überprüfung:

• Neues Segment oder neue Produktlinie
• Wechsel von sales-led zu product-led Bewegung
• Neue Verlängerungs- oder Expansionsbewegung
• Größere Änderung an CRM oder Marketing-Automatisierung
• Wiederkehrende Streitigkeiten über Definitionen
• Diskrepanz zwischen Forecast und Board-Reporting

Die Stufenkarte sollte stabil genug fürs Reporting und flexibel genug sein, um zum Geschäft zu passen.

Checkliste für Einsatzbereitschaft

Bevor Sie die Lifecycle-Karte veröffentlichen, bestätigen Sie:

• Jede Stufe hat einen primären Owner.
• Jede Stufe hat Eintritts- und Austrittskriterien.
• Jede Stufe hat Pflichtfelder, die an Entscheidungen geknüpft sind.
• Stufenbewegung kann auditiert werden.
• Stufen nach dem Verkauf sind enthalten.
• Finance versteht, welche Stufen die Planung beeinflussen.
• Dashboards nutzen dieselben Definitionen.
• Manager wissen, wie sie mit Ausnahmen umgehen.

Ist die Antwort nein, ist die Stufenkarte nicht bereit für Governance.

So führen Sie neue Stufen ein

Lifecycle-Stufen zu ändern ist riskant, weil es Reports, Workflows, Automatisierungen, Dashboards und Gewohnheiten beeinflusst.

Ein praktischer Rollout sollte enthalten:

1. Die aktuellen Stufen abbilden und identifizieren, wofür jede genutzt wird.
2. Das neue Stufenmodell und den Grund für jede Änderung definieren.
3. Alte Stufen den neuen Stufen zuordnen.
4. Dashboards, Workflows und Integrationen prüfen, die von Stufenwerten abhängen.
5. Die Auswirkung mit Marketing, Sales, CS, Finance und Systemen überprüfen.
6. Manager zu Eintritts- und Austrittskriterien schulen.
7. Datensätze sorgfältig migrieren und Annahmen dokumentieren.
8. Die Stufenbewegung im ersten Monat überwachen.

Benennen Sie Stufen nicht beiläufig um. Eine kleine Etikettenänderung kann die Reporting-Historie brechen oder Teams verwirren.

Alterung von Stufen

Jede Stufe sollte eine erwartete Altersspanne haben.

Die Stufenalterung hilft Managern zu sehen, wo Datensätze feststecken:

Der richtige Schwellenwert hängt von der Bewegung ab. Ein Inbound-Lead mit hoher Geschwindigkeit altert vielleicht in Stunden. Eine Enterprise-Opportunity altert vielleicht in Wochen. Wichtig ist, den Schwellenwert zu definieren, statt veraltete Datensätze als normal zu behandeln.

Closed-Lost- und disqualifizierte Stufen

Eine vollständige Lifecycle-Karte umfasst negative Ergebnisse.

Disqualifiziert, abgelehnt, Closed-Lost, abgewandert und Kontraktion sind keine Fehlschläge, die man verstecken sollte. Es sind Lernpunkte.

RevOps sollte Grundcodes standardisieren:

• Schlechte Passung
• Kein Budget
• Keine Entscheidungsbefugnis
• Kein klarer Pain
• Timing
• Wettbewerber
• Fehlendes Feature
• Duplikat
• Nicht erreichbar
• Implementierungsrisiko

Diese Gründe sollten in zukünftige Entscheidungen einfließen. Ist „schlechte Passung" häufig, ändern Sie das Targeting. Ist Timing häufig, verbessern Sie das Nurturing. Ist „fehlendes Feature" häufig, leiten Sie die Erkenntnis an Product weiter. Ist „keine Entscheidungsbefugnis" häufig, verbessern Sie die Discovery.

Source-of-Truth-Regeln

Die Lifecycle-Karte sollte festlegen, wo jede Stufe liegt.

Zum Beispiel:

• Der Lead-Status liegt im Lead- oder Kontaktdatensatz.
• Der Account-Lifecycle liegt im Account.
• Die Sales-Stufe liegt in der Opportunity.
• Der Kunden-Lifecycle liegt im Account- oder Kunden-Objekt.
• Verlängerungs- und Expansionsstatus können je nach System in Opportunity-, Account- oder Subscription-Objekten liegen.

Halten Sie das schriftlich fest. Wissen Teams nicht, welches Objekt maßgeblich ist, werden Dashboards uneinig sein.

Für verwandte Governance siehe Revenue Operations System of Record.

Qualitätsprüfung der Stufenkarte

Prüfen Sie die Karte anhand echter Datensätze.

Wählen Sie zehn aktuelle Leads, zehn Opportunities, fünf Closed-Won-Deals, fünf Accounts mit Verlängerungsrisiko und fünf Expansionskandidaten aus. Fragen Sie, ob jeder Datensatz in der richtigen Stufe ist und ob die nächste Aktion klar ist.

Sind sich Prüfer uneinig, ist die Definition nicht klar genug. Ist die nächste Aktion unklar, ist die Stufe nicht nützlich. Sind Pflichtfelder leer oder mit Unsinnswerten befüllt, braucht das Datenmodell Arbeit.

Diese Prüfung auf Datensatzebene ist besser, als abstrakt über Stufennamen zu diskutieren.

Häufige Fehler

Zu viele Stufen. Wird jeder kleine Status zur Lifecycle-Stufe, wird das Reporting unruhig.

Keine Austrittskriterien. Eine Stufe ohne Evidenz wird subjektiv.

Reiner Sales-Lifecycle. Unternehmen mit wiederkehrendem Umsatz brauchen auch Kunden- und Expansionsstufen.

Tool-getriebene Stufen. Nutzen Sie keine Stufe nur, weil die CRM-Vorlage sie enthält.

Kein Owner für veraltete Stufen. Verweilt ein Datensatz zu lange, sollte jemand wissen, wer handelt.

Ignorieren von Closed-Lost- und Churn-Daten. Verlorene und abgewanderte Datensätze zeigen dem Unternehmen, welche Stufen schlecht qualifiziert waren.

Unterschiedliche Stufenkarten je Team. Lokale Stufen können existieren, aber das Executive-Reporting braucht einen gemeinsamen Lifecycle.

Beispiel für eine Lifecycle-Policy

Eine einfache Policy kann die Karte leichter durchsetzbar machen:

Eine Lifecycle-Stufe darf nur hinzugefügt werden, wenn sie Ownership, erforderliche Aktion, Reporting oder Kundenstatus verändert. Jede Stufe muss Eintrittskriterien, Austrittskriterien, einen Owner, erforderliche Daten, erwartete Alterung und einen Ausnahmepfad haben. Im Executive-Reporting genutzte Stufen müssen über die RevOps-Governance genehmigt und im Data Dictionary dokumentiert werden.

Diese Policy verhindert Stufen-Wildwuchs.

Checkliste für Stufenänderungen

Fragen Sie vor einer Stufenänderung:

• Welche Reports nutzen diese Stufe?
• Welche Workflows oder Automatisierungen hängen davon ab?
• Welche Teams erfassen oder aktualisieren sie?
• Welche historischen Vergleiche brechen?
• Welche Felder werden verpflichtend oder optional?
• Welche Schulung oder Manager-Prüfung ändert sich?
• Welche Dashboards brauchen aktualisierte Definitionen?

Die meisten Stufenänderungen sind teurer, als sie aussehen. RevOps sollte diese Kosten sichtbar machen, bevor die Änderung genehmigt wird.

Praktische Empfehlung

Beginnen Sie mit einer einfachen, vollständigen Lifecycle-Karte und fügen Sie Detail nur dort hinzu, wo Entscheidungen es erfordern.

Für viele B2B-Unternehmen sollte die erste Version abdecken:

• Erfasster Lead
• MQL
• SQL
• Opportunity
• Closed-Won
• Onboarding
• Aktiver Kunde
• Verlängerungsrisiko
• Expansionskandidat

Das reicht, um Akquisition, Sales, Customer Success und Planung zu verknüpfen. Detailliertere Stufen können später hinzugefügt werden, wenn das Unternehmen Belege hat, dass sie das Management verbessern, nicht nur das Reporting-Detail.

Die beste Stufenkarte ist auf gute Weise unspektakulär. Führungskräfte verstehen sie, Manager können sie durchsetzen, Systeme können sie unterstützen, und neue Mitarbeitende können sie ohne private Erklärungen lernen. Braucht die Karte ständige Interpretation, ist sie noch nicht fertig.

Governance-Review-Paket für Stufen

Ein Lifecycle-Stufen-Review sollte mehr zeigen als die Liste der Stufen.

Enthalten Sie:

• Stufenname und Definition.
• Eintrittskriterien.
• Austrittskriterien.
• Primärer Owner.
• Pflichtfelder.
• SLA- oder Timing-Regel.
• Ausnahmepfad.
• Dashboard-Auswirkung.
• Auswirkung auf nachgelagerte Übergaben.

Dieses Paket hält Stufenänderungen praxisnah. Verändert eine vorgeschlagene Stufe weder Ownership, Evidenz, Timing, Reporting noch Kundenübergabe, verdient sie vielleicht keine Existenz. Zusätzliche Stufen sollten Mehrdeutigkeit reduzieren, nicht nur Etiketten hinzufügen.

FAQ

Wie viele Revenue-Funnel-Stufen sollten wir haben?

Nutzen Sie so wenige wie nötig, um Ownership und Entscheidungen klar zu machen. Die meisten B2B-Unternehmen können mit 8 bis 10 Lifecycle-Stufen beginnen.

Wer besitzt die Revenue-Funnel-Stufen?

RevOps sollte den gesamten Lifecycle steuern, während fachliche Leiter für die Ausführung in ihren Stufen verantwortlich sind.

Mehr erfahren

• Funnel Governance
• Lead to Opportunity Process
• Opportunity to Customer Process
• Customer to Expansion Process