Wie übergeben Sie einen gewonnenen Deal an das Team, das ihn umsetzt?

01Das Geschäftsproblem

Ein Deal wird abgeschlossen. Nun muss etwas gebaut, konfiguriert, migriert oder geschult werden, bevor der Kunde irgendeinen Nutzen aus dem Gekauften zieht – und die Personen, die das tun, sind nicht die, die es verkauft haben.

Meist findet die Übergabe hier statt:

• Ein Gespräch oder eine Nachricht in einem Kanal und eine Tabelle, die das Umsetzungsteam privat pflegt.
• Was auch immer der Vertriebsmitarbeiter zufällig in die Deal-Notizen geschrieben hat, und das ist nie das, was das Umsetzungsteam wissen muss.
• Ein Startdatum, auf das sich niemand einigt, weil „gewonnen“ und „startbereit“ verschiedene Ereignisse sind, getrennt durch eine Rechnung.

Die Folgen sind vorhersehbar und teuer. Niemand kann beantworten, wie viele Kunden sich gerade mitten in der Implementierung befinden oder welche davon überfällig sind, weil die Antwort in einer Tabelle steckt. Der Support erfährt, dass ein Kunde live gegangen ist, wenn dieser Kunde sein erstes Ticket eröffnet. Und die eigenen Berichte des Vertriebsteams verschlechtern sich unbemerkt, weil die Deals, die es abgeschlossen hat, Monate später noch in seiner Pipeline liegen.

02Warum der naheliegende Ansatz scheitert

Umsetzungsphasen an die Vertriebspipeline anhängen

Das ist der erste Instinkt, und er ist der teure. Die Pipeline hat schon Phasen, der Deal-Datensatz existiert bereits, also werden die Umsetzungsphasen angehängt: Gewonnen → Einrichtung → Schulung → Geliefert.

Das verfälscht jede Pipeline-Kennzahl gleichzeitig, denn eine Pipeline misst einen Lebenszyklus und trägt nun zwei:

• Der Verkaufszyklus wird zu Verkaufszeit plus Umsetzungszeit. Ein im März abgeschlossener und im Juli live gegangener Deal weist einen viermonatigen Zyklus aus, auf den kein Vertriebsmitarbeiter Einfluss hatte.
• Die Konversionsrate verliert jede Aussagekraft, weil Datensätze die Pipeline aus Umsetzungsgründen verlassen, nicht aus Vertriebsgründen.
• Die gewichtete Prognose zählt zugesicherten Umsatz, als würde er noch gewonnen.
• Die Verweildauer in den Phasen – der Bericht, mit dem alle festhängende Deals finden – füllt sich mit Datensätzen, die nicht festhängen, sondern lediglich umgesetzt werden.

Außerdem zwingt es zwei Teams einen Feldsatz und einen Verantwortlichen auf. Der Vertriebsmitarbeiter behält einen Datensatz, mit dem er nichts mehr tut; das Umsetzungsteam erbt ein Formular voller Felder zu Wettbewerbern und Rabattfreigaben.

Stattdessen am Account verfolgen

Besserer Instinkt, immer noch die falsche Form. Der Account ist der Kunde, und ein Kunde kann mehr als einmal kaufen – ein zweites Projekt, ein Upsell, der eine eigene Konfiguration braucht. Ein Umsetzungsstatus am Account kann nur ein Engagement beschreiben, also überschreibt das zweite das erste, und die Historie ist weg.

Eine Aufgabenliste

Aufgaben sind das richtige Werkzeug für Schritte und das falsche für einen Lebenszyklus. Eine Checkliste aus zehn Aufgaben kann Ihnen nicht sagen, in welcher Phase sich ein Projekt befindet, lässt sich nicht als Trichter auswerten und kennt keinen Unterschied zwischen einem überfälligen Projekt und einer überfälligen Aufgabe.

03Datenmodell – zwei Pipelines, eine Beziehung

Die Umsetzung bekommt ihre eigene Pipeline, mit eigenen Phasen, einem eigenen Verantwortlichen und einem eigenen Feldsatz. Die gewonnene Vertriebs-Opportunity wird dorthin geklont.

