---
title: "Come individua i clienti a rischio di abbandono prima del rinnovo?"
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/it/blueprints/customer-health-score-churn-risk/
language: it
translation_of: https://blueprints.coevera.com/blueprints/customer-health-score-churn-risk/
author: Lucia Schmidt
publisher: Coevera
customer_data: none
---

# Come individua i clienti a rischio di abbandono prima del rinnovo?

**Risposta breve.** Coevera ha un **motore di salute nativo**, quindi il punteggio è
configurazione e non un campo che qualcuno mantiene. Si imposta **per sottotipo di record**: un
elenco di **regole indicatore**, ciascuna composta da un campo, un operatore e un punteggio, si
traduce in un punteggio numerico, in una di quattro **fasce** e in un **trend**. Un insieme
separato di **indicatori critici** vale `-1`, e poiché anche la fascia Critical è `-1`, una sola
regola critica soddisfatta, stando ai valori memorizzati, impone la fascia peggiore per quanto
bene abbia valutato tutto il resto; lo si deduce, non è stato osservato in un ricalcolo.

La fascia di salute è un trigger legittimo per un processo, verificato in produzione. Ma la regola
di progettazione che fa funzionare il tutto è: **lasci che il punteggio indirizzi l'attenzione, e
che sia una persona a impegnarsi.** I cambiamenti di salute avvisano il responsabile della
relazione; il responsabile registra un verdetto in un campo dedicato; ed è **il campo verdetto** a
far scattare il contatto con il cliente.

L'avvertenza: il punteggio viene **ricalcolato, non è in tempo reale**. L'automazione scatta
quando viene eseguito il ricalcolo, non quando si è mosso il campo sottostante.

## 01 · Il problema di business

Un cliente non abbandona il giorno del rinnovo. Abbandona nei mesi precedenti, in silenzio, e la
conversazione sul rinnovo è il momento in cui lo si scopre. A quel punto gli interventi utili,
riparare ciò che si è rotto, formare il team che non è mai stato avviato all'uso, raggiungere lo
sponsor che se n'è andato, arrivano tutti troppo tardi per contare.

Il requisito è quindi un preavviso che raggiunga davvero qualcuno:

- una valutazione costante di ogni cliente, aggiornata senza che nessuno debba mantenerla;
- costruita su segnali generati dal cliente, non su opinioni che qualcuno si ricorda di
  registrare;
- espressa in modo che **«perché questo account è giallo?»** abbia una risposta;
- che arrivi *alla persona responsabile della relazione*, non su una dashboard;
- e che porti a un'azione specifica a cui qualcuno si impegna, con la traccia che sia avvenuta.

Il punto centrale è quello su cui muore la maggior parte dei punteggi di salute. Un numero che
nessuno sa spiegare viene contestato, poi ignorato. L'ultimo è quello su cui muore il resto: un
segnale che non produce alcun obbligo non produce alcun risultato.

## 02 · Perché l'approccio ovvio non funziona

### Un campo salute che qualcuno mantiene

Il primo istinto è un menu a tendina, verde, giallo, rosso, che imposta l'account manager.
Descrive l'umore dell'account manager, si deteriora nel momento in cui l'attenzione si sposta
altrove, ed è sempre più obsoleto proprio sugli account che nessuno sta osservando. Che sono gli
account a rischio.

### Un campo calcolato o di rollup

L'istinto migliore è calcolarlo: un campo formula o rollup che produce un numero. Così si ottiene
l'aritmetica e nulla dell'apparato. Non c'è cronologia, quindi non si vede un declino; nessun
trend, quindi un 60 che scende da 90 appare identico a un 60 che sale da 30; nessuna attribuzione,
quindi non si può dire quale input si sia mosso; e nessuna fascia, quindi ogni utilizzatore del
numero reinventa le soglie. Si finisce per ricostruire male il motore di salute, in un campo.

### Collegare l'intervento direttamente al punteggio

