Auf dieser Seite
Ein Revenue Lifecycle ist keine Funnel-Grafik mit mehr Bezeichnungen.
Revenue-Lifecycle-Phasen sind definierte kommerzielle Zustände, die eine abgegrenzte Prozessinstanz von einem benannten Eintrittsereignis zu einem benannten Ergebnis, einem terminalen Abschluss oder einem am Beobachtungshorizont offenen Status führen. Jeder Zustand braucht Eintrittsnachweis, Verantwortung, Austritts- oder Fortsetzungsregel, Folgezustand und einen sichtbaren Fehlermodus.
Das ist anspruchsvoller, als „Marketing Qualified“ oder „Renewal“ in ein Dashboard aufzunehmen. Es macht den Lifecycle aber anpassbar: Zustände dürfen sich mit der Motion ändern, während der Nachweisvertrag prüfbar bleibt.
Was ist eine Revenue-Lifecycle-Phase?
Eine Lifecycle-Phase ist ein Zustand in einem definierten kommerziellen Prozess. Sie ist nicht dasselbe wie eine Funnel-Zählung, ein CRM-Feld, eine Vertriebsmethode oder eine Übergabe. Die Phase zeigt, wo sich die Prozessinstanz befindet. Die Eintrittsregel erklärt, warum sie dort sein darf. Die Austrittsregel beschreibt, welcher Nachweis den nächsten Zustand erlaubt. Die verantwortliche Rolle kann den Zustand prüfen oder ändern.
Reinartz et al. (2004) konzipieren und messen Customer Relationship Management als Prozess mit Initiierung, Pflege und Beendigung. Ihr Design ist nützlich, weil es den Lifecycle als messbares Objekt behandelt. Es legt nicht fest, dass jedes Unternehmen diese drei Bezeichnungen verwenden sollte oder dass sich ein Revenue Lifecycle aus einem CRM-Menü kopieren lässt.
Boulding et al. (2005) rahmen CRM breiter über die Wertschöpfung für Kunden und Unternehmen sowie über Akquisition, Bindung und Ausbau als getrennte Aufgaben. Daraus folgt eine zweite Grenze: Ein Lifecycle sollte zeigen, zu welchem kommerziellen Problem ein Zustand gehört, nicht nur, wo ein Datensatz in einem Bericht steht.
Warum ist ein Lifecycle nicht dasselbe wie ein Funnel?
Ein Funnel ist eine aggregierte Ansicht von Datensätzen, die in Zuständen beobachtet werden. Ein Lifecycle ist der definierte Pfad mit den Nachweisen hinter diesen Zuständen. Der Funnel kann beantworten, wie viele Datensätze an einem Datum in einem Zustand erscheinen. Der Lifecycle muss zusätzlich erklären, welches Ereignis sie aufgenommen hat, wer sie verantwortet, welcher Nachweis fehlt, welcher Übergang folgt und was offen bleibt.
Das ist praktisch. Ein Datensatz kann als „Opportunity“ gezählt werden, weil ein Phasenfeld geändert wurde, während bestätigter Bedarf, Entscheidungsweg oder akzeptierter kommerzieller Umfang fehlen. Ein Kunde kann als „Renewal“ erscheinen, während Vertrag, Nutzennachweis oder Entscheidungshorizont noch offen sind. Die Zählung ist nicht zwingend falsch. Sie ist als Lifecycle-Zustand unvollständig.
Der Beitrag zum Revenue-Prozess besitzt den detaillierten Übergabevertrag von der Freigabe durch den Absender bis zur Annahme durch den Empfänger. Diese Seite besitzt die größere Zustandsfolge um diese Schnittstelle. Der Beitrag zur Pipeline-Hygiene besitzt die Datensatzprüfung, bevor eine Opportunity in eine offene Pipelineansicht gelangt.
Welche Forschungsgrenzen gehören um den Lifecycle?
Jayachandran et al. (2005) konzipieren relationale Informationsprozesse als organisatorische Routinen, die für CRM wesentlich sind. In ihrer Darstellung hat Technologie eine unterstützende oder moderierende Rolle bei der Umsetzung dieser Prozesse. Die Schlussfolgerung für das Lifecycle-Design ist eng: Technologie kann Nachweise speichern oder weiterleiten, aber ein konfiguriertes System ist nicht selbst der kommerzielle Zustand.
Järvinen und Taiminen (2016) verbinden Marketing Automation, B2B-Content-Prozesse und Vertriebsprozesse in einer begrenzten Einzelfallstudie. Das akzeptierte Manuskript ist hilfreicher Kontext dafür, wie Content und Automation über einen Lifecycle hinweg liegen können. Es belegt weder eine universelle Automationsfolge noch ein allgemeines Konversionsergebnis.
Homburg et al. (2017) behandeln Customer Experience Management als organisatorisches und funktionsübergreifendes Umsetzungsproblem. Van Bruggen et al. (2010) behandeln Mehrkanaligkeit als Gestaltungs- und Managementproblem. Zusammen warnen die Quellen vor einem Lifecycle, der einer einzelnen Abteilung oder einem Kanal gehört, während sich der Kunde durch mehrere bewegt.
Der Lifecycle braucht deshalb eine verantwortliche Informationsrolle und eine Identitätsregel über Kanäle hinweg. Er braucht keine universelle Phasenliste.
Welche Felder machen einen Lifecycle-Zustand prüfbar?
| Zustand | Eintrittsnachweis | Verantwortung | Austritts- oder Annahmeereignis | Folgezustand | Fehlermodus |
|---|---|---|---|---|---|
| Nicht identifizierte Nachfrage | Benannter Auslöser, Quelle und zulässige Population | Demand-Verantwortung | Bedarfs- oder Fit-Nachweis angenommen | Qualifiziertes Konto | Aktivität wird ohne zulässige Einheit gezählt |
| Qualifiziertes Konto | Fit-, Bedarfs- und Buying-Context-Nachweis | SDR- oder BDR-Verantwortung | Kommerzieller Kontext vom Empfänger angenommen | Aktive Opportunity | ICP-Etikett ersetzt den Nachweis |
| Aktive Opportunity | Konto, Problem, Entscheidungsweg und aktueller Phasennachweis | Vertriebsverantwortung | Angebot, Vertrag oder ausdrücklich dokumentierte Nichtentscheidung | Kunde oder beendete Beziehung | Phasenetikett ändert sich ohne Übergangsereignis |
| Kunde oder Implementierung | Angenommener Vertrag und Lieferumfang | Kunden- oder Delivery-Verantwortung | Erster Wert, Aktivierung oder Abschluss der Implementierung | Aktiviert oder implementiert | Übergabe wird ohne abgestimmten Umfang angenommen |
| Aktiviert oder implementiert | Erster Wert oder Abschluss der Implementierung | Kunden- oder Delivery-Verantwortung | Fortgesetzte Nutzung, Verlängerung oder Nachweis eines terminalen Verlusts nach der definierten Bindungsfrist | Gebundene, ausgebaute oder beendete Beziehung | Aktivierung wird als Bindung oder Ausbau gezählt |
| Ausbau oder Verlängerung | Nutzungs-, Wert-, Vertrags- oder Verlängerungsnachweis | Account-Verantwortung | Entscheidung über Verlängerung, Ausbau, Schrumpfung oder Rückgang am benannten Horizont | Gebundene, ausgebaute oder verlorene Beziehung | Verlängerung wird vor dem Entscheidungshorizont gezählt |
| Am Beobachtungshorizont offen | Aktueller Zustandsnachweis und Zensurdatum ohne terminales Ergebnis | Prozessverantwortung | Beobachtungsfenster endet ohne ausdrückliches Abschlussereignis | Bleibt offen oder zensiert bis zu neuer Evidenz | Zensur wird als Abschluss oder Verlust gezählt |
| Beendete Beziehung | Ausdrücklicher Nachweis von Abschluss, Verlust oder Kündigung | Prozessverantwortung | Datensatz behalten, erst nach einem ausdrücklichen neuen Ereignis wieder öffnen oder ausdrücklich ausschließen | Nur definierter Wiedereintritt | Abschluss verdeckt einen offenen oder zurückgegebenen Fall |
Abbildung 1Karte der Revenue-Lifecycle-Zustände
Jeder Zustand benennt den Eintrittsnachweis, die Verantwortung, das Austrittsereignis, den Folgezustand und den Fehlermodus, der sichtbar bleiben sollte.
Quelle: Boulding et al. (2005), Reinartz et al. (2004), Jayachandran et al. (2005), Järvinen und Taiminen (2016), Homburg et al. (2017) sowie Van Bruggen et al. (2010). Die Zeilen sind das synthetische Arbeitsmodell des Autors.
Diese Tabelle ist ein Gestaltungsobjekt und keine Behauptung, dass jedes Unternehmen diese acht Zustände braucht. Der Test lautet, ob eine prüfende Person rekonstruieren kann, warum eine Prozessinstanz in einen Zustand gelangt ist, wer sie verantwortet, welcher Nachweis den Folgezustand erlaubt und was bei einem Fehlerpfad passiert.
Die Zeile Am Beobachtungshorizont offen ist ein Status und keine terminale Phase. Sie hält einen
rechtszensierten Datensatz getrennt von einer beendeten oder verlorenen Beziehung. Ein Wiedereintritt
braucht nach einem Abschluss ein neues, ausdrückliches Ereignis; ein offener Datensatz hat diesen
Übergang noch nicht verdient.
Wie sollten zurückgegebene und gehaltene Zustände erscheinen?
Zurückgegebene und gehaltene Zustände sollten neben angenommenen Zuständen sichtbar sein. Ein zurückgegebenes Konto kann einen Entscheidungsweg vermissen. Eine gehaltene Opportunity kann Rechts- oder Preisnachweise benötigen. Eine überarbeitete Implementierung kann einen neuen Umfang haben und trotzdem dieselbe Prozessinstanz bleiben. Ein ausgeschlossener Datensatz kann außerhalb der Motion liegen, ohne ein gescheiterter Kunde zu sein.
Der Datensatz sollte Grund, Verantwortung, Datum, Prüf- oder Ablauftrigger und Disposition bewahren. Ein finaler Phasenwert reicht nicht, weil er den Pfad entfernt, der den aktuellen Zustand erklärt. Der Beitrag zum Lead Routing besitzt die Zuweisung vor einer kommerziellen Übergabe; diese Seite hält angenommene, zurückgegebene und gehaltene Zustände über den Lifecycle hinweg sichtbar.
Welche Grenzen sollten vor einem Lifecycle-Dashboard feststehen?
Legen Sie diese Grenzen fest, bevor Sie Phasen zählen:
- die Prozesseinheit, etwa Konto, Opportunity, Vertrag, Kunde oder benannte Übergabe;
- die zulässige Population und Ausschlussregel;
- das Eintrittsereignis und den Nachweis;
- Verantwortung und Annahmeregel für jeden Zustand;
- Austrittsereignis und Folgezustandsregel;
- Beobachtungsdatum, Zeitzone und Ergebnishorizont;
- den Join-Schlüssel über Kanäle, Systeme oder Entitäten; und
- den Umgang mit zurückgegebenen, gehaltenen, überarbeiteten, ausgeschlossenen und am Horizont offenen Zuständen.
Diese Grenzen verhindern, dass ein Phasen-Dashboard seine Bedeutung ändert, während die Bezeichnungen gleich bleiben. Sie halten den Lifecycle auch vom Beitrag zur Kohortenanalyse getrennt, der einen altersbezogenen Populationsvergleich besitzt und keine universelle Revenue- Zustandslogik.
Können Lifecycle-Phasen bessere Umsatzleistung beweisen?
Nein. Ein Lifecycle-Dashboard kann unter seinen definierten Grenzen Zustandszusammensetzung, Übergangszeiten, angenommene Arbeit, zurückgegebene Arbeit oder offene Fälle beschreiben. Es kann nicht allein beweisen, dass das Lifecycle-Design Konversion, Bindung, Kundenwert oder Umsatz verursacht hat.
Eine Lifecycle-Änderung kann verändern, welche Datensätze in einen Zustand gelangen, wer sie annimmt, wann sie austreten oder welche Fälle sichtbar bleiben. Ein anderer Dashboard-Gesamtwert kann deshalb eine Definitions- oder Instrumentierungsänderung widerspiegeln und nicht ein kommerzielles Ergebnis. Für eine kausale Aussage müssen Intervention, zulässige Population, Vergleich, Ergebnis und Horizont definiert sein.
Wie sollte ein Team seinen Revenue Lifecycle prüfen?
Beginnen Sie mit einer Prozessfamilie und einem Beobachtungshorizont. Wählen Sie aus jeder Phase eine Stichprobe von Datensätzen. Fragen Sie für jeden Datensatz:
- welches Ereignis ihn aufgenommen hat;
- welcher Nachweis den aktuellen Zustand stützt;
- wer die Entscheidung verantwortet;
- welches Ereignis den Folgezustand erlaubt;
- ob eine andere Rolle ihn angenommen, gehalten, zurückgegeben oder ausgeschlossen hat;
- ob der Datensatz terminal, am Horizont offen oder zensiert oder für einen ausdrücklichen Wiedereintritt zulässig ist; und
- welche Ergebnis- oder Zensurregel gilt.
Vergleichen Sie anschließend die schriftlichen Regeln mit den Datensätzen, die das Dashboard zählt. Wenn ein Zustand nicht rekonstruierbar ist, behalten Sie ihn als offenen Zustand und verbessern Sie den Nachweispfad, bevor Sie eine weitere Phase hinzufügen. So wird der Lifecycle zu einem prüfbaren Arbeitsmodell statt zu einer längeren Funnel-Liste.
Die belastbare Schlussfolgerung ist eng: Ein Revenue Lifecycle ist eine versionierte Karte kommerzieller Zustände und Nachweise. Sein Wert entsteht durch sichtbare Grenzen für Eintritt, Verantwortung, Austritt, Ausnahme, Identität und Ergebnis, nicht durch die Anzahl der Phasen im Dashboard.
Quellen
- Boulding, W., Staelin, R., Ehret, M., & Johnston, W. J. (2005). A customer relationship management roadmap: What is known, potential pitfalls, and where to go. Journal of Marketing, 69(4), 155–166. https://doi.org/10.1509/jmkg.2005.69.4.155
- Homburg, C., Jozić, D., & Kuehnl, C. (2017). Customer experience management: Toward implementing an evolving marketing concept. Journal of the Academy of Marketing Science, 45, 377–401. https://doi.org/10.1007/s11747-015-0460-7
- Jayachandran, S., Sharma, S., Kaufman, P., & Raman, P. (2005). The role of relational information processes and technology use in customer relationship management. Journal of Marketing, 69(4), 177–192. https://doi.org/10.1509/jmkg.2005.69.4.177
- Järvinen, J., & Taiminen, H. (2016). Harnessing marketing automation for B2B content marketing. Industrial Marketing Management, 54, 164–175. Accepted manuscript held. https://doi.org/10.1016/j.indmarman.2015.07.002
- Reinartz, W., Krafft, M., & Hoyer, W. D. (2004). The customer relationship management process: Its measurement and impact on performance. Journal of Marketing Research, 41(3), 293–305. https://doi.org/10.1509/jmkr.41.3.293.35991
- Van Bruggen, G. H., Antia, K. D., Jap, S. D., Reinartz, W. J., & Pallas, F. (2010). Managing marketing channel multiplicity. Journal of Service Research, 13(3), 331–340. https://doi.org/10.1177/1094670510375601