In Coevera ist ein Opportunity-Typ eins zu eins einer Pipeline zugeordnet, eine zweite Pipeline bedeutet also zwangsläufig einen zweiten Typ – was hier praktisch ist, denn genau diese Trennung wollen Sie: Ein Umsetzungsdatensatz ist etwas anderes als ein Vertriebsdatensatz, mit einem anderen Formular.

Quelle. Coevera-Hilfecenter, Adding another pipeline.

Die Phasen beschreiben die Umsetzung, nicht den Verkauf

Der Produktivaufbau, auf dem dies beruht, verwendet vier, und die Form lässt sich verallgemeinern:

Beachten Sie die erste Phase. Gewonnen und startbereit sind verschiedene Ereignisse, meist getrennt durch eine Rechnung, und dieser Lücke eine eigene Phase zu geben verhindert, dass sich die Warteschlange des Umsetzungsteams mit Arbeit füllt, die es nicht beginnen kann.

Bedingt klonen

Nicht jeder gewonnene Deal muss umgesetzt werden. Der Klon löst nur aus, wenn der Deal eine tatsächliche Leistung enthält – eine Einrichtung, eine Schulung, eine Datenmigration, ein Kontingent an Beratungsstunden. Eine reine Lizenzverlängerung erzeugt keinen Umsetzungsdatensatz und erscheint nie in der Warteschlange dieses Teams.

Diese eine Bedingung macht den Unterschied zwischen einer Umsetzungspipeline, der das Team vertraut, und einer, die es ignoriert, weil sie voller Dinge ist, die nicht seine Arbeit sind.

Verworfene Alternativen

• Eine benutzerdefinierte Entität für das Projekt statt eines zweiten Opportunity-Typs. Vertretbar, und es kostet Sie die Pipeline: Phasen, eine Trichteransicht, Verweildauer in den Phasen und prognoseartige Berichte gibt es bei einer Opportunity umsonst, bei einer benutzerdefinierten Entität müssen sie nachgebaut werden. Wählen Sie das nur, wenn die Umsetzung wirklich keinen Phasenverlauf hat – siehe Blueprint 003 für diese Entscheidung.
• Den Datensatz zwischen Pipelines verschieben statt zu klonen. Dann verliert die Vertriebspipeline den Deal, den sie abgeschlossen hat, und historische Vertriebsberichte ändern sich rückwirkend jedes Mal, wenn etwas umgesetzt wird.
• Ein Datensatz, zwei Statusfelder – ein Vertriebsstatus und ein Umsetzungsstatus an derselben Opportunity. Jeder Bericht, jede Ansicht und jeder Prozess muss dann wissen, welches Feld ihn interessiert, und die Pipeline zeigt trotzdem nur eines davon.

04Konfiguration auf Feldebene

Der Umsetzungsdatensatz braucht einen kleinen Satz von Feldern, mit denen der Vertriebsdatensatz nichts anfangen kann.

05Automatisierung & Logik

Der Klon und ein Prozess pro Quellpipeline

Der Klon löst aus, wenn der Status der Vertriebs-Opportunity zu gewonnen wird, gefiltert auf Deals, die eine Leistung enthalten. Er legt den Umsetzungsdatensatz in der ersten Phase an, kopiert die Basisfelder, wendet die Standardmengen pro Leistung an und sendet dem Kunden eine Bestätigung, deren Inhalt davon abhängt, was er gekauft hat.

Deals können aus mehr als einer Vertriebspipeline kommen – typischerweise Neugeschäft und Upsell. Der Produktivbestand verwendet einen Schwesterprozess pro Quellpipeline statt eines Prozesses mit zusammengesetzter Bedingung. Etwas mehr Wartung, und es lohnt sich: Jeder ist für sich lesbar, jeder lässt sich unabhängig deaktivieren, und keiner entwickelt eine Bedingung, die niemand mehr gefahrlos bearbeiten kann.