L'errore con le conseguenze più gravi è architetturale più che meccanico: far partire il contatto
con il cliente direttamente dal superamento di una soglia da parte del punteggio. È a un solo nodo
di processo di distanza ed è sbagliato, perché **un punteggio è un segnale probabilistico e il
contatto con il cliente è un impegno**. Collegarli comporta tre conseguenze:

- **I problemi dei dati diventano contatti con i clienti.** Un'integrazione va in pausa, un
  indicatore peggiora su tutto il parco clienti, e il CRM scrive a metà della sua base clienti per
  un problema che non esiste.
- **Nessuno è titolare del giudizio.** Quando è una soglia di punteggio a inviare l'email, nessuna
  persona ha mai deciso che questo account fosse a rischio, quindi nessuna persona risponde di ciò
  che accade dopo.
- **La fascia oscilla.** Un ricalcolo sposta un account oltre una soglia e poi indietro, e ogni
  attraversamento è un altro trigger.

### Una dashboard

Un elenco ordinato degli account a rischio è davvero utile e del tutto insufficiente, perché
dipende dal fatto che qualcuno scelga di guardarlo. Il punteggio di salute ripaga il suo costo
quando interrompe la persona giusta; una dashboard non interrompe nessuno.

## 03 · Modello dati

### Una configurazione della salute per sottotipo di record

La salute non è un'impostazione valida per tutto lo spazio. Un record di configurazione indica un
`entityType` *e* un `typeId`, cioè uno specifico sottotipo di record, quindi un tipo di account
che rappresenta un cliente pagante viene valutato con regole e fasce diverse da uno che
rappresenta un potenziale cliente. In uno spazio in produzione ci sono **quindici configurazioni
su Account, una per tipo di account, ed esattamente una è attivata.**

**Fonte.** Centro assistenza Coevera, [Account management — using account health in
Coevera](https://help.coevera.com/en/articles/5609036-account-management-using-account-health-in-coevera),
per la funzionalità così come la configura un amministratore.

> **È questo il fatto che sorprende.** Attivare la salute è una decisione per sottotipo, e i
> sottotipi che non vengono valutati hanno comunque una configurazione completa. Valutare un
> cliente in modo diverso da un potenziale cliente è proprio lo scopo, ma lo è anche la
> conseguenza per la manutenzione descritta nel §6.

### Che cosa contiene una configurazione

| Proprietà | Che cos'è |
|---|---|
| `categories` | Le fasce. Ognuna ha un'etichetta, una soglia intera e un colore. Quattro per impostazione predefinita: Critical, Poor, Neutral, Good |
| `calculationType` | `Manual`, in cui ogni regola ha punti che si sommano, oppure `Priority`, in cui le regole sono ordinate e non hanno punti |
| `healthIndicators` | Le regole di punteggio |
| `criticalHealthIndicators` | Un insieme di regole **separato** per le condizioni squalificanti |
| `isEnabled`, `lastRecalculation`, `calculationProgress` | Se è in funzione, quando è stata eseguita l'ultima volta e a che punto è un ricalcolo in corso |

### Che cosa riceve ogni record

| Sul record | Tipo | Note |
|---|---|---|
| `healthStatus` | intero | Il punteggio. **Sola lettura**: lo gestisce il motore |
| `healthCategory` | id | La fascia risultante. **Scrivibile**, il che conta in due modi: si vedano il §5 e il §6 |
| `health` | oggetto | `score`, `trend`, risultati per indicatore, `lastCalculation` |

Il trend è un vero enum, `Increasing`, `Decreasing`, `NoChange`, `Critical`, e non qualcosa da
derivare. E ogni indicatore riporta singolarmente `Ok`, `Error` o `Critical`, con **la data
dell'ultimo cambiamento**, quindi a «questo account fallisce questo controllo da marzo» si può
rispondere dal record.

### La cronologia è la parte da conoscere

La salute tiene una cronologia giorno per giorno. Ogni voce contiene la data, il punteggio, il
trend e un elenco di **variazioni**, e ogni variazione indica uno `scoreDifference`, il `ruleId` e
il `fieldId` che si è mosso.

È un'attribuzione giornaliera. È la differenza tra «questo account è a 55» e *«questo account è
sceso di 25 punti il quattordici, quando la regola sull'utilizzo delle licenze ha smesso di essere
soddisfatta»*. È anche la risposta al requisito più difficile del §1, ed è il motivo più forte in
assoluto per usare il motore anziché calcolare un numero in un campo.

### L'alternativa scartata

Modellare la salute come campi personalizzati, un campo punteggio, un menu a tendina per la
fascia, una data dell'ultima valutazione, è il riflesso. Riproduce il punteggio e nient'altro:
nessuna cronologia, nessun trend, nessuno stato per indicatore, nessuna attribuzione e nessun
ricalcolo. Una struttura davvero diversa *è* giustificata quando ogni valutazione della salute
deve essere un record verificabile con un proprio responsabile e un proprio ciclo di vita: una
revisione periodica documentata anziché un segnale costante. Si tratta di un record figlio
correlato, e il quadro per prendere questa decisione è il [Blueprint
003](https://blueprints.coevera.com/it/blueprints/where-should-this-data-live/).

## 04 · Configurazione a livello di campo

### L'anatomia di una regola indicatore

| Proprietà | Scopo |
|---|---|
| `field` | L'id del campo verificato |
| `operator` | Uno tra 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` | Il termine di confronto |
| `score` | I punti assegnati quando la regola è soddisfatta |
| `description` | **La regola a parole.** Facoltativa, e il §6 tratta di ciò che succede quando resta vuota |

`RelativePeriod` è quello da usare più spesso: verifica una data rispetto a una finestra mobile,
ed è così che si esprime «ha sincronizzato negli ultimi N giorni» o «ha creato un record in questo
trimestre» senza un job pianificato che mantenga un flag. Il suo valore è un elenco in quattro
parti, una modalità, una direzione, un'unità e un conteggio, come in `["Custom", "Last", "Day",
"14"]` per «negli ultimi quattordici giorni».

### Le regole booleane non hanno operatore

Una condizione su una casella di controllo non memorizza **alcun operatore**: `operator: null`,
con il valore che porta il significato, `"1"` per vero, `"0"` per falso. Un indicatore critico che
osserva un flag di invio al recupero crediti è quindi `null` più `"1"`, cioè «questa casella è
spuntata».

> **È la codifica, non una regola rotta.** La stessa convenzione compare nei filtri dei processi,
> dove i controlli di soppressione memorizzano `null` con `"0"` per «è falso». La conseguenza
> pratica: **non legga mai un operatore senza il suo valore**; in una regola booleana il valore
> *è* la condizione, e una revisione che scorre solo gli operatori vedrà una lacuna apparente
> proprio dove risiede la logica.

### Scegliere gli indicatori: segnali, non opinioni

La regola pratica che regge al confronto con la realtà è che un indicatore dovrebbe essere
qualcosa che **fa il cliente**, non qualcosa che registra un collega. Una configurazione attiva ha
sette regole: quattro indicatori ponderati, uno per dimensione, e tre critici:

| Dimensione | Indicatore | Operatore | Punti |
|---|---|---|---|
| Lo usano? | % di utilizzo delle licenze | `More` | 25 |
| È ancora connesso? | Data dell'ultima sincronizzazione della telemetria | `RelativePeriod` | 25 |
| Ci lavorano? | Data in cui il cliente ha creato l'ultimo record | `RelativePeriod` | 25 |
| L'assistenza è in difficoltà? | Rollup dei ticket aperti da più di due settimane | `Is` | 20 |
| **Indicatori critici, ciascuno con punteggio `-1`** |  |  |  |
| Commercialmente intatto? | Stato dell'account | `IsNot` | `-1` |
| Utilizzo crollato | % di utilizzo delle licenze sotto una soglia minima | `Less` | `-1` |
| Paga? | Flag di invio al recupero crediti | — | `-1` |

Guardi la forma più che i dettagli. Ogni indicatore ponderato è un fatto sull'utilizzo del
prodotto o sulla qualità del servizio; ogni indicatore critico è un fatto sul rapporto
commerciale. Si noti anche che **un campo compare in entrambi gli insiemi con operatori diversi**:
l'utilizzo delle licenze sopra un obiettivo vale 25 punti, e sotto una soglia minima squalifica. È
il modo previsto per esprimere una metrica che ha sia un intervallo sano sia uno fatale.

Crea anche una decisione da prendere deliberatamente: **la soglia minima sana e il limite critico
non devono per forza coincidere.** Dove non coincidono, gli account nell'intervallo intermedio non
ottengono punti per quell'indicatore e non sono nemmeno critici, il che spesso è esattamente
giusto, poiché è la fascia in cui una metrica è semplicemente mediocre. Ma è una scelta, e
lasciarla implicita significa che nessuno sa dire che cosa quell'intervallo dovesse significare.

### Le fasce, e come le scavalca il critico

Le categorie hanno una soglia intera, letta come limite superiore della fascia:

| Fascia | Configurazione ponderata | Configurazione per priorità |
|---|---|---|
| Critical | `-1` | `-1` |
| Poor | 35 | 30 |
| Neutral | 75 | 80 |
| Good | 100 | 100 |

La parte elegante è la fascia Critical posta a `-1`. Secondo i valori memorizzati, un indicatore
critico non sottrae punti: **porta il punteggio a `-1`**, che è sotto il limite superiore di ogni
altra fascia, quindi una sola regola critica soddisfatta porta l'account in Critical per quanto
bene abbiano valutato le regole ponderate. Un account può usare ogni licenza, sincronizzare ogni
giorno e non aprire alcun ticket, ed essere comunque Critical perché è finito al recupero crediti.
È corretto, e lo si ottiene senza una sola riga di automazione. Lo si deduce dai punteggi
memorizzati delle regole e dalle soglie delle fasce; non è stato osservato in un ricalcolo.

Si noti anche che quelle due configurazioni attive hanno le fasce a **soglie diverse**: 35/75
contro 30/80. Lo stesso punteggio è Poor con un sottotipo e Neutral con un altro, il che è una
caratteristica della configurazione per sottotipo e una trappola per chiunque confronti punteggi
tra tipi diversi.

### Ponderato o per priorità

| `calculationType` | Come si risolve | Quando usarlo |
|---|---|---|
| `Manual` | Ogni regola ha dei punti; i punti delle regole soddisfatte si sommano nel punteggio | Più segnali parziali devono sommarsi: il caso abituale per un cliente |
| `Priority` | Le regole sono ordinate e valgono `0` punti; è la posizione a decidere l'esito | Un segnale dominante deve decidere, con gli altri come alternative di riserva |

Nell'uso reale le configurazioni ponderate hanno punti espliciti su ogni regola e quelle per
priorità hanno zero su tutte: è così che si capisce a colpo d'occhio quale modalità una
configurazione stia davvero usando.

## 05 · Automazione e logica

### La salute è una superficie di trigger

Per l'automazione `healthCategory` è un campo ordinario, quindi un processo attivato dalle
modifiche può osservarlo. Verificato in produzione: un processo si attiva sull'aggiornamento di
Account con **esattamente un campo osservato, la categoria di salute**, filtra sulla vicinanza del
rinnovo e invia un'email al responsabile della relazione.

Quel processo fa una sola cosa: avvisa una persona. Non invia alcun messaggio al cliente e non
crea alcuna attività per conto del cliente. Ed è questo l'intero progetto.

### I due livelli

|  | Livello 1: la macchina nota | Livello 2: una persona si impegna |
|---|---|---|
| Trigger | Cambia la categoria di salute | Cambia un **campo verdetto** |
| Scritto da | Il motore di salute | Il responsabile della relazione, a mano |
| Azione | Avvisare il responsabile. Nient'altro | L'intera catena di contatti con il cliente |
| Significato | «Merita un'occhiata» | «Ho giudicato questo account a rischio» |

Il campo verdetto è un normale campo radio personalizzato: un piccolo insieme di esiti espliciti
come *rinnovo probabile*, *a rischio*, *perdita prevista*. È ciò che il responsabile dell'account
compila dopo aver davvero guardato. Un processo in produzione osserva quel solo campo e, quando
cambia, invia un'email al responsabile e al relationship manager e poi passa il testimone a **tre
sottoprocessi** che creano il lavoro di follow-up.

Quel passaggio di consegne non è decorazione: un processo porta un solo filtro i cui rami seguono
la regola della prima corrispondenza, quindi le conseguenze indipendenti di un verdetto devono
essere processi separati. Il [Blueprint
011](https://blueprints.coevera.com/it/blueprints/keeping-hundreds-of-automations-maintainable/)
tratta il vincolo e la disciplina dei nomi che mantiene leggibile una catena del genere.

> **Perché il passaggio indiretto vale la pena.** Il campo verdetto è la traccia che una persona
> con nome e cognome ha valutato questo account in questa data e ne ha tratto una conclusione. È
> verificabile, utilizzabile nei report e riesaminabile se l'account abbandona comunque: nulla di
> tutto ciò vale per il superamento di una soglia. Significa anche che un'integrazione in pausa fa
> peggiorare il *punteggio* senza generare una sola azione rivolta al cliente.

### La rete di sicurezza

Il livello 1 scatta solo quando la fascia *cambia*. Un account che è Poor da quattro mesi non lo
fa più scattare, ed è proprio l'account che più di tutti va guardato. Il pattern ha quindi bisogno
di un terzo elemento: una **verifica pianificata** che trovi gli account prossimi al rinnovo la
cui fascia non è Good, o il cui campo verdetto non è stato toccato da novanta giorni, e crei
un'attività di revisione. L'automazione attivata dalle modifiche coglie il deterioramento;
l'automazione pianificata coglie la trascuratezza. Servono entrambe, e falliscono in modi diversi.

### Il ricalcolo, e che cosa significa per le tempistiche

Il punteggio non è in tempo reale. Una configurazione registra `lastRecalculation` e una
percentuale `calculationProgress`, e il ricalcolo può essere avviato per un record o per tutti i
record. La catena causale è quindi:

`field changes` → `recalculation runs` → `score and band change` → `process fires`

Ogni ipotesi sulle tempistiche va costruita sulla seconda freccia, non sulla prima. Nello spazio
in produzione la configurazione attivata era stata ricalcolata la mattina stessa in cui è stata
letta.

## 06 · Limiti e compromessi

> **Il punteggio non sa spiegarsi da solo, a meno che non glielo si faccia fare.** Ogni regola
> indicatore ha un campo `description`, e nella configurazione esaminata **ogni descrizione di
> ogni regola in tutte e quindici le configurazioni era vuota**. L'apparato per rispondere a
> «perché questo account è Poor?» è incluso nel prodotto e resta vuoto per impostazione
> predefinita, per cui alla risposta si arriva solo aprendo la configurazione e risolvendo a mano
> gli identificativi dei campi. La compili mentre scrive ogni regola; nulla glielo ricorderà mai.

- **Il punteggio viene ricalcolato, non è in tempo reale.** L'automazione scatta al ricalcolo,
  quindi «subito quando l'utilizzo cala» non è disponibile, e un'interpretazione in giornata di un
  cambiamento di fascia vale quanto la cadenza del ricalcolo.
- **Un indicatore su un campo replicato trasforma un'interruzione in un segnale di abbandono.**
  Dove un indicatore legge un campo di proprietà di un altro sistema, una data di sincronizzazione
  della telemetria, uno stato dell'abbonamento, un'integrazione bloccata fa peggiorare
  quell'indicatore su tutti gli account contemporaneamente, e il motore non può distinguere «il
  cliente ha smesso di usarlo» da «il canale ha smesso di consegnare». Questa è una conseguenza
  ragionata di due fatti verificati, non un incidente osservato: gli indicatori attivi leggono
  effettivamente campi data replicati, e il [Blueprint
  009](https://blueprints.coevera.com/it/blueprints/automating-on-integration-owned-fields/)
  documenta che cosa ha provocato in produzione un'interruzione della replica durata più giorni.
  La mitigazione è la stessa che prescrive quel blueprint, un controllo sulla freschezza della
  sincronizzazione indipendente dai dati sincronizzati, più la regola del §5 per cui un punteggio
  non fa mai scattare da solo un contatto con il cliente.
- **La categoria di salute è scrivibile.** Utile, perché una persona può correggere una fascia che
  il motore ha sbagliato, e pericoloso, perché una fascia impostata a mano è indistinguibile da
  una calcolata, e il ricalcolo successivo può sovrascriverla. Se le correzioni contano, le
  registri in un campo dedicato.
- **La configurazione si moltiplica per sottotipo.** Quindici tipi di account hanno significato
  quindici configurazioni, ciascuna con le proprie fasce e regole, tutte disattivate tranne una.
  Aggiungere un indicatore al «modello di salute del cliente» significa modificare quella attivata
  e ricordare che le altre sono divergenti: nello spazio in produzione le configurazioni ponderate
  e quelle per priorità hanno già le fasce a soglie diverse. Non esiste ereditarietà.
- **Una regola booleana non ha operatore, e il significato sta nel valore.** Una condizione su una
  casella di controllo memorizza `operator: null` con un valore di `"1"` per vero o `"0"` per
  falso. Quindi un indicatore critico che legge un flag di invio al recupero crediti è `null` più
  `"1"`: «questa casella è spuntata». È la normale codifica della piattaforma e non una regola
  rotta, e significa che **un operatore null non può essere letto da solo: il valore è l'intera
  condizione.** Qualsiasi verifica di una configurazione deve leggere entrambi, e un diff che
  mostra solo l'operatore non mostra nulla.
- **I punteggi non devono per forza raggiungere il limite della fascia.** Nella configurazione
  ponderata attiva i quattro indicatori totalizzano 95 contro un limite Good di 100, quindi un
  account perfetto ottiene 95. È innocuo, perché la fascia è un limite superiore e non un
  obiettivo, ma rende il punteggio grezzo una cosa poco adatta da mostrare a chiunque, e ancor
  meno adatta da confrontare tra sottotipi.
- **Gli indicatori da record correlati non sono dimostrati.** La configurazione ammette regole
  indicatore tratte da un'entità correlata tramite un lookup, e nello spazio esaminato questa
  possibilità non era usata: ogni regola attiva leggeva i campi dell'account stesso. Verificato
  nello schema, non nel comportamento. Dove serve «nessuna attività in 90 giorni», un campo rollup
  sull'account è la strada di cui è noto il funzionamento.
- **Solo Account è stato osservato con la salute.** La proprietà del tipo di entità ne ammette
  altri; ogni configurazione attiva era su Account. Non testato altrove.

### Il compromesso da dichiarare apertamente

Il motore offre cronologia, trend, stato per indicatore, attribuzione giornaliera e una fascia che
l'automazione può osservare: nulla che si costruirebbe correttamente a mano, e tutto ottenuto con
la sola configurazione. Ciò che non offre è una previsione. Non c'è alcun modello, nessuna
ponderazione suggerita, nessun apprendimento dagli account che hanno davvero abbandonato; le
regole e i punti sono la sua ipotesi sul perché i clienti se ne vanno, e il motore si limita ad
applicarli in modo coerente. È un buon accordo, a patto che l'ipotesi venga rivista quando è
sbagliata: è a questo che serve la cronologia, ed è il motivo per cui il §5 insiste che sia il
verdetto di una persona, e non il punteggio, a entrare nel record come decisione.

## 07 · Verifica

Letto il 2026-09-10 da uno spazio in produzione: l'intero insieme delle configurazioni della
salute, i campi indicatore risolti e i processi che utilizzano il risultato.

- **Quindici configurazioni della salute su Account**, una per tipo di account, con esattamente
  una attivata e con un timestamp di ricalcolo della mattina stessa della lettura. Le altre
  quattordici erano configurate e disattivate.
- **Entrambe le modalità di calcolo sono state trovate in uso reale**: configurazioni ponderate
  con punti espliciti su ogni regola, configurazioni per priorità con zero su tutte, e hanno le
  fasce a soglie diverse, 35/75 contro 30/80.
- **Il meccanismo critico è stato confermato dai dati**: ogni regola critica in ogni
  configurazione ha `score: -1`, e ogni configurazione definisce una fascia Critical a `-1`.
  Stando a questi valori memorizzati, un solo indicatore critico domina il punteggio; non è stato
  osservato in un ricalcolo.
- **Ogni id di campo indicatore è stato risolto nel relativo campo**, ed è da lì che vengono le
  quattro dimensioni del §4: utilizzo, recenza della telemetria, record generati dal cliente,
  ticket di assistenza che invecchiano, più lo stato dell'account e un flag di recupero crediti
  come regole critiche. Un campo compare in entrambi gli insiemi con operatori opposti.
- **La salute come trigger è stata verificata, non presunta.** Un processo attivato in produzione
  scatta sull'aggiornamento di Account con un solo campo osservato, e quell'id di campo si risolve
  nella categoria di salute nativa. Un secondo processo in produzione osserva un solo campo radio
  personalizzato, il verdetto, e passa il testimone a tre sottoprocessi.
- **I 23 operatori e i quattro valori di trend** sono stati letti dallo schema, così come il
  punteggio, la fascia e lo stato per indicatore di ogni record, e la struttura della cronologia
  con la sua attribuzione per differenza di punteggio, regola e campo.
- **Ogni descrizione di regola era vuota** in tutte e quindici le configurazioni.
- **I valori delle regole sono stati letti insieme agli operatori**, ed è questo che stabilisce la
  codifica booleana del §4: l'unica regola senza operatore lo abbina a un valore di `"1"`. La
  stessa convenzione `operator: null` compare nei filtri dei processi con un valore di `"0"` per
  un test di falsità, quindi la codifica è coerente tra due sottosistemi indipendenti ed è il
  valore a distinguere i due significati.
- **La grammatica dei valori del periodo relativo è stata letta da regole attive**: un elenco in
  quattro parti con una modalità, una direzione, un'unità e un conteggio, che è la forma indicata
  nel §4.

**Non osservato, e dichiarato come tale:**

- Un ricalcolo in corso, o la cadenza con cui viene eseguito. Solo che era stato eseguito, e che
  esiste una percentuale di avanzamento.
- Indicatori tratti da un'entità correlata tramite un lookup: verificato nello schema, non nel
  comportamento.
- La salute su qualsiasi entità diversa da Account.
- Se una categoria di salute scritta a mano sopravviva al ricalcolo successivo.
- Un indicatore critico soddisfatto che porti il punteggio a `-1` durante un ricalcolo. Questo
  comportamento è dedotto dai punteggi memorizzati delle regole e dalla soglia della fascia
  Critical.
- L'ordine preciso di risoluzione nella modalità per priorità, al di là del fatto che conta
  l'ordine delle regole e i punti sono zero.

### Che cosa segnalerebbe una regressione

- **Molti account che cambiano fascia nello stesso giorno.** Il deterioramento reale non è
  sincronizzato. Uno spostamento su tutto il parco clienti significa che l'input di un indicatore
  si è rotto, il più delle volte un campo replicato, e sembrerà un'ondata di abbandoni.
- **Un timestamp di ricalcolo che smette di avanzare.** Il punteggio semplicemente si congela;
  nulla fallisce, e ogni fascia su ogni record diventa, senza che nessuno se ne accorga,
  un'affermazione sul passato.
- **Cambiamenti di fascia che scattano mentre i campi verdetto restano intatti.** Il livello 1
  funziona e il livello 2 no: le persone vengono avvisate e nessuno decide. È il modo di fallire
  che appare più sano dal lato dell'automazione.
- **Account fermi in Poor per mesi senza un'attività di revisione.** La verifica pianificata si è
  fermata, e l'automazione attivata dalle modifiche non li coglierà mai, perché la loro fascia non
  cambia.

## Blueprint correlati

- [Blueprint 009 — Come automatizza sui campi del CRM di proprietà di un altro
  sistema?](https://blueprints.coevera.com/it/blueprints/automating-on-integration-owned-fields/)
  — lettura essenziale se un indicatore legge un campo replicato.
- [Blueprint 008 — Come prevede rinnovi che non esistono ancora come
  record?](https://blueprints.coevera.com/it/blueprints/forecasting-renewals-before-they-exist/) —
  il lato dei ricavi dello stesso rinnovo; la salute ne è il lato del rischio.
- [Blueprint 011 — Come mantiene gestibili centinaia di automazioni del
  CRM?](https://blueprints.coevera.com/it/blueprints/keeping-hundreds-of-automations-maintainable/)
  — perché un verdetto si dirama in diversi processi.
- [Blueprint 012 — Come gestisce un sondaggio clienti dal suo CRM e riporta le risposte sul
  record?](https://blueprints.coevera.com/it/blueprints/customer-survey-answers-onto-the-record/)
  — come portare una domanda con risposta sul record, dove una regola di salute può leggerla.
- [Blueprint 003 — Come modella qualcosa per cui il suo CRM non ha un
  oggetto?](https://blueprints.coevera.com/it/blueprints/where-should-this-data-live/) — scegliere
  tra un segnale costante e un record di valutazione verificabile.

## Domande frequenti

### Come individua i clienti a rischio di abbandono prima del rinnovo?

Usi il motore nativo di salute delle entità anziché un campo punteggio mantenuto a mano. La salute si configura per sottotipo di record: un insieme di regole indicatore, ciascuna con un campo, un operatore e un punteggio, si traduce in un punteggio numerico, in una di quattro fasce e in un trend. Un insieme separato di indicatori critici è memorizzato con un punteggio di meno uno, e una fascia Critical è posta a meno uno, quindi un indicatore critico soddisfatto dovrebbe imporre la fascia peggiore indipendentemente da come hanno valutato le altre regole; lo si deduce da questi valori memorizzati, non è stato osservato in un ricalcolo. La fascia di salute dell'account cambia, e un processo può attivarsi su quel cambiamento.

### Un punteggio di salute in calo dovrebbe far scattare direttamente l'intervento sul cliente?

No. Un punteggio è un segnale probabilistico e un intervento è un impegno, quindi i due non vanno collegati direttamente. Faccia sì che il cambiamento di salute avvisi la persona responsabile della relazione, e che questa registri un verdetto in un campo dedicato. È il cambiamento del campo verdetto a far scattare la catena di contatti con il cliente. Così un problema di qualità dei dati o un'integrazione in pausa non generano azioni rivolte al cliente.

### Il punteggio di salute di un CRM viene calcolato in tempo reale?

No. Il punteggio viene ricalcolato, non è in tempo reale: la configurazione della salute registra un timestamp dell'ultimo ricalcolo e una percentuale di avanzamento del calcolo, e il ricalcolo può essere avviato per un singolo record o per tutti. Quindi un processo che si attiva su un cambiamento di salute scatta quando viene eseguito il ricalcolo, non nel momento in cui è cambiato il campo sottostante.

### Quali campi sono buoni indicatori della salute del cliente?

Segnali operativi generati dal cliente, non opinioni che qualcuno registra. Un insieme funzionante copre quattro aspetti: se il prodotto viene usato, se è ancora connesso, se l'assistenza è in difficoltà e se il rapporto commerciale è intatto, per esempio l'utilizzo delle licenze, la data dell'ultima sincronizzazione della telemetria, la data in cui il cliente ha creato l'ultimo record, un rollup dei ticket di assistenza più vecchi di due settimane, lo stato dell'account e un flag di invio al recupero crediti.

### Perché due account con lo stesso punteggio di salute possono trovarsi in fasce diverse?

Perché le fasce si configurano per sottotipo di record, e ogni sottotipo ha le proprie soglie. In uno spazio in produzione le configurazioni ponderate hanno le soglie a 35 e 75, mentre quelle basate sulla priorità le hanno a 30 e 80, quindi lo stesso punteggio risulta Poor con un sottotipo e Neutral con un altro. La configurazione della salute non è globale.

---

Pubblicato da Coevera. Ridotto allo schema riutilizzabile: nessun nome di cliente, nessun dato
dei clienti, nessun dato personale.