--- title: "Wie prognostizieren Sie Verlängerungen, die noch gar nicht als Datensätze existieren?" blueprint: 008 slug: forecasting-renewals-before-they-exist category: Automatisierung published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/de/blueprints/forecasting-renewals-before-they-exist/ language: de translation_of: https://blueprints.coevera.com/blueprints/forecasting-renewals-before-they-exist/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # Wie prognostizieren Sie Verlängerungen, die noch gar nicht als Datensätze existieren? **Kurze Antwort.** **Trennen Sie zugesicherten Umsatz vom Verlängerungsprozess.** Der künftige Umsatz eines unterzeichneten mehrjährigen Deals ist bereits im System – ein **Umsatzplan** an der bestehenden Opportunity verteilt seinen Wert auf datierte Perioden (Monat, Quartal oder Jahr), jede Periode ein Datensatz mit einem Datum und einem Betrag – so, wie es aus dem Schema gelesen wurde; das Erzeugen der Perioden wurde nicht beobachtet. Künftige Deal-Datensätze sind nicht nötig. Das Hilfecenter beschränkt Revenue Recognition auf den Tarif **Business & Enterprise**. Ob der Kunde *verlängert*, ist eine Vertriebsfrage, und dafür braucht es eine echte Opportunity. Eine **Wiederholungsregel an der Opportunity** erzeugt diese nativ – mit einem Rhythmus `AfterNMonths` oder `AfterNYears`, der zu einer Vertragslaufzeit passt statt zu einem Kalenderdatum. ## 01 · Das Geschäftsproblem Ein Unternehmen verkauft mit mehrjährigen Laufzeiten. Jemand fragt, wie der Umsatz im nächsten Jahr aussieht, und die ehrliche Antwort erfordert drei verschiedene Dinge, die meist als eines behandelt werden: - **Bereits zugesicherter Umsatz.** Ein im letzten Quartal unterzeichneter Dreijahresvertrag verpflichtet den Kunden für zwei weitere Jahre. Dieses Geld ist keine Prognose – es ist vertraglich vereinbart und sollte nicht in einer Pipeline von Dingen erscheinen, die gerade verkauft werden. - **Umsatz, der von einer Entscheidung abhängt.** Eine Laufzeit, die im März endet, wird vielleicht verlängert, vielleicht auch nicht, vielleicht zu einem anderen Preis, vielleicht für einen kürzeren Zeitraum. Das ist tatsächlich eine Verkaufschance und gehört in eine Pipeline. - **Gefährdeter Umsatz.** Ein Kunde, der während der Laufzeit kündigt, entzieht zugesicherten Umsatz, der bereits eingerechnet war. Die Anforderung, wie sie meist formuliert wird – „Verlängerungen prognostizieren, die es noch nicht gibt“ –, wirft alle drei zusammen. Eine brauchbare Antwort beginnt damit, sie auseinanderzunehmen. ## 02 · Warum der naheliegende Ansatz scheitert ### Ruhende Verlängerungs-Opportunities anlegen > **Das Problem ist das Ruhen, nicht die Frühzeitigkeit.** Eine Verlängerungs-Opportunity, die für > eine Laufzeit in zwei Jahren angelegt wird, ist ein Datensatz in der aktiven Pipeline, den > zwanzig Monate lang niemand anrührt. Konversionsrate, durchschnittlicher Verkaufszyklus, > Verweildauer in den Phasen und gewichtete Prognose werden alle über diese Pipeline berechnet – > füllen Sie sie mit Deals, an denen niemand arbeitet, verschlechtert sich jede dieser Zahlen, > nicht sichtbar, sondern stetig. > > **Früh ist aber in Ordnung, wenn etwas den Datensatz vorantreibt.** Ein von uns untersuchter > Produktivaufbau legt die Verlängerungs-Opportunity bei der **365-Tage**-Marke an und lässt dann > einen gestaffelten Countdown dagegen laufen: eine Aufgabe für ein Quarterly Business Review bei > 180 Tagen, eine Einladung zum Review an den Kunden bei 90, eine Prüfung von Kundengesundheit und > Wert bei 60, danach sich steigernde interne und kundenseitige Benachrichtigungen bei 45, 30, 18 > und 15. Der Datensatz ruht nie, weil der Countdown vom ersten Tag an jemandem etwas zu tun gibt. > > Die Regel, die sich daraus ergibt: **Legen Sie Verlängerungen höchstens eine Laufzeit im Voraus > an, nie mehrere Laufzeiten – und nur zusammen mit einem Rhythmus, der darauf reagiert.** Eine > Verlängerungs-Opportunity ohne Countdown dahinter verschmutzt die Pipeline, egal wie weit in der > Zukunft sie liegt. ### Den gesamten Vertragswert auf das Abschlussdatum legen Ein Dreijahresdeal, der als einzelner Wert an einem einzelnen Abschlussdatum gebucht wird, besagt, dass das Unternehmen alles in einem Monat verdient hat. Jede periodenbasierte Sicht – Monatsumsatz, quartalsweise Run-Rate, ARR – ist dann für die gesamte Laufzeit falsch, und zwar in beide Richtungen: überhöht im Abschlussmonat, zu niedrig in jedem Monat danach. ### Berichte über „Opportunities mit Abschluss im nächsten Jahr“ Der instinktive Bericht, und er beantwortet die falsche Frage. Er zeigt Deals, deren *Abschluss* im nächsten Jahr erwartet wird, und lässt damit jeden bereits gewonnenen Vertrag weg, der im nächsten Jahr noch Umsatz bringt. Das ist meist die größere Zahl, und sie fehlt vollständig. ### Alles mit Automatisierung bauen Verständlich und größtenteils unnötig – für beide Hälften gibt es native Mechanismen. Das lohnt sich vor dem Bauen zu prüfen, aus demselben Grund wie in [Blueprint 006](https://blueprints.coevera.com/de/blueprints/document-numbering-that-survives-production/), wo die häufig empfohlene Automatisierungs-Umgehung etwas nachbaut, das als Optionsfeld mitgeliefert wird. ## 03 · Zwei Mechanismen, zwei Fragen Eine Opportunity in Coevera trägt beides, und es sind vollständig getrennte Dinge. ### Umsatzplan – was bereits zugesichert ist Ein an die Opportunity angehängter Plan, der Folgendes hält: | Eigenschaft | Bedeutung | |---|---| | `startDate` | Wann der Umsatz beginnt – nicht das Abschlussdatum. | | `periodCount` | Auf wie viele Perioden sich der Wert verteilt. | | `periodType` | **Month, Quarter oder Year.** Genau diese drei. | | `cancelationDate` | Das vorzeitige Vertragsende. Hier wird Abwanderung ausgedrückt. | | `periods` | Die erzeugten Periodendatensätze. | Jede Periode ist ein eigener Datensatz mit einem **Datum** und einem **Wert**. Diese Struktur macht periodenbasierte Berichte möglich: Der Umsatz eines beliebigen Monats ist die Summe der darin datierten Periodenzeilen über alle Verträge hinweg, unabhängig davon, wann diese Verträge abgeschlossen wurden. ### Wiederholung – den nächsten Deal erzeugen Eine separate Regel, ebenfalls an der Opportunity, die künftige Opportunity-Datensätze erzeugt: | Eigenschaft | Bedeutung | |---|---| | `startDate` / `endDate` | Das Zeitfenster, in dem Vorkommen erzeugt werden. | | `stepId` | **Pflichtfeld** – der Pipeline-Schritt, auf dem erzeugte Opportunities landen. | | `occurEvery` / `occurrencesCount` | Das Intervall und wie viele erzeugt werden. | | `type` | Der Rhythmus – siehe unten. | | `day` · `dayOfWeek` · `week` · `month` | Kalenderposition, verwendet von den absoluten und relativen Typen. | Die verfügbaren Rhythmen fallen in drei Familien: - **Einfach** – täglich, wöchentlich. - **Absolut und relativ** – monatlich oder jährlich, entweder an einem festen Kalendertag („am 15.“) oder relativ („am letzten Freitag“). - **Nach N** – nach N Tagen, Wochen, Monaten oder Jahren. **Das ist die Familie für Verlängerungen**, denn eine Verlängerung wird eine Laufzeit nach der letzten fällig und nicht an einem festen Kalenderdatum. **Quellen.** Coevera-Hilfecenter, [Using opportunity recurrence](https://help.coevera.com/en/articles/4190616-using-opportunity-recurrence) und [Using opportunity revenue recognition](https://help.coevera.com/en/articles/4293948-using-opportunity-revenue-recognition) – die beiden Mechanismen, getrennt dokumentiert, was genau die Unterscheidung ist, auf der dieser Blueprint aufbaut. > **Die Designentscheidung, die Ihnen das überlässt.** Setzen Sie das Wiederholungsfenster so, > dass die nächste Opportunity erscheint, wenn tatsächlich jemand daran arbeiten wird – ein > Quartal vor Laufzeitende, nicht drei Jahre –, und lassen Sie den Umsatzplan in der Zwischenzeit > den zugesicherten Umsatz tragen. So bleibt die Pipeline ehrlich und die Umsatzsicht zugleich > vollständig, und genau dafür ist die Aufteilung in zwei Mechanismen da. ### Verlängerung von Neugeschäft unterscheiden Verlängerungen müssen meist getrennt vom Neugeschäft berichtet werden, was einen Opportunity-Typ bedeutet. Eine strukturelle Tatsache, die Sie einplanen sollten: **Opportunity-Typen sind eins zu eins mit Pipelines verbunden.** Ein Space mit New Business, Expansion und Renewal als Typen hat daher drei Pipelines – was oft ohnehin gewünscht ist, weil eine Verlängerung andere Schritte durchläuft als ein Neuverkauf, aber es ist keine freie Wahl. ## 04 · Was Sie selbst ergänzen müssen Die Mechanik ist nativ, das kaufmännische Vokabular von Verlängerungen nicht. Diese benutzerdefinierten Felder gibt es in jedem Aufbau, den wir gesehen haben: | Feld | Warum es nötig ist | |---|---| | Laufzeit | Die Wiederholung kennt ihr Intervall; der Datensatz nennt nicht die vertraglich vereinbarte Laufzeit. | | Verlängerungsdatum | Nicht zu verwechseln mit dem Abschlussdatum, an dem der Verlängerungs-*Deal* abgeschlossen wird. | | Zulässige Preiserhöhung | Eine vertragliche Obergrenze für die Erhöhung – nötig vor dem Gespräch, nicht danach. | | Abrechnungs- und Bestellanforderungen | Ob dieser Kunde vor der Rechnungsstellung eine Bestellung benötigt. Meist ein Standardwert am Account, pro Verlängerung überschreibbar. | | Indikator für Abwanderungsrisiko | Speist die Reaktivierung und ergänzt im Nachhinein das Kündigungsdatum. | Das Muster aus Standardwert am Account mit Überschreibung pro Verlängerung in der vierten Zeile sollten Sie früh klären. Es ist eine Frage danach, wo die Daten liegen, und wer sie spät beantwortet, muss die Daten verschieben. ## 05 · Den Countdown antreiben Es gibt keine native Benachrichtigung „Verlängerung steht bevor“. Der Mechanismus, den ein Produktivaufbau dafür verwendet, ist es wert, übernommen zu werden, denn er ist einfacher, als er aussieht. ### Ein Countdown-Feld, viele Beobachter Pflegen Sie einen einzigen Wert **„läuft ab in Tagen“** am Account und lassen Sie jede Stufe des Countdowns bei *Änderungen dieses einen Felds* auslösen, statt dass jede ihre eigene Datumsarithmetik ausführt. Eine Zahl zählt herunter; die Aktion bei 180 Tagen, die Aktion bei 90 Tagen und die Aktion bei 60 Tagen beobachten sie alle unabhängig voneinander. Die Alternative – jeder Prozess berechnet selbst, ob das Verlängerungsdatum innerhalb von N Tagen liegt – vervielfacht dieselbe Datumslogik an einem Dutzend Stellen, und die laufen auseinander. ### Den Ersteller mit einem Flag idempotent machen > **Ein täglich geplanter Job, der Datensätze anlegt, muss sich gefahrlos jeden Tag ausführen > lassen.** Das Muster: Filtern Sie darauf, dass der Countdown den Schwellenwert überschreitet, > *und* darauf, dass ein Flag „Verlängerung bereits angelegt“ nicht gesetzt ist; legen Sie die > Opportunity an; setzen Sie das Flag. > > Dieselbe Form wie der Einmal-Schutz in [Blueprint > 001](https://blueprints.coevera.com/de/blueprints/one-entity-five-request-types/) – die > Bedingung macht den Schreibvorgang idempotent, sodass keine separate Buchführung darüber nötig > ist, ob er schon gelaufen ist. Ohne sie erzeugt ein täglicher Job ein Jahr lang jeden Morgen > eine neue Verlängerungs-Opportunity. ### Mehrjahresverträge vom jährlichen Countdown ausnehmen Ein Dreijahresvertrag sollte am Ende des ersten und des zweiten Jahres keine Verlängerungsaktivität auslösen. Der Produktivaufbau löst das mit einem ausdrücklichen **Mehrjahres-Flag**, das zusammen mit einem **Flag für manuelle Bearbeitung** den Standard-Countdown unterdrückt und diese Accounts auf einen separaten Pfad mit einem besonderen Verlängerungsdatum leitet. Das sollten Sie von Anfang an einplanen. Es nachzurüsten heißt, zuerst jeden Account mitten in der Vertragslaufzeit zu finden, der Verlängerungs-E-Mails erhalten hat, die er nicht hätte erhalten sollen. ### Die Laufzeit bewusst abschließen Wenn ein Abonnement tatsächlich endet, muss etwas das festhalten. Ein geplanter Job, der am Tag *nach* dem Enddatum läuft, setzt das Verlustdatum, stempelt das Datum der letzten Nutzung und leert die vorausschauenden Verlängerungsfelder. Ohne ihn erscheinen beendete Abonnements weiter in den Verlängerungsberichten, als stünden sie noch aus. ### Zwei Hinweise zur Form Ein geplanter Prozess, der auf ein Datum filtert, braucht einen Vergleich mit einem relativen Zeitraum statt eines festen Werts. Und ein Prozess, dessen erster Knoten eine Aktion statt eines Filters ist, wird erfolgreich gespeichert und zeigt eine leere Arbeitsfläche – die Form ist Trigger, dann Filter, dann Aktionen, wie in [Blueprint 002](https://blueprints.coevera.com/de/blueprints/ai-fields-read-documents/) beschrieben. Soll die Verlängerungs-Opportunity etwas von der auslaufenden übernehmen – Positionen, die Account-Beziehung, Werte benutzerdefinierter Felder –, ist auch das Automatisierung. Eine Wiederholungsregel erzeugt einen Datensatz auf einem Schritt; sie ist kein Mechanismus zum Kopieren von Verträgen. ## 06 · Grenzen & Kompromisse ### Periodentypen sind Monat, Quartal oder Jahr – sonst nichts Ein Plan verteilt sich auf einen dieser drei. Unregelmäßige Abrechnung – Meilensteinzahlungen, ein ungleichmäßiger Hochlauf, eine Anzahlung gefolgt von Raten – lässt sich nicht als nativer Plan ausdrücken. Dieser Fall braucht entweder mehrere Opportunities oder eine untergeordnete Entität, die den Zahlungsplan hält, bepreist wie in [Blueprint 007](https://blueprints.coevera.com/de/blueprints/pricing-one-product-many-prices/). ### Ein Plan pro Opportunity, im Modus auf Basis des Opportunity-Werts Wenn Revenue Recognition auf dem Opportunity-Wert läuft, ist der Plan ein einzelner Anhang, keine Sammlung. Ein Deal, der etwa eine Jahreslizenz und einen monatlichen Service kombiniert, hat zwei Rhythmen und muss in diesem Modus auf zwei Opportunities aufgeteilt werden – eine Modellierungsentscheidung, die Sie bewusst treffen sollten, statt sie zu entdecken, wenn der erste solche Vertrag eintrifft. Der in §3 zitierte Hilfecenter-Artikel beschreibt außerdem einen Modus **Product Line**, in dem Revenue Recognition für jede Produktposition einzeln festgelegt wird; bei einer monatlichen Konfiguration kann jede Position ihre eigene Periode Month, Quarter oder Year erhalten. Dieser Modus ist die dokumentierte Alternative zum Aufteilen; hier wurde er nicht getestet. ### Die erzeugte Opportunity landet auf einem festen Schritt Die Wiederholungsregel verlangt einen Zielschritt, daher erscheint jedes erzeugte Vorkommen an derselben Position in der Pipeline. Sollen Verlängerungen je nach Risiko oder Größe in unterschiedlichen Phasen einsteigen, ist dieses Routing nachgelagerte Automatisierung und nicht Teil der Regel. ### Gespeicherte Felder pro Verlängerungsjahr werden zur jährlichen Wartung > **Eine Falle, die nur in einem Aufbau sichtbar wird, der seit Jahren läuft.** Wenn Sie > „Verlängerung dieses Jahr“, „Verlängerung letztes Jahr“ und „Verlängerung nächstes Jahr“ als > Felder am Account speichern – weil die Berichte sie nebeneinander haben wollen –, haben Sie sich > einen **jährlichen Umschichtungsvorgang** eingehandelt. > > Der von uns untersuchte Produktivaufbau lässt **einmal pro Kalenderjahr eine Kette von vier > Prozessen** laufen, um letztes ← dieses, dieses ← nächstes und nächstes zwölf Monate nach vorn > zu verschieben, mit separaten Zweigen für Mehrjahresverträge, und leitet danach die Verlustdaten > neu her. Die Kette wird manuell ausgeführt, von der Person, die sich daran erinnert, dass es sie > gibt. > > Leiten Sie diese Werte, wo immer die Berichtsebene es erlaubt, zur Lesezeit aus dem > Verlängerungsdatum ab. Speichern Sie sie nur, wo Sie müssen, und wenn Sie müssen, dokumentieren > Sie, dass es den Jahreswechsel gibt – genau diese Art jährlicher Aufgabe wird in dem Jahr > vergessen, in dem die zuständige Person die Rolle wechselt. ### Am Schema verifiziert, nicht am Verhalten > **Eine ehrliche Grenze dieses Blueprints.** Die Orchestrierung in §5 und die obigen Kompromisse > stammen aus einem Aufbau, der seit Jahren produktiv läuft. Die Hälfte zu den *nativen Entitäten* > ist schwächer belegt: Die Formen, Eigenschaftsnamen, Periodentypen und Wiederholungsrhythmen > wurden direkt aus dem Schema eines Live-Space gelesen und sind korrekt, aber wir haben > **keinen** Umsatzplan angelegt und die Entstehung der Perioden beobachtet, und wir haben keine > Wiederholung bis zum Ende laufen lassen. > > Zwei Verhaltensweisen im Besonderen sind unbeobachtet: wie genau Periodendatensätze reagieren, > wenn während der Laufzeit ein Kündigungsdatum gesetzt wird, und ob die Erzeugung von > Wiederholungen davon beeinflusst wird, dass die Quell-Opportunity gewonnen, verloren oder > archiviert ist. Beides ist für Berichte wichtig. Verifizieren Sie es in einer Sandbox, bevor Sie > eine Prognose darauf aufbauen – und beachten Sie, dass der Endpunkt für Umsatzpläne selbst > keinen Opportunity-Verweis hat, sodass die Zuordnung von der Seite der Opportunity aus erfolgt. ### Der Plan lässt sich nicht über REST anhängen > **Versucht und gescheitert, damit Sie es nicht tun müssen.** Der Endpunkt für Umsatzpläne hat > selbst keinen Opportunity-Verweis, und ein Anlegen, das einen mitschickt, wird abgelehnt. Das > Anhängen aus der anderen Richtung – die Opportunity mit einer Plan-Nutzlast zu patchen – > **meldet Erfolg und legt nichts an.** Ein anschließender Lesevorgang zeigt keinen Plan im Space. > > Das ist das vorherrschende Fehlerbild der API dieser Plattform, das in dieser ganzen Bibliothek > dokumentiert ist: Der Schreibvorgang wird angenommen, kein Fehler wird ausgelöst, und nichts > passiert. Gehen Sie davon aus, dass Pläne über die Oberfläche oder die Administrations-API > angelegt werden müssen, bis das Gegenteil bewiesen ist, und **lesen Sie immer zurück**, nachdem > Sie es versucht haben. ### Eine Eigenheit beim Schreiben, die Sie kennen sollten Der Wert der Opportunity wird als zusammengesetzter Wert aus Basiswert, Fremdwährungswert und Währung zurückgelesen – aber er wird **als einfache Zahl geschrieben**. Die zusammengesetzte Form beim Anlegen mitzugeben wurde akzeptiert und ergab stillschweigend einen Wert von null; dasselbe Feld als Skalar gesetzt funktionierte. Wenn Ihre Prognose davon abhängt, dass Deal-Werte korrekt über eine Integration ankommen, prüfen Sie sie nach dem Schreiben. ## 07 · Verifizierung - **Gleichen Sie den Plan mit dem Deal ab.** Die Summe der Periodenwerte sollte dem Vertragswert entsprechen. Wenn nicht, erzählen Plan und Hauptwert unterschiedliche Geschichten, und Berichte widersprechen einander. - **Vergleichen Sie eine periodenbasierte Umsatzsicht mit einer Sicht nach Abschlussdatum** und bestätigen Sie, dass sie sich so unterscheiden, wie Sie es erwarten. Stimmen sie überein, wird der Plan wahrscheinlich nicht genutzt. - **Setzen Sie ein Kündigungsdatum an einem Testplan** und beobachten Sie, was mit den Perioden nach diesem Datum geschieht, bevor Sie Abwanderungsberichten vertrauen. - **Lassen Sie eine Wiederholung mindestens zwei Vorkommen erzeugen** und prüfen Sie deren Daten gegen die beabsichtigte Laufzeit – besonders bei einem Rhythmus nach N, bei dem ein um eins verschobenes Intervall leicht zu konfigurieren und schwer zu erkennen ist. - **Zählen Sie die aktiven Pipeline-Datensätze vorher und nachher**, wenn Sie die Wiederholung aktivieren. Springt die Anzahl um mehr als das nächste Vorkommen, ist das Fenster zu weit, und die Pipeline-Kennzahlen werden bald abdriften. - **Verifizieren Sie Deal-Werte nach jedem Schreibvorgang einer Integration**, angesichts des oben beschriebenen Verhaltens von zusammengesetztem Wert gegenüber Skalar. **Was auf eine Regression hindeuten würde:** Periodenwerte, die sich nicht mehr zum Vertragswert summieren; Verlängerungs-Opportunities, die weiter in der Zukunft erscheinen als das beabsichtigte Fenster; ein gekündigter Vertrag, der noch Umsatz zu künftigen Perioden beiträgt; oder eine steigende Zahl unberührter Opportunities in der aktiven Pipeline, was das Symptom dafür ist, dass das Problem aus §2 zurückkehrt. ## Verwandte Blueprints - [Blueprint 014 — Wie erkennen Sie abwanderungsgefährdete Kunden vor der Verlängerung?](https://blueprints.coevera.com/de/blueprints/customer-health-score-churn-risk/) — das Signal für Abwanderungsrisiko, das laut diesem Blueprint jede Verlängerung braucht, aufgebaut auf dem nativen Health Score. - [Blueprint 007 — Wie bepreisen Sie ein Produkt je nach Region, Segment oder Vertrag unterschiedlich?](https://blueprints.coevera.com/de/blueprints/pricing-one-product-many-prices/) — woher ein Verlängerungspreis und seine zulässige Preiserhöhung kommen. - [Blueprint 010 — Wie übergeben Sie einen gewonnenen Deal an das Team, das ihn umsetzt?](https://blueprints.coevera.com/de/blueprints/handover-from-sales-to-delivery/) — eine zweite Pipeline für die Arbeit nach einem gewonnenen Deal – dieselbe Einschränkung „ein Typ, eine Pipeline“. ## Häufige Fragen ### Wie prognostizieren Sie wiederkehrenden Umsatz oder Verlängerungsumsatz in einem CRM, bevor die Verlängerung als Deal existiert? Indem Sie zwei Fragen trennen, die meist vermengt werden. Welchen Umsatz ein unterzeichneter mehrjähriger Deal bereits zusichert, beantwortet ein Umsatzplan an der bestehenden Opportunity: ein Startdatum, eine Periodenanzahl, ein Periodentyp Monat, Quartal oder Jahr und ein Satz erzeugter Periodendatensätze, die jeweils ein Datum und einen Wert tragen – eine Struktur, die aus dem Schema gelesen wurde; das Erzeugen der Perioden wurde nicht beobachtet. Dieser Umsatz ist bereits im System und braucht keine künftigen Deal-Datensätze. Laut Hilfecenter ist Revenue Recognition im Tarif Business & Enterprise verfügbar. Ob der Kunde tatsächlich verlängert, ist eine eigene Vertriebsfrage, die durch das Erzeugen einer künftigen Opportunity beantwortet wird – was eine Wiederholungsregel an der ursprünglichen Opportunity automatisch erledigen kann. ### Kann ein CRM die nächste Verlängerungs-Opportunity automatisch anlegen? In Coevera ja, nativ. Eine Opportunity kann eine Wiederholungsregel tragen, mit einem Startdatum, einem optionalen Enddatum, einem Ziel-Pipeline-Schritt, der Anzahl der zu erzeugenden Vorkommen und einem Wiederholungstyp. Die verfügbaren Typen umfassen täglich und wöchentlich, monatlich und jährlich sowohl in absoluter Form (ein fester Kalendertag) als auch in relativer Form (zum Beispiel der letzte Freitag) sowie nach N Tagen, Wochen, Monaten oder Jahren – wobei diese letzte Familie diejenige ist, die zu einer Vertragslaufzeit passt, denn eine Verlängerung wird N Monate nach der vorherigen fällig und nicht an einem festen Kalenderdatum. ### Warum ist es eine schlechte Idee, Verlängerungs-Opportunities Jahre im Voraus anzulegen? Weil dadurch Deals in die aktive Pipeline gelangen, an denen niemand arbeitet. Konversionsraten, durchschnittlicher Verkaufszyklus, Verweildauer in den Phasen und gewichtete Prognose verschlechtern sich alle, weil die Pipeline nun Datensätze enthält, die ein Jahr oder länger unberührt liegen. Außerdem werden die Abschlussdaten zur Fiktion, denn ein Verlängerungsdatum Jahre in der Zukunft ist eine Schätzung. Die bessere Trennung ist, den künftigen zugesicherten Umsatz vom Umsatzplan tragen zu lassen und die Verlängerungs-Opportunity erst zu erzeugen, wenn die Laufzeit nah genug ist, dass tatsächlich jemand daran arbeitet. ### Wie werden Abwanderung oder Kündigung während der Laufzeit in einem Umsatzplan abgebildet? Der Umsatzplan trägt neben seinem Startdatum und seiner Periodenanzahl ein Kündigungsdatum. Das ist das Feld, das ein vorzeitiges Vertragsende ausdrückt, statt Perioden zu löschen oder den ursprünglichen Deal-Wert zu bearbeiten. Beachten Sie, dass wir das genaue Verhalten der Periodendatensätze beim Setzen eines Kündigungsdatums aus dem Schema dokumentiert, aber nicht in einem Live-Space beobachtet haben; verifizieren Sie es daher, bevor Sie sich für Berichte darauf verlassen. --- Herausgegeben von Coevera. Auf das wiederverwendbare Muster abstrahiert – keine Kundennamen, keine Kundendaten, keine personenbezogenen Daten.