Go-live als Auffächerung behandeln, nicht als einen Prozess

Wenn ein Projekt live geht, müssen mehrere voneinander unabhängige Dinge geschehen. Sie als einen Prozess zu schreiben ergibt etwas, das in einem Jahr niemand mehr anfasst. Sie als vier zu schreiben ergibt vier Dinge, die sich unabhängig lesen, deaktivieren und erneut ausführen lassen:

Den dritten vergessen Teams, und er ist die eigentliche Übergabe. Mit dem Abschluss der Umsetzung ist die Geschichte nicht zu Ende: Wer das erste Support-Ticket dieses Kunden beantwortet, muss wissen, was implementiert wurde, und eine Benachrichtigung mit dem Umfang verhindert, dass diese Person bei null anfängt.

Der vierte löst bewusst am Tag danach aus statt am selben Tag. Der Go-live-Tag ist hektisch, und ein Folgeimpuls kommt besser an, sobald der Kunde das Ganze benutzt hat.

Die Frist nach Typ verzweigen, nicht nach Konvention

Dasselbe Feld braucht je nach Art des Engagements eine andere Berechnung – ein Projekt zählt ab dem Go-live, ein Kontingent an Beratungsstunden zählt ab dem Verkauf und verfällt, ob es genutzt wurde oder nicht. Zwei Zweige in einem Prozess, gesteuert vom Feld für die Implementierungsart, sind alles, was es braucht, und damit ist die Frist nicht mehr etwas, an dessen Setzen man denken muss.

06Grenzen & Kompromisse

Ein Klon ist ein Snapshot, und nichts gleicht die Kopien ab

Das ist der Preis dieses Designs, und er lohnt sich, aber er muss eingeplant werden. Im Moment des Klonens stimmen die beiden Datensätze überein. Danach ändern sich beide weiter, und kein Mechanismus der Plattform hält sie synchron.

Der Produktivaufbau führt Nachfüllvorgänge in beide Richtungen aus:

• Ein täglich geplanter Job befüllt den Link zum Kundenportal an offenen Umsetzungsdatensätzen aus dem Account, für Datensätze, die angelegt wurden, bevor der Account einen hatte.
• Ein manueller Job kopiert das Go-live-Datum vom Account zurück auf das Projekt, für den Fall, dass jemand es zuerst am Account erfasst hat.

Keiner ist elegant. Beide sind nötig. Schreiben Sie sie, wenn Sie den Klon schreiben – die Alternative ist, sie in Eile zu schreiben, wenn zum ersten Mal jemand fragt, warum zwei Datensätze voneinander abweichen.

Der Klon löst beim Status aus, und Positionen sind vielleicht noch nicht angehängt

Der Trigger ist, dass der Deal gewonnen wird; die Standardwerte pro Leistung werden aus dem gelesen, was der Deal enthält. Wird der Status umgestellt, bevor die Positionen am Datensatz sind – ein optimistischer Vertriebsmitarbeiter, ein Import, eine Integration, die zuerst den Status schreibt –, sieht der Zweig für den Leistungsmix eine leere Produktliste, und die Standardwerte sind stillschweigend falsch. Kein Fehler, nur ein Umsetzungsdatensatz, auf dem nichts geplant ist.

Gegenmaßnahmen, in der Reihenfolge der Präferenz: Lösen Sie auf ein späteres Signal aus, das impliziert, dass die Produkte vorhanden sind; oder akzeptieren Sie es und geben Sie dem Umsetzungsteam eine Ansicht der Datensätze, bei denen alle Mengen leer sind – ein Filter, der fünf Minuten kostet und jeden Fall erfasst.

Es gibt keine native Umwandlung in ein Projekt

Die Plattform hat keinen eingebauten Vorgang „diesen gewonnenen Deal in einen Umsetzungsdatensatz umwandeln“. Was hier beschrieben wird, ist aus einer Automatisierung zum Anlegen verknüpfter Datensätze und einer Feldzuordnung zusammengesetzt, die Sie pflegen. Wenn das Vertriebsformular ein Feld erhält, das der Umsetzungsdatensatz braucht, muss der Klon davon erfahren – nichts bemerkt es für Sie.

Pipelineübergreifende Berichte müssen zusammengesetzt werden

„Wie lange von gewonnen bis live, nach Leistungsmix“ umspannt zwei Datensatzmengen, und keine der beiden Pipelines kann das allein beantworten. Das ist der direkte Tausch für saubere Kennzahlen pro Pipeline: Sie erhalten wahrheitsgetreue Vertriebsberichte und wahrheitsgetreue Umsetzungsberichte, und die Frage, die beide umspannt, kostet einen Join. Das Go-live-Datum auf den Account zu kopieren dient unter anderem dazu, die gängige Variante dieser Frage an einer Stelle beantwortbar zu machen.

07Verifizierung

Alles hier scheitert leise, daher geht es bei den Prüfungen um Datensätze, die existieren sollten und es nicht tun, statt um Fehler.

• Gewinnen Sie einen Deal mit jeder Leistungskombination und bestätigen Sie, dass ein Umsetzungsdatensatz mit den richtigen Mengen erscheint. Dass eine Kombination funktioniert, heißt nicht, dass die Verzweigungstabelle stimmt; die Standardwerte gelten pro Mix, und jeder Mix ist ein eigener Pfad.
• Gewinnen Sie einen Deal ohne Leistung und bestätigen Sie, dass nichts angelegt wird. Beim bedingten Klon geht es ebenso sehr um das, was er nicht tut.
• Fragen Sie Umsetzungsdatensätze ab, bei denen alle Mengen leer sind. Das ist der Fingerabdruck des Reihenfolgerisikos aus §6, und es sollte eine gespeicherte Ansicht sein statt einer gelegentlichen Prüfung.
• Setzen Sie ein Go-live-Datum und prüfen Sie alle vier Folgen – die Kopie am Account, beide abgeleiteten Fristen, die Support-Benachrichtigung und die Folgeaufgabe am nächsten Tag. Ändern Sie dann das Datum und prüfen Sie, dass sich alle aktualisieren. Das erneute Auslösen bei Änderung ist die Stelle, an der das meist bricht.
• Gleichen Sie die beiden Kopien per Abfrage ab: Umsetzungsdatensätze, deren Go-live-Datum von dem ihres Accounts abweicht. Die Abfrage sollte nichts liefern. Liefert sie doch etwas, ist der Nachfüllvorgang entweder nicht gelaufen oder läuft in die falsche Richtung.
• Führen Sie die manuellen Zwillinge auf einem Datensatz aus, der bereits korrekt ist, und bestätigen Sie, dass sich nichts bewegt. Ein erneut ausführbarer Prozess, der nicht idempotent ist, ist ein schlechteres Reparaturwerkzeug als gar keines.

Was auf eine Regression hindeuten würde: ein gewonnener Deal mit einer Leistung und ohne Umsetzungsdatensatz; Umsetzungsdatensätze, deren Phase sich länger nicht bewegt hat als eine typische Implementierung dauert, was entweder ein festhängendes Projekt oder ein Prozess ist, der nicht mehr auslöst; jedes Datumsfeld, bei dem eine große Zahl von Datensätzen denselben Wert teilt, was bedeutet, dass etwas über einen Stapel hinweg „heute“ gestempelt hat.

Verwandte Blueprints

• Blueprint 003 — die vorgelagerte Frage. Ob die Umsetzung eine Pipeline, eine benutzerdefinierte Entität oder gar nichts verdient, wird dort entschieden.
• Blueprint 008 — dasselbe Argument zur Pipeline-Hygiene, angewendet auf Verlängerungen: Datensätze, die aus Gründen in einer Pipeline liegen, die nichts mit Verkaufen zu tun haben, verschlechtern jede Kennzahl, die die Pipeline liefert.
• Blueprint 009 — warum eine erneut ausführbare Ableitung das Werkzeug zur Wiederherstellung ist und was mit datumsstempelnder Automatisierung passiert, wenn sie verspätet auslöst.