--- title: "Wie erkennen Sie abwanderungsgefährdete Kunden vor der Verlängerung?" blueprint: 014 slug: customer-health-score-churn-risk category: Customer Success published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/de/blueprints/customer-health-score-churn-risk/ language: de translation_of: https://blueprints.coevera.com/blueprints/customer-health-score-churn-risk/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # Wie erkennen Sie abwanderungsgefährdete Kunden vor der Verlängerung? **Kurze Antwort.** Coevera hat eine **native Health-Engine**, der Score ist also Konfiguration und kein Feld, das jemand pflegt. Sie wird **pro Untertyp von Datensätzen** eingerichtet: Eine Liste von **Indikatorregeln** – jede ein Feld, ein Operator und eine Punktzahl – ergibt einen numerischen Score, eine von vier **Stufen** und einen **Trend**. Eine separate Reihe **kritischer Indikatoren** punktet mit `-1`, und weil die Critical-Stufe ebenfalls bei `-1` liegt, erzwingt eine einzige zutreffende kritische Regel nach den gespeicherten Werten die schlechteste Stufe, wie gut auch immer alles andere bewertet wurde; das ist abgeleitet, nicht in einer Neuberechnung beobachtet. Die Health-Stufe ist ein legitimer Prozess-Trigger – im Produktivbetrieb verifiziert. Die Designregel, die das Ganze tragfähig macht, lautet aber: **Lassen Sie den Score Aufmerksamkeit lenken, und lassen Sie einen Menschen sich festlegen.** Health-Änderungen benachrichtigen den Verantwortlichen für die Kundenbeziehung; dieser erfasst eine Einschätzung in einem eigenen Feld; und **das Einschätzungsfeld** löst den Outreach aus. Die Einschränkung: Der Score wird **neu berechnet, nicht live geführt**. Automatisierung löst aus, wenn die Neuberechnung läuft, nicht wenn sich das zugrunde liegende Feld bewegt hat. ## 01 · Das Geschäftsproblem Ein Kunde wandert nicht am Tag der Verlängerung ab. Er wandert in den Monaten davor ab, leise, und das Verlängerungsgespräch ist der Ort, an dem Sie es erfahren. Bis dahin kommen die sinnvollen Interventionen – das reparieren, was kaputtging, das Team schulen, das nie ordentlich eingeführt wurde, den Sponsor erreichen, der gegangen ist – alle zu spät, um noch etwas zu bewirken. Die Anforderung ist also eine Frühwarnung, die tatsächlich jemanden erreicht: - eine laufende Einschätzung jedes Kunden, aktualisiert, ohne dass jemand sie pflegt; - aufgebaut aus Signalen, die der Kunde erzeugt, nicht aus Meinungen, an deren Erfassung jemand denken muss; - so ausgedrückt, dass **„Warum steht dieser Account auf Gelb?“** eine Antwort hat; - die *bei der Person ankommt, der die Kundenbeziehung gehört*, nicht auf einem Dashboard; - und die zu einer konkreten, verbindlichen Maßnahme führt, mit einem Nachweis, dass sie stattgefunden hat. An der mittleren Anforderung scheitert das meiste Health Scoring. Über eine Zahl, die niemand erklären kann, wird gestritten, dann wird sie ignoriert. An der letzten scheitert der Rest: Ein Signal, das keine Verpflichtung erzeugt, erzeugt kein Ergebnis. ## 02 · Warum der naheliegende Ansatz scheitert ### Ein Health-Feld, das jemand pflegt Der erste Reflex ist ein Dropdown – grün, gelb, rot –, das der Account Manager setzt. Es beschreibt die Stimmung des Account Managers, veraltet in dem Moment, in dem sich die Aufmerksamkeit anderswohin verlagert, und ist immer genau bei den Accounts am veraltetsten, auf die niemand schaut. Und das sind die gefährdeten Accounts. ### Ein berechnetes Feld oder ein Rollup-Feld Der bessere Reflex ist, den Wert zu berechnen: ein Formel- oder Rollup-Feld, das eine Zahl liefert. Damit bekommen Sie die Arithmetik und nichts von dem Apparat drumherum. Es gibt keinen Verlauf, also sehen Sie keinen Rückgang; keinen Trend, also sieht eine 60, die von 90 fällt, genauso aus wie eine 60, die von 30 steigt; keine Zuordnung, also können Sie nicht sagen, welcher Eingangswert sich bewegt hat; und keine Stufen, also erfindet jeder, der die Zahl nutzt, die Schwellenwerte neu. Am Ende bauen Sie die Health-Engine schlecht nach, in einem Feld. ### Die Intervention direkt an den Score koppeln Der folgenreichste Fehler ist architektonisch statt mechanisch: den Kunden-Outreach direkt auszulösen, wenn der Score einen Schwellenwert überschreitet. Das ist nur einen Prozessknoten entfernt, und es ist falsch, weil **ein Score ein Wahrscheinlichkeitssignal ist und Outreach eine Verpflichtung**. Aus der direkten Kopplung folgen drei Dinge: - **Datenprobleme werden zu Kundenkontakt.** Eine Integration pausiert, ein Indikator verschlechtert sich flächendeckend, und das CRM schreibt der Hälfte Ihrer Kundenbasis E-Mails über ein Problem, das nicht existiert. - **Niemand verantwortet das Urteil.** Wenn ein Score-Schwellenwert die E-Mail verschickt, hat nie ein Mensch entschieden, dass dieser Account gefährdet ist – also ist auch kein Mensch für das verantwortlich, was als Nächstes passiert. - **Die Stufe pendelt.** Eine Neuberechnung verschiebt einen Account über einen Schwellenwert und wieder zurück, und jede Überschreitung ist ein weiterer Trigger. ### Ein Dashboard Eine nach Risiko sortierte Liste ist wirklich nützlich und völlig unzureichend, weil sie davon abhängt, dass jemand beschließt hinzuschauen. Health Scoring rechtfertigt seinen Aufwand, wenn es die richtige Person unterbricht; ein Dashboard unterbricht niemanden. ## 03 · Datenmodell ### Eine Health-Konfiguration pro Untertyp von Datensätzen Health ist keine Einstellung für den ganzen Space. Ein Konfigurationsdatensatz nennt einen `entityType` *und* eine `typeId` – einen bestimmten Untertyp von Datensätzen –, sodass ein Account-Typ, der einen zahlenden Kunden darstellt, nach anderen Regeln und mit anderen Stufen bewertet wird als einer, der einen Interessenten darstellt. In einem Live-Space gibt es **fünfzehn Konfigurationen auf Account, eine pro Account-Typ, und genau eine ist aktiviert.** **Quelle.** Coevera-Hilfecenter, [Account management — using account health in Coevera](https://help.coevera.com/en/articles/5609036-account-management-using-account-health-in-coevera), für die Funktion so, wie ein Administrator sie konfiguriert. > **Das ist die Tatsache, die viele überrascht.** Health zu aktivieren ist eine Entscheidung pro > Untertyp, und die Untertypen, die Sie nicht bewerten, tragen trotzdem eine vollständige > Konfiguration. Einen Kunden anders zu bewerten als einen Interessenten ist genau der Sinn – aber > ebenso die Wartungsfolge in §6. ### Was eine Konfiguration enthält | Eigenschaft | Bedeutung | |---|---| | `categories` | Die Stufen. Jede hat eine Bezeichnung, einen ganzzahligen Schwellenwert und eine Farbe. Standardmäßig vier: Critical, Poor, Neutral, Good | | `calculationType` | `Manual` – jede Regel trägt Punkte, die sich summieren – oder `Priority` – die Regeln sind geordnet und tragen keine Punkte | | `healthIndicators` | Die Bewertungsregeln | | `criticalHealthIndicators` | Eine **separate** Regelmenge für Ausschlussbedingungen | | `isEnabled`, `lastRecalculation`, `calculationProgress` | Ob sie läuft, wann sie zuletzt lief und wie weit eine laufende Neuberechnung gekommen ist | ### Was jeder Datensatz bekommt | Am Datensatz | Typ | Hinweise | |---|---|---| | `healthStatus` | integer | Der Score. **Schreibgeschützt** – er gehört der Engine | | `healthCategory` | id | Die ermittelte Stufe. **Beschreibbar** – was in zweierlei Hinsicht wichtig ist, siehe §5 und §6 | | `health` | object | `score`, `trend`, Ergebnisse pro Indikator, `lastCalculation` | Der Trend ist ein echtes Enum – `Increasing`, `Decreasing`, `NoChange`, `Critical` – und nichts, was Sie ableiten müssen. Und jeder Indikator meldet einzeln `Ok`, `Error` oder `Critical`, mit **dem Datum seiner letzten Änderung**, sodass sich „Dieser Account fällt seit März durch diese Prüfung“ direkt am Datensatz beantworten lässt. ### Der Verlauf ist der Teil, den man kennen sollte Health führt einen tageweisen Verlauf. Jeder Eintrag enthält das Datum, den Score, den Trend und eine Liste von **Änderungen** – und jede Änderung nennt eine `scoreDifference`, die `ruleId` und die `fieldId`, die sich bewegt hat. Das ist eine tagesgenaue Zuordnung. Sie macht den Unterschied zwischen „Dieser Account steht bei 55“ und *„Dieser Account hat am Vierzehnten 25 Punkte verloren, als die Regel zur Lizenzauslastung nicht mehr zutraf“*. Sie ist auch die Antwort auf die schwierigste Anforderung aus §1, und sie ist der stärkste einzelne Grund, die Engine zu nutzen, statt eine Zahl in einem Feld zu berechnen. ### Die verworfene Alternative Health als benutzerdefinierte Felder zu modellieren – ein Score-Feld, ein Stufen-Dropdown, ein Datum der letzten Bewertung – ist der Reflex. Das reproduziert den Score und sonst nichts: keinen Verlauf, keinen Trend, keinen Zustand pro Indikator, keine Zuordnung und keine Neuberechnung. Eine wirklich andere Struktur *ist* dann gerechtfertigt, wenn jede Health-Bewertung ein prüfbarer Datensatz mit eigenem Verantwortlichen und eigenem Lebenszyklus sein muss – eine dokumentierte periodische Überprüfung statt eines laufenden Signals. Das ist ein verknüpfter untergeordneter Datensatz, und den Rahmen für diese Entscheidung liefert [Blueprint 003](https://blueprints.coevera.com/de/blueprints/where-should-this-data-live/). ## 04 · Konfiguration auf Feldebene ### Der Aufbau einer Indikatorregel | Eigenschaft | Zweck | |---|---| | `field` | Die ID des geprüften Felds | | `operator` | Einer von 23: `Is`, `IsNot`, `IsEmpty`, `IsNotEmpty`, `Less`, `LessOrEqual`, `More`, `MoreOrEqual`, `Between`, `BetweenNot`, `Contains`, `ContainsNot`, `Has`, `HasNot`, `RelativePeriod`, `RelativePeriodNot`, `In`, `InNot`, `StartsWith`, `EndsWith`, `IsActive`, `IsNotActive`, `Nop` | | `values` | Wogegen geprüft wird | | `score` | Punkte, die vergeben werden, wenn die Regel zutrifft | | `description` | **Die Regel in Worten.** Optional, und in §6 geht es darum, was passiert, wenn sie leer bleibt | `RelativePeriod` ist der Operator, zu dem Sie am häufigsten greifen werden: Er prüft ein Datum gegen ein rollierendes Zeitfenster, und so lässt sich „hat in den letzten N Tagen synchronisiert“ oder „hat in diesem Quartal einen Datensatz angelegt“ ausdrücken, ohne dass ein geplanter Job ein Kennzeichen pflegt. Sein Wert ist eine vierteilige Liste – ein Modus, eine Richtung, eine Einheit und eine Anzahl, wie in `["Custom", "Last", "Day", "14"]` für „innerhalb der letzten vierzehn Tage“. ### Boolesche Regeln haben keinen Operator Eine Bedingung auf einer Checkbox speichert **überhaupt keinen Operator**: `operator: null`, wobei der Wert die Bedeutung trägt – `"1"` für wahr, `"0"` für falsch. Ein kritischer Indikator, der ein Kennzeichen für die Übergabe an das Inkasso überwacht, ist daher `null` plus `"1"`, was „dieses Kästchen ist angehakt“ bedeutet. > **Das ist die Kodierung, keine defekte Regel.** Dieselbe Konvention taucht in Prozessfiltern > auf, wo Unterdrückungsbedingungen `null` mit `"0"` für „ist falsch“ speichern. Die praktische > Konsequenz: **Lesen Sie einen Operator nie ohne seinen Wert** – bei einer booleschen Regel *ist* > der Wert die Bedingung, und eine Überprüfung, die nur die Operatoren durchsieht, erkennt eine > scheinbare Lücke genau dort, wo die Logik tatsächlich steckt. ### Indikatoren wählen: Signale, keine Meinungen Die Faustregel, die den Kontakt mit der Realität übersteht: Ein Indikator sollte etwas sein, **das der Kunde tut**, nicht etwas, das ein Kollege erfasst. Eine Live-Konfiguration hat sieben Regeln – vier gewichtete Indikatoren, einen pro Dimension, und drei kritische: | Dimension | Indikator | Operator | Punkte | |---|---|---|---| | Nutzen sie es? | Lizenzauslastung in % | `More` | 25 | | Ist es noch verbunden? | Datum der letzten Telemetrie-Synchronisierung | `RelativePeriod` | 25 | | Arbeiten sie darin? | Datum, an dem der Kunde zuletzt einen Datensatz angelegt hat | `RelativePeriod` | 25 | | Hat der Support Mühe? | Rollup der Tickets, die länger als zwei Wochen offen sind | `Is` | 20 | | **Kritische Indikatoren – jeder mit `-1` bewertet** | | | | | Kommerziell intakt? | Account-Status | `IsNot` | `-1` | | Eingebrochene Nutzung | Lizenzauslastung in % unter einer Untergrenze | `Less` | `-1` | | Zahlen sie? | Kennzeichen für die Übergabe an das Inkasso | — | `-1` | Achten Sie auf die Form, nicht auf die Einzelheiten. Jeder gewichtete Indikator ist eine Tatsache über Produktnutzung oder Servicequalität; jeder kritische Indikator ist eine Tatsache über die Geschäftsbeziehung. Beachten Sie auch, dass **ein Feld in beiden Mengen mit unterschiedlichen Operatoren vorkommt** – eine Lizenzauslastung über einem Zielwert bringt 25 Punkte, unter einer Untergrenze ist sie ein Ausschlusskriterium. So ist es gedacht, eine Kennzahl auszudrücken, die sowohl einen gesunden als auch einen fatalen Bereich hat. Daraus ergibt sich auch eine Entscheidung, die Sie bewusst treffen sollten: **Die gesunde Untergrenze und die kritische Obergrenze müssen nicht zusammenfallen.** Wo sie es nicht tun, erhalten Accounts in der Lücke für diesen Indikator keine Punkte und sind auch nicht kritisch – was oft genau richtig ist, denn das ist der Bereich, in dem eine Kennzahl bloß mittelmäßig ist. Aber es ist eine Entscheidung, und wer sie implizit lässt, sorgt dafür, dass niemand sagen kann, was die Lücke bedeuten sollte. ### Die Stufen, und wie „kritisch“ sie kurzschließt Kategorien tragen einen ganzzahligen Schwellenwert, der als Obergrenze der Stufe gelesen wird: | Stufe | Gewichtete Konfiguration | Prioritätsbasierte Konfiguration | |---|---|---| | Critical | `-1` | `-1` | | Poor | 35 | 30 | | Neutral | 75 | 80 | | Good | 100 | 100 | Der elegante Teil ist, dass die Critical-Stufe bei `-1` liegt. Nach den gespeicherten Werten zieht ein kritischer Indikator keine Punkte ab – **er setzt den Score auf `-1`**, was unter der Obergrenze jeder anderen Stufe liegt, sodass eine einzige zutreffende kritische Regel den Account in Critical einordnet, egal wie gut die gewichteten Regeln bewertet haben. Ein Account kann jede Lizenz nutzen, täglich synchronisieren und keine Tickets eröffnen und trotzdem Critical sein, weil er ans Inkasso übergeben wurde. Das ist korrekt, und Sie bekommen es ohne eine einzige Zeile Automatisierung. Das ist aus den gespeicherten Regel-Scores und Stufenschwellen abgeleitet; in einer Neuberechnung wurde es nicht beobachtet. Beachten Sie auch, dass diese beiden Live-Konfigurationen ihre Stufen bei **unterschiedlichen Schwellenwerten** setzen – 35/75 gegenüber 30/80. Derselbe Score ist unter einem Untertyp Poor und unter einem anderen Neutral, was eine Eigenschaft der Konfiguration pro Untertyp ist und eine Falle für jeden, der Scores über Typen hinweg vergleicht. ### Gewichtet oder prioritätsbasiert | `calculationType` | Wie das Ergebnis zustande kommt | Einsetzen, wenn | |---|---|---| | `Manual` | Jede Regel trägt Punkte; die Punkte zutreffender Regeln ergeben summiert den Score | Sich mehrere Teilsignale aufaddieren sollen – der Normalfall bei einem Kunden | | `Priority` | Die Regeln sind geordnet und tragen `0` Punkte; die Position entscheidet über das Ergebnis | Ein dominantes Signal den Ausschlag geben soll, mit den übrigen als Rückfalloptionen | Im Live-Einsatz tragen die gewichteten Konfigurationen explizite Punkte bei jeder Regel und die prioritätsbasierten bei allen Regeln null – daran erkennen Sie auf einen Blick, welchen Modus eine Konfiguration tatsächlich verwendet. ## 05 · Automatisierung & Logik ### Health ist eine Trigger-Fläche `healthCategory` ist aus Sicht der Automatisierung ein gewöhnliches Feld, also kann ein änderungsgesteuerter Prozess es überwachen. Im Produktivbetrieb verifiziert: Ein Prozess löst bei Account-Aktualisierung aus, mit **genau einem überwachten Feld – der Health-Kategorie** –, filtert auf die Nähe zur Verlängerung und schickt dem Verantwortlichen für die Kundenbeziehung eine E-Mail. Dieser Prozess tut eine Sache: Er informiert einen Menschen. Er verschickt keine Nachricht an den Kunden und legt keine Aufgabe im Namen des Kunden an. Und genau das ist das ganze Design. ### Die zwei Ebenen | | Ebene 1 – die Maschine bemerkt | Ebene 2 – ein Mensch legt sich fest | |---|---|---| | Trigger | Die Health-Kategorie ändert sich | Ein **Einschätzungsfeld** ändert sich | | Geschrieben von | Der Health-Engine | Dem Verantwortlichen für die Kundenbeziehung, von Hand | | Aktion | Den Verantwortlichen benachrichtigen. Sonst nichts | Die vollständige Outreach-Kette | | Bedeutung | „Einen Blick wert“ | „Ich habe diesen Account als gefährdet eingestuft“ | Das Einschätzungsfeld ist ein gewöhnliches benutzerdefiniertes Radio-Feld – eine kleine Menge expliziter Ergebnisse wie *Verlängerung wahrscheinlich*, *gefährdet*, *Verlust erwartet*. Der Account-Verantwortliche füllt es aus, nachdem er tatsächlich hingeschaut hat. Ein Produktivprozess überwacht genau dieses eine Feld und schickt bei einer Änderung dem Verantwortlichen und dem Relationship Manager eine E-Mail und übergibt dann an **drei Unterprozesse**, die die Folgearbeit anlegen. Dieses Übergabemuster ist keine Dekoration – ein Prozess trägt einen einzigen Filter, dessen Zweige nach dem Prinzip „der erste Treffer gewinnt“ ausgewertet werden, also müssen unabhängige Folgen einer Einschätzung separate Prozesse sein. [Blueprint 011](https://blueprints.coevera.com/de/blueprints/keeping-hundreds-of-automations-maintainable/) behandelt diese Einschränkung und die Benennungsdisziplin, die eine solche Kette lesbar hält. > **Warum sich der Umweg lohnt.** Das Einschätzungsfeld ist ein Nachweis, dass eine namentlich > bekannte Person diesen Account an diesem Datum bewertet und zu einem Schluss gekommen ist. Das > ist prüfbar, auswertbar und nachvollziehbar, wenn der Account trotzdem abwandert – was alles > nicht für eine Schwellenwertüberschreitung gilt. Es bedeutet auch, dass eine pausierte > Integration den *Score* verschlechtert, ohne eine einzige Aktion gegenüber dem Kunden zu > erzeugen. ### Das Sicherheitsnetz Ebene 1 löst nur aus, wenn sich die Stufe *ändert*. Ein Account, der seit vier Monaten Poor ist, löst sie nie wieder aus, und genau diesen Account müssen Sie sich am dringendsten ansehen. Das Muster braucht also ein drittes Element: einen **geplanten Durchlauf**, der Accounts kurz vor der Verlängerung findet, deren Stufe etwas anderes als Good ist oder deren Einschätzungsfeld seit neunzig Tagen nicht angefasst wurde, und eine Überprüfungsaufgabe anlegt. Änderungsgesteuerte Automatisierung erkennt Verschlechterung; geplante Automatisierung erkennt Vernachlässigung. Sie brauchen beides, und beide versagen auf unterschiedliche Weise. ### Neuberechnung, und was sie für das Timing bedeutet Der Score ist nicht live. Eine Konfiguration speichert `lastRecalculation` und einen Prozentwert `calculationProgress`, und die Neuberechnung lässt sich für einen Datensatz oder für alle Datensätze anstoßen. Die Kausalkette lautet also: `field changes` → `recalculation runs` → `score and band change` → `process fires` Jede Annahme zum Timing sollte auf dem zweiten Pfeil aufbauen, nicht auf dem ersten. Im Live-Space hatte die aktivierte Konfiguration am selben Morgen neu berechnet, an dem sie ausgelesen wurde. ## 06 · Grenzen & Kompromisse > **Der Score kann sich nicht selbst erklären, wenn Sie ihn nicht dazu bringen.** Jede > Indikatorregel hat ein `description`-Feld, und in der untersuchten Konfiguration **war jede > Beschreibung bei jeder Regel in allen fünfzehn Konfigurationen leer**. Der Apparat, der „Warum > ist dieser Account Poor?“ beantworten soll, ist im Produkt enthalten und bleibt standardmäßig > leer, sodass sich die Antwort nur erreichen lässt, indem man die Konfiguration öffnet und > Feldkennungen von Hand auflöst. Füllen Sie das Feld aus, während Sie jede Regel schreiben; > nichts wird Sie jemals daran erinnern. - **Der Score wird neu berechnet, nicht live geführt.** Automatisierung löst bei der Neuberechnung aus, „sofort, wenn die Auslastung sinkt“ ist also nicht verfügbar, und eine Deutung einer Stufenänderung am selben Tag ist nur so gut wie der Takt der Neuberechnung. - **Ein Indikator auf einem replizierten Feld verwandelt einen Ausfall in ein Abwanderungssignal.** Wo ein Indikator ein Feld liest, das einem anderen System gehört – ein Telemetrie-Synchronisierungsdatum, einen Abonnementstatus –, verschlechtert eine stockende Integration diesen Indikator bei allen Accounts gleichzeitig, und die Engine kann „der Kunde nutzt es nicht mehr“ nicht von „die Leitung liefert nicht mehr“ unterscheiden. Das ist eine begründete Folgerung aus zwei verifizierten Tatsachen, kein beobachteter Vorfall: Live-Indikatoren lesen tatsächlich replizierte Datumsfelder, und [Blueprint 009](https://blueprints.coevera.com/de/blueprints/automating-on-integration-owned-fields/) dokumentiert, was ein mehrtägiger Replikationsausfall im Produktivbetrieb bewirkt hat. Die Abhilfe ist dieselbe, die dieser Blueprint vorschreibt – eine Prüfung der Synchronisierungsaktualität, die unabhängig von den synchronisierten Daten ist –, plus die Regel aus §5, dass ein Score nie von sich aus Kundenkontakt auslöst. - **Die Health-Kategorie ist beschreibbar.** Nützlich, weil ein Mensch eine Stufe übersteuern kann, die die Engine falsch ermittelt hat – und riskant, weil sich eine manuell gesetzte Stufe nicht von einer berechneten unterscheiden lässt und die nächste Neuberechnung sie überschreiben kann. Wenn Übersteuerungen wichtig sind, erfassen Sie sie in einem eigenen Feld. - **Die Konfiguration vervielfacht sich mit den Untertypen.** Fünfzehn Account-Typen bedeuteten fünfzehn Konfigurationen, jede mit eigenen Stufen und Regeln, alle bis auf eine abgeschaltet. Einen Indikator zum „Customer-Health-Modell“ hinzuzufügen heißt, die aktivierte Konfiguration zu bearbeiten und daran zu denken, dass die anderen auseinandergelaufen sind – im Live-Space setzen die gewichteten und die prioritätsbasierten Konfigurationen ihre Stufen bereits bei unterschiedlichen Schwellenwerten. Es gibt keine Vererbung. - **Eine boolesche Regel hat keinen Operator, und der Wert trägt die Bedeutung.** Eine Bedingung auf einer Checkbox speichert `operator: null` mit einem Wert von `"1"` für wahr oder `"0"` für falsch. Ein kritischer Indikator, der ein Kennzeichen für die Übergabe an das Inkasso liest, ist also `null` plus `"1"` – „dieses Kästchen ist angehakt“. Das ist die normale Kodierung der Plattform und keine defekte Regel, und es bedeutet, dass **sich ein Null-Operator nicht für sich allein lesen lässt: Der Wert ist die ganze Bedingung.** Alles, was eine Konfiguration prüft, muss beides lesen, und ein Diff, der nur den Operator zeigt, zeigt nichts. - **Scores müssen die Obergrenze der Stufe nicht erreichen.** In der gewichteten Live-Konfiguration ergeben die vier Indikatoren zusammen 95 bei einer Good-Obergrenze von 100, ein perfekter Account erzielt also 95. Das ist harmlos – die Stufe ist eine Obergrenze, kein Ziel –, macht den Rohscore aber zu einer schlechten Zahl, um sie jemandem zu zeigen, und zu einer noch schlechteren, um sie über Untertypen hinweg zu vergleichen. - **Indikatoren aus verknüpften Datensätzen sind unbewiesen.** Die Konfiguration lässt Indikatorregeln zu, die über einen Lookup aus einer verknüpften Entität stammen, und im untersuchten Space wurde diese Möglichkeit nicht genutzt – jede Live-Regel las die eigenen Felder des Accounts. Im Schema verifiziert, nicht im Verhalten verifiziert. Wo Sie „keine Aktivität in 90 Tagen“ brauchen, ist ein Rollup-Feld am Account der Weg, von dem bekannt ist, dass er funktioniert. - **Nur Account wurde mit Health beobachtet.** Die Eigenschaft für den Entitätstyp lässt andere zu; jede Live-Konfiguration lag auf Account. Anderswo nicht getestet. ### Der Kompromiss, den man klar benennen sollte Die Engine liefert Verlauf, Trend, Zustand pro Indikator, tagesgenaue Zuordnung und eine Stufe, die Automatisierung überwachen kann – nichts davon würden Sie von Hand korrekt bauen, und all das entsteht allein durch Konfiguration. Was sie nicht liefert, ist eine Vorhersage. Es gibt kein Modell, keine vorgeschlagene Gewichtung, kein Lernen aus Accounts, die tatsächlich abgewandert sind; die Regeln und die Punkte sind Ihre Hypothese darüber, warum Kunden gehen, und die Engine wendet sie nur konsistent an. Das ist ein fairer Handel, vorausgesetzt, die Hypothese wird überprüft, wenn sie falsch ist – wofür der Verlauf da ist, und der Grund, warum §5 darauf besteht, dass die Einschätzung eines Menschen, nicht der Score, als Entscheidung in den Datensatz eingeht. ## 07 · Verifizierung Am 2026-09-10 aus einem Live-Produktiv-Space ausgelesen: die vollständige Menge der Health-Konfigurationen, die aufgelösten Indikatorfelder und die Prozesse, die das Ergebnis verwenden. - **Fünfzehn Health-Konfigurationen auf Account**, eine pro Account-Typ, von denen genau eine aktiviert war und einen Zeitstempel der Neuberechnung vom Morgen des Auslesens trug. Die anderen vierzehn waren konfiguriert und abgeschaltet. - **Beide Berechnungsmodi wurden im Live-Einsatz gefunden** – gewichtete Konfigurationen mit expliziten Punkten bei jeder Regel, prioritätsbasierte mit null bei allen –, und sie setzen ihre Stufen bei unterschiedlichen Schwellenwerten, 35/75 gegenüber 30/80. - **Der Mechanismus der kritischen Indikatoren wurde anhand der Daten bestätigt**: Jede kritische Regel in jeder Konfiguration trägt `score: -1`, und jede Konfiguration definiert eine Critical-Stufe bei `-1`. Nach diesen gespeicherten Werten dominiert ein kritischer Indikator den Score; in einer Neuberechnung wurde das nicht beobachtet. - **Jede Feld-ID eines Indikators wurde zu ihrem Feld aufgelöst**, und daher stammen die vier Dimensionen in §4 – Auslastung, Aktualität der Telemetrie, vom Kunden erzeugte Datensätze, alternde Support-Tickets, dazu Account-Status und ein Inkasso-Kennzeichen als kritische Regeln. Ein Feld kommt in beiden Mengen mit gegensätzlichen Operatoren vor. - **Health als Trigger wurde verifiziert, nicht angenommen.** Ein aktivierter Live-Prozess löst bei Account-Aktualisierung mit einem einzigen überwachten Feld aus, und diese Feld-ID wird zur nativen Health-Kategorie aufgelöst. Ein zweiter Live-Prozess überwacht ein einzelnes benutzerdefiniertes Radio-Feld – die Einschätzung – und übergibt an drei Unterprozesse. - **Die 23 Operatoren und die vier Trendwerte** wurden aus dem Schema gelesen, ebenso der Score, die Stufe und der Zustand pro Indikator am Datensatz sowie die Struktur des Verlaufs mit der Zuordnung nach Score-Differenz, Regel und Feld. - **Jede Regelbeschreibung war leer**, über alle fünfzehn Konfigurationen hinweg. - **Die Regelwerte wurden zusammen mit den Operatoren gelesen**, und daraus ergibt sich die boolesche Kodierung in §4: Die eine Regel ohne Operator kombiniert ihn mit einem Wert von `"1"`. Dieselbe Konvention `operator: null` taucht in Prozessfiltern mit einem Wert von `"0"` für eine Prüfung auf falsch auf, die Kodierung ist also über zwei unabhängige Subsysteme hinweg konsistent, und der Wert unterscheidet die beiden Bedeutungen. - **Die Wertgrammatik für relative Zeiträume wurde aus Live-Regeln gelesen** – eine vierteilige Liste aus Modus, Richtung, Einheit und Anzahl, also die in §4 angegebene Form. **Nicht beobachtet, und ausdrücklich so benannt:** - Eine laufende Neuberechnung oder der Takt, in dem sie läuft. Nur dass sie gelaufen war und dass ein Prozentwert für den Fortschritt existiert. - Indikatoren aus einer verknüpften Entität über einen Lookup – im Schema verifiziert, nicht im Verhalten verifiziert. - Health auf einer anderen Entität als Account. - Ob eine manuell geschriebene Health-Kategorie die nächste Neuberechnung übersteht. - Ein zutreffender kritischer Indikator, der den Score während einer Neuberechnung auf `-1` setzt. Dieses Verhalten ist aus den gespeicherten Regel-Scores und der Schwelle der Critical-Stufe abgeleitet. - Die genaue Auswertungsreihenfolge im Prioritätsmodus, über die Tatsache hinaus, dass die Reihenfolge der Regeln entscheidet und die Punkte null sind. ### Woran Sie eine Regression erkennen - **Viele Accounts wechseln am selben Tag die Stufe.** Echte Verschlechterung ist nicht synchronisiert. Eine flächendeckende Bewegung bedeutet, dass der Eingangswert eines Indikators kaputt ist – meist ein repliziertes Feld –, und sie wird wie eine Abwanderungswelle aussehen. - **Ein Zeitstempel der Neuberechnung, der nicht mehr weiterläuft.** Der Score friert einfach ein; nichts schlägt fehl, und jede Stufe auf jedem Datensatz wird stillschweigend zu einer Aussage über die Vergangenheit. - **Stufenänderungen lösen aus, während Einschätzungsfelder unberührt bleiben.** Ebene 1 funktioniert und Ebene 2 nicht: Menschen werden benachrichtigt, und niemand entscheidet. Das ist das Fehlerbild, das von der Automatisierungsseite aus am gesündesten aussieht. - **Accounts, die monatelang in Poor stehen, ohne Überprüfungsaufgabe.** Der geplante Durchlauf läuft nicht mehr, und änderungsgesteuerte Automatisierung wird sie nie erfassen, weil sich ihre Stufe nicht ändert. ## Verwandte Blueprints - [Blueprint 009 — Wie automatisieren Sie auf CRM-Feldern, die einem anderen System gehören?](https://blueprints.coevera.com/de/blueprints/automating-on-integration-owned-fields/) – Pflichtlektüre, wenn ein Indikator ein repliziertes Feld liest. - [Blueprint 008 — Wie prognostizieren Sie Verlängerungen, die noch gar nicht als Datensätze existieren?](https://blueprints.coevera.com/de/blueprints/forecasting-renewals-before-they-exist/) – die Umsatzseite derselben Verlängerung; Health ist die Risikoseite. - [Blueprint 011 — Wie halten Sie Hunderte von CRM-Automatisierungen wartbar?](https://blueprints.coevera.com/de/blueprints/keeping-hundreds-of-automations-maintainable/) – warum sich eine Einschätzung in mehrere Prozesse auffächert. - [Blueprint 012 — Wie führen Sie eine Kundenumfrage aus Ihrem CRM durch und bekommen die Antworten zurück an den Datensatz?](https://blueprints.coevera.com/de/blueprints/customer-survey-answers-onto-the-record/) – wie eine beantwortete Frage an den Datensatz kommt, wo eine Health-Regel sie lesen kann. - [Blueprint 003 — Wie modellieren Sie etwas, für das Ihr CRM kein Objekt hat?](https://blueprints.coevera.com/de/blueprints/where-should-this-data-live/) – die Entscheidung zwischen einem laufenden Signal und einem prüfbaren Bewertungsdatensatz. ## Häufige Fragen ### Wie erkennen Sie abwanderungsgefährdete Kunden vor der Verlängerung? Nutzen Sie die native Health-Engine für Entitäten statt eines von Hand gepflegten Score-Felds. Health wird pro Untertyp von Datensätzen konfiguriert: Eine Reihe von Indikatorregeln, die jeweils ein Feld, einen Operator und eine Punktzahl nennen, ergibt einen numerischen Score, eine von vier Stufen und einen Trend. Eine separate Reihe kritischer Indikatoren ist mit einem Score von minus eins gespeichert, und eine Critical-Stufe liegt bei minus eins, sodass ein zutreffender kritischer Indikator die schlechteste Stufe erzwingen sollte, unabhängig davon, wie die anderen Regeln bewertet haben – abgeleitet aus diesen gespeicherten Werten, nicht in einer Neuberechnung beobachtet. Die Health-Stufe des Accounts ändert sich dann, und ein Prozess kann auf diese Änderung auslösen. ### Sollte ein sinkender Health Score die Kundenintervention direkt auslösen? Nein. Ein Score ist ein Wahrscheinlichkeitssignal und eine Intervention ist eine Verpflichtung, deshalb sollten die beiden nicht direkt verbunden werden. Lassen Sie die Health-Änderung die Person benachrichtigen, der die Kundenbeziehung gehört, und lassen Sie diese Person eine Einschätzung in einem eigenen Feld erfassen. Die Änderung dieses Einschätzungsfelds löst die Outreach-Kette aus. So verhindern Sie, dass ein Datenqualitätsproblem oder eine pausierte Integration Aktionen gegenüber dem Kunden erzeugt. ### Wird ein Health Score im CRM in Echtzeit berechnet? Nein. Der Score wird neu berechnet, statt live zu sein: Die Health-Konfiguration speichert einen Zeitstempel der letzten Neuberechnung und einen Prozentwert für den Berechnungsfortschritt, und die Neuberechnung lässt sich für einen einzelnen Datensatz oder für alle auslösen. Ein Prozess, der auf eine Health-Änderung auslöst, löst also aus, wenn die Neuberechnung läuft, und nicht in dem Moment, in dem sich das zugrunde liegende Feld geändert hat. ### Welche Felder eignen sich als Indikatoren für die Kundengesundheit? Operative Signale, die der Kunde selbst erzeugt, statt Meinungen, die jemand erfasst. Ein bewährtes Set deckt vier Dinge ab: ob das Produkt genutzt wird, ob es noch verbunden ist, ob der Support Mühe hat und ob die Geschäftsbeziehung intakt ist – zum Beispiel die Lizenzauslastung, das Datum der letzten Telemetrie-Synchronisierung, das Datum, an dem der Kunde zuletzt einen Datensatz angelegt hat, ein Rollup der Support-Tickets, die älter als zwei Wochen sind, der Account-Status und ein Kennzeichen für die Übergabe an das Inkasso. ### Warum können zwei Accounts mit demselben Health Score in unterschiedlichen Stufen liegen? Weil die Stufen pro Untertyp von Datensätzen konfiguriert werden und jeder Untertyp eigene Schwellenwerte hat. In einem Live-Space liegen die Stufengrenzen der gewichteten Konfigurationen bei 35 und 75, die der prioritätsbasierten bei 30 und 80, sodass derselbe Score unter einem Untertyp als Poor und unter einem anderen als Neutral gilt. Die Health-Konfiguration ist nicht global. --- Herausgegeben von Coevera. Auf das wiederverwendbare Muster abstrahiert – keine Kundennamen, keine Kundendaten, keine personenbezogenen Daten.