--- title: "Wie übergeben Sie einen gewonnenen Deal an das Team, das ihn umsetzt?" blueprint: 010 slug: handover-from-sales-to-delivery category: Übergabe published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/de/blueprints/handover-from-sales-to-delivery/ language: de translation_of: https://blueprints.coevera.com/blueprints/handover-from-sales-to-delivery/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # Wie übergeben Sie einen gewonnenen Deal an das Team, das ihn umsetzt? **Kurze Antwort.** Geben Sie der Umsetzung **ihre eigene Pipeline** und klonen Sie die gewonnene Opportunity dorthin. Hängen Sie keine Umsetzungsphasen an das Ende der Vertriebspipeline – ein Datensatz, der zwei Lebenszyklen durchläuft, verfälscht Konversionsrate, Verkaufszyklus und gewichtete Prognose auf einen Schlag. Klonen Sie **bedingt**, abhängig davon, ob der Deal tatsächlich etwas Umzusetzendes enthält, und setzen Sie am neuen Datensatz Standardwerte pro Leistung aus dem, was verkauft wurde. Behandeln Sie dann das Go-live-Datum als eine einzige Feldänderung, die sich **auffächert**: auf den Account, in abgeleitete Fristen und nach außen als Übergabe an den Support. Der Teil, den alle zu spät entdecken: Ein Klon ist ein **Snapshot**, die beiden Datensätze driften auseinander, und nichts gleicht sie ab. Schreiben Sie die Nachfüll-Jobs zur selben Zeit wie den Klon. ## 01 · Das 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. ## 02 · Warum 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. ## 03 · Datenmodell – 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](https://help.coevera.com/en/articles/2723998-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: | Phase | Was sie bedeutet | Ausstiegsbedingung | |---|---|---| | Warten auf Zahlung / Einführung | Gewonnen, noch nicht begonnen | Zahlung eingegangen und Einführungsgespräch geführt | | Einrichtung läuft | Die Implementierungsuhr läuft | Konfiguration abgeschlossen | | Anwenderschulung – System live | Der Kunde nutzt es | Schulung durchgeführt | | Leistungen erbracht | Fertig | — | 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](https://blueprints.coevera.com/de/blueprints/where-should-this-data-live/) 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. ## 04 · Konfiguration auf Feldebene Der Umsetzungsdatensatz braucht einen kleinen Satz von Feldern, mit denen der Vertriebsdatensatz nichts anfangen kann. | Zweck | Typ | Gesetzt durch | Hinweise | |---|---|---|---| | Art der Implementierung | Dropdown | Klon / manuell | Verzweigt die Fristregeln – siehe §5. Projekte und Beratungsstunden verhalten sich unterschiedlich. | | Mengen pro Leistung (Einrichtung, Schulung, Daten, Admin-Schulung) | Numerisch | **Klon, aus dem Produktmix** | Standardwerte pro Leistungskombination, sodass der Datensatz befüllt statt leer ankommt. | | Projektstartdatum | Datum | Prozess, bei Projektbeginn | Nicht das Gewinndatum. Die Implementierungsuhr startet, wenn die Arbeit startet. | | Go-live-Datum | Datum | Manuell | Das eine Feld, das sich auffächert. Siehe §5. | | Enddatum des Onboardings | Datum | Prozess, abgeleitet | Aus dem Go-live berechnet. | | Schulung abzuschließen bis | Datum | Prozess, abgeleitet | Je nach Implementierungsart aus dem Go-live *oder* aus der Anlage des Datensatzes berechnet. | | Link zu Kundenportal / Abonnement | URL | Klon, plus ein Nachfüll-Job | Beim Klonen häufig leer. Siehe §6. | | Go-live-Datum *am Account* | Datum | Prozess, aus dem Projektdatensatz | Damit Automatisierung auf Account-Ebene es sehen kann, ohne zum Projekt zu navigieren. | > **Warum der Account seine eigene Kopie des Go-live-Datums trägt.** Das ist Duplizierung, und sie > ist gewollt. Automatisierung auf Account-Seite – Customer-Success-Rhythmen, > Gesundheitsprüfungen, alles Geplante – muss danach filtern können, ob dieser Kunde live ist und > seit wann, ohne auf einen verknüpften Datensatz zuzugreifen. Die berechneten Felder im > untersuchten Space verweisen nur auf Felder ihrer eigenen Entität; ob eines das Feld eines > verknüpften Datensatzes lesen kann, wurde nicht verifiziert, sodass Sie sich für das Datum des > Projekts nicht auf ein abgeleitetes Feld am Account verlassen sollten. Es im richtigen Moment zu > kopieren ist der Mechanismus, der es verfügbar macht. ## 05 · Automatisierung & 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: | Prozess | Trigger | Was er tut | |---|---|---| | Der maßgebliche Setzer | Go-live-Datum ändert sich | Kopiert das Datum auf den Account; berechnet das Enddatum des Onboardings | | Fristableitung | Go-live-Datum ändert sich | Setzt die Schulungsfrist, verzweigt nach Implementierungsart | | Übergabe an den Support | Phase wird zu *System live* | Benachrichtigt den Support mit Lizenzen, Stufe und Implementierungsumfang | | Kreis schließen | Geplant, am Tag nach dem Go-live | Benachrichtigt den Verantwortlichen und legt eine Folgeaufgabe an | 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. > **Jeder automatische Setzer braucht einen manuellen, erneut ausführbaren Zwilling.** Der > Produktivbestand kombiniert den Go-live-Setzer mit einem manuell ausgelösten Prozess, der > identische Logik enthält. > > Der Grund ist struktureller Natur, nicht defensiv: Ein Prozess, der bei Änderung auslöst, lässt > sich nicht nachspielen. Go-live-Daten verschieben sich, Datensätze werden in falscher > Reihenfolge angelegt, eine Automatisierung ist einen Nachmittag lang deaktiviert. Ohne manuellen > Zwilling bleibt als einzige Reparatur, Felder von Hand zu bearbeiten und zu hoffen, dass man an > alle gedacht hat. Dieselbe Überlegung findet sich in [Blueprint > 009](https://blueprints.coevera.com/de/blueprints/automating-on-integration-owned-fields/), wo > eine erneut ausführbare Ableitung das Werkzeug zur Wiederherstellung für eine ganze Klasse von > Fehlern ist. ## 06 · Grenzen & 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. ## 07 · Verifizierung 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](https://blueprints.coevera.com/de/blueprints/where-should-this-data-live/) — die vorgelagerte Frage. Ob die Umsetzung eine Pipeline, eine benutzerdefinierte Entität oder gar nichts verdient, wird dort entschieden. - [Blueprint 008](https://blueprints.coevera.com/de/blueprints/forecasting-renewals-before-they-exist/) — 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](https://blueprints.coevera.com/de/blueprints/automating-on-integration-owned-fields/) — warum eine erneut ausführbare Ableitung das Werkzeug zur Wiederherstellung ist und was mit datumsstempelnder Automatisierung passiert, wenn sie verspätet auslöst. ## Häufige Fragen ### Wie übergeben Sie einen gewonnenen CRM-Deal an ein Umsetzungs- oder Onboarding-Team? Geben Sie der Umsetzung ihre eigene Pipeline und klonen Sie die gewonnene Opportunity dorthin, statt am Ende der Vertriebspipeline Umsetzungsphasen anzuhängen. Beide haben unterschiedliche Verantwortliche, unterschiedliche Phasen, unterschiedliche Felder und unterschiedliche Definitionen von „fertig“, und eine Vertriebspipeline, die nach dem Abschluss des Deals noch monatelang weiterläuft, liefert keine brauchbaren Berichte: Konversionsrate, Verkaufszyklus und Verweildauer in den Phasen messen alle das Falsche. Klonen Sie bedingt, abhängig davon, ob der Deal tatsächlich eine Leistung enthält, damit Deals ohne Umsetzungsbedarf nicht in der Warteschlange des Umsetzungsteams erscheinen. Setzen Sie am Klon Standardwerte pro Leistung aus dem, was verkauft wurde. Akzeptieren Sie, dass ein Klon ein Snapshot ist, der von seiner Quelle abdriftet, und bauen Sie die Nachfüll-Jobs, die ihn abgleichen. ### Sollte die Umsetzung aus zusätzlichen Phasen in der Vertriebspipeline bestehen oder eine eigene Pipeline sein? Eine eigene Pipeline. Zusätzliche Phasen lassen einen Datensatz zwei Lebenszyklen durchlaufen, was jede Pipeline-Kennzahl verfälscht: Ein Deal, der im März abgeschlossen wurde und im Juli live geht, zeigt einen viermonatigen Verkaufszyklus, und die gewichtete Prognose zählt zugesicherten Umsatz, als würde er noch gewonnen. Außerdem zwingt es zwei Teams, deren Arbeit fast nichts gemeinsam hat, einen Feldsatz und einen Verantwortlichen auf. In Coevera ist ein Opportunity-Typ eins zu eins einer Pipeline zugeordnet, eine zweite Pipeline bedeutet also einen zweiten Typ, und die beiden Datensätze sind miteinander verknüpft statt identisch. ### Was sollte im CRM passieren, wenn ein Projekt live geht? Behandeln Sie das Go-live-Datum als eine einzige Feldänderung, die sich auffächert, und schreiben Sie jede Folge als eigenen Prozess statt als einen großen. In einem Produktivaufbau lösen daraus vier Dinge aus: Das Datum wird vom Projektdatensatz auf den Kunden-Account kopiert, damit Automatisierung auf Account-Ebene es sehen kann; zwei abgeleitete Fristen werden daraus berechnet, verzweigt nach der Art der Implementierung; das Support-Team wird mit dem Implementierungsumfang benachrichtigt, was die eigentliche Übergabe aus der Umsetzung heraus ist; und einen Tag später benachrichtigt ein geplanter Prozess auf Account-Seite den Verantwortlichen und legt eine Folgeaufgabe an, was den Kreis zurück zum Customer Success schließt. Jeder lässt sich einzeln erneut ausführen, was wichtig ist, weil sich Go-live-Daten verschieben. ### Warum brauchen geklonte CRM-Datensätze Nachfüll-Jobs? Weil ein Klon ein Snapshot ist, der zu einem Zeitpunkt aufgenommen wird, und sich beide Kopien danach weiter ändern. Nichts in der Plattform gleicht sie ab. Der Produktivaufbau, auf dem dies beruht, betreibt zwei solche Jobs: einen täglichen, der ein Link-Feld an offenen Umsetzungsdatensätzen aus dem Account befüllt, wenn es beim Klonen leer war, und einen manuellen, der das Go-live-Datum in die umgekehrte Richtung kopiert, für Datensätze, bei denen der Account es hat und das Projekt nicht. Keiner ist elegant, und beide sind nötig. Schreiben Sie sie, wenn Sie den Klon schreiben, nicht erst, wenn zum ersten Mal jemand fragt, warum zwei Datensätze voneinander abweichen. --- Herausgegeben von Coevera. Auf das wiederverwendbare Muster abstrahiert – keine Kundennamen, keine Kundendaten, keine personenbezogenen Daten.