---
title: "Come prevede rinnovi che non esistono ancora come record?"
blueprint: 008
slug: forecasting-renewals-before-they-exist
category: Automazione
published: 2026-09-23
revised: 2026-09-23
platform: Coevera CRM (formerly Pipeliner CRM)
canonical: https://blueprints.coevera.com/it/blueprints/forecasting-renewals-before-they-exist/
language: it
translation_of: https://blueprints.coevera.com/blueprints/forecasting-renewals-before-they-exist/
author: Lucia Schmidt
publisher: Coevera
customer_data: none
---

# Come prevede rinnovi che non esistono ancora come record?

**Risposta breve.** **Separi i ricavi già impegnati dal processo di rinnovo.** I ricavi futuri di
un contratto pluriennale firmato sono già nel sistema — un **piano dei ricavi** sull'opportunità
esistente ne distribuisce il valore su periodi datati (mese, trimestre o anno), e ogni periodo è
un record con una data e un importo — secondo quanto letto dallo schema; la generazione dei
periodi non è stata osservata. Non servono record di trattative future. Il centro assistenza
limita Revenue Recognition al livello **Business & Enterprise**.

Se il cliente *rinnova* è una domanda di vendita, e richiede una vera opportunità. Una **regola di
ricorrenza dell'opportunità** le genera in modo nativo — con una cadenza `AfterNMonths` o
`AfterNYears` che corrisponde alla durata di un contratto anziché a una data del calendario.

## 01 · Il problema di business

Un'azienda vende con contratti pluriennali. Qualcuno chiede come si presentano i ricavi dell'anno
prossimo, e la risposta onesta richiede tre cose diverse che di solito vengono trattate come una
sola:

- **Ricavi già impegnati.** Un contratto triennale firmato lo scorso trimestre vincola il cliente
  per altri due anni. Quel denaro non è una previsione — è contrattualizzato, e non dovrebbe
  comparire in una pipeline di cose in vendita.
- **Ricavi che dipendono da una decisione.** Un contratto che scade a marzo può rinnovarsi o no,
  può rinnovarsi a un prezzo diverso, può rinnovarsi per un periodo più breve. Quella è davvero
  un'opportunità di vendita e appartiene a una pipeline.
- **Ricavi a rischio.** Un cliente che disdice a metà contratto elimina ricavi impegnati che erano
  già stati conteggiati.

Il requisito così come viene formulato — «prevedere rinnovi che non esistono ancora» — fonde tutti
e tre. Ottenere una risposta utile comincia dal separarli.

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

### Creare opportunità di rinnovo dormienti

> **Il problema è la dormienza, non l'anticipo.** Un'opportunità di rinnovo creata per una
> scadenza lontana due anni è un record fermo nella pipeline attiva che nessuno toccherà per venti
> mesi. Tasso di conversione, ciclo di vendita medio, invecchiamento per fase e previsione
> ponderata sono tutti calcolati su quella pipeline — la riempia di trattative su cui nessuno
> lavora e ognuno di quei numeri peggiora, non in modo visibile, ma costantemente.
>
> **Ma l'anticipo va bene se qualcosa lo guida.** Un'implementazione in produzione che abbiamo
> esaminato crea l'opportunità di rinnovo al traguardo dei **365 giorni** e poi esegue su di essa
> un conto alla rovescia a tappe: un'attività di revisione trimestrale con il cliente a 180
> giorni, un invito alla revisione rivolto al cliente a 90, una verifica di salute e valore a 60,
> poi notifiche interne e al cliente sempre più pressanti a 45, 30, 18 e 15. Il record non è mai
> dormiente, perché il conto alla rovescia dà a qualcuno qualcosa da fare fin dal giorno in cui
> compare.
>
> La regola che ne deriva: **crei l'opportunità con un solo periodo contrattuale di anticipo, mai
> con più periodi — e solo insieme a una cadenza che agisca su di essa.** Un'opportunità di
> rinnovo senza un conto alla rovescia alle spalle inquina la pipeline, a prescindere da quanto
> sia lontana.

### Mettere l'intero valore del contratto sulla data di chiusura

Un contratto triennale registrato come un unico valore su un'unica data di chiusura dice che
l'azienda ha guadagnato tutto in un solo mese. Qualsiasi vista per periodo — ricavi mensili,
run-rate trimestrale, ARR — risulta allora sbagliata per l'intera durata, in entrambe le
direzioni: sovrastimata nel mese di chiusura, sottostimata in ogni mese successivo.

### Fare reportistica sulle «opportunità in chiusura l'anno prossimo»

È il report istintivo, e risponde alla domanda sbagliata. Mostra le trattative che si prevede
*chiudano* l'anno prossimo, escludendo ogni contratto già vinto che genererà ancora ricavi l'anno
prossimo. Di solito quello è il numero più grande, e manca del tutto.

### Costruire tutto con l'automazione

Comprensibile, e per lo più superfluo — entrambe le metà hanno meccanismi nativi. Vale la pena
verificarlo prima di costruire, per lo stesso motivo del [Blueprint
006](https://blueprints.coevera.com/it/blueprints/document-numbering-that-survives-production/),
dove l'espediente di automazione comunemente raccomandato duplica qualcosa che esiste già come
pulsante di opzione.

## 03 · Due meccanismi, due domande

Un'opportunità in Coevera contiene entrambi, e sono due cose del tutto separate.

### Piano dei ricavi — che cosa è già impegnato

Un piano associato all'opportunità, che contiene:

| Proprietà | Significato |
|---|---|
| `startDate` | Quando iniziano i ricavi — non la data di chiusura. |
| `periodCount` | Su quanti periodi si distribuisce il valore. |
| `periodType` | **Month, Quarter o Year.** Esattamente questi tre. |
| `cancelationDate` | La fine anticipata del contratto. È qui che si esprime l'abbandono. |
| `periods` | I record di periodo generati. |

Ogni periodo è un record a sé con una **data** e un **valore**. È questa la struttura che rende
possibile la reportistica per periodo: i ricavi di un qualsiasi mese sono la somma delle righe di
periodo datate in quel mese, su tutti i contratti, indipendentemente da quando quei contratti sono
stati chiusi.

### Ricorrenza — generare la trattativa successiva

Una regola separata, anch'essa sull'opportunità, che produce record di opportunità futuri:

| Proprietà | Significato |
|---|---|
| `startDate` / `endDate` | La finestra in cui vengono generate le occorrenze. |
| `stepId` | **Obbligatorio** — la fase della pipeline in cui arrivano le opportunità generate. |
| `occurEvery` / `occurrencesCount` | L'intervallo, e quante occorrenze produrre. |
| `type` | La cadenza — veda sotto. |
| `day` · `dayOfWeek` · `week` · `month` | Posizionamento nel calendario, usato dai tipi assoluti e relativi. |

Le cadenze disponibili si dividono in tre famiglie:

- **Semplici** — giornaliera, settimanale.
- **Assolute e relative** — mensile o annuale, in un giorno fisso del calendario («il 15») oppure
  in modo relativo («l'ultimo venerdì»).
- **Dopo N** — dopo N giorni, settimane, mesi o anni. **È questa la famiglia dei rinnovi**, perché
  un rinnovo scade a un periodo contrattuale di distanza dal precedente anziché in una data fissa
  del calendario.

**Fonti.** Centro assistenza di Coevera, [Using opportunity
recurrence](https://help.coevera.com/en/articles/4190616-using-opportunity-recurrence) e [Using
opportunity revenue
recognition](https://help.coevera.com/en/articles/4293948-using-opportunity-revenue-recognition) —
i due meccanismi, documentati separatamente, che è la distinzione su cui si basa questo blueprint.

> **La decisione di progettazione che ne deriva.** Imposti la finestra di ricorrenza in modo che
> l'opportunità successiva compaia quando qualcuno ci lavorerà davvero — un trimestre prima della
> scadenza, non tre anni — e lasci che nel frattempo sia il piano dei ricavi a portare i ricavi
> già impegnati. Così la pipeline resta onesta e la vista dei ricavi resta completa allo stesso
> tempo, ed è a questo che serve la separazione in due meccanismi.

### Distinguere il rinnovo dal nuovo business

Di solito i rinnovi devono essere riportati separatamente dal nuovo business, il che significa un
tipo di opportunità. Un fatto strutturale di cui tenere conto: **i tipi di opportunità
corrispondono uno a uno alle pipeline.** Uno spazio con New Business, Expansion e Renewal come
tipi ha quindi tre pipeline — che spesso è comunque ciò che si vuole, poiché un rinnovo attraversa
fasi diverse da una nuova vendita, ma non è una scelta libera.

## 04 · Che cosa deve aggiungere da sé

La meccanica è nativa; il vocabolario commerciale dei rinnovi no. Questi sono campi personalizzati
in ogni implementazione che abbiamo visto:

| Campo | Perché serve |
|---|---|
| Durata del contratto | La ricorrenza conosce il proprio intervallo; il record non indica la durata contrattuale. |
| Data di rinnovo | Distinta dalla data di chiusura, che è quando si chiude la *trattativa* di rinnovo. |
| Aumento consentito | Un tetto contrattuale all'aumento — serve prima della conversazione, non dopo. |
| Requisiti di fatturazione e di ordine d'acquisto | Se questo cliente ha bisogno di un ordine d'acquisto prima della fatturazione. Di solito un valore predefinito dell'account, modificabile per singolo rinnovo. |
| Indicatore di rischio di abbandono | Alimenta il recupero del cliente, e si abbina alla data di cancellazione a posteriori. |

Lo schema con valore predefinito sull'account e modifica per singolo rinnovo della quarta riga
merita di essere definito presto. È una domanda su dove risiedono i dati, e rispondervi tardi
significa doverli spostare.

## 05 · Gestire il conto alla rovescia

Non esiste una notifica nativa «il rinnovo si avvicina». Il meccanismo che un'implementazione in
produzione usa per questo merita di essere copiato, perché è più semplice di quanto sembri.

### Un solo campo per il conto alla rovescia, molti osservatori

Mantenga un unico valore **"expires in days"** sull'account, e lasci che ogni fase del conto alla
rovescia si attivi sulle *modifiche di quell'unico campo* anziché eseguire ciascuna il proprio
calcolo sulle date. Un solo numero scende; l'azione a 180 giorni, quella a 90 giorni e quella a 60
giorni lo osservano tutte in modo indipendente.

L'alternativa — ogni processo che calcola da sé «la data di rinnovo è entro N giorni?» —
moltiplica la stessa logica sulle date in una dozzina di punti, e questi finiscono per divergere.

### Renda idempotente il creatore con un flag

> **Un job pianificato giornaliero che crea record deve poter essere eseguito ogni giorno senza
> rischi.** Lo schema: filtrare sul conto alla rovescia che supera la soglia *e* su un flag
> «rinnovo già creato» non impostato; creare l'opportunità; impostare il flag.
>
> Stessa forma della protezione a esecuzione singola del [Blueprint
> 001](https://blueprints.coevera.com/it/blueprints/one-entity-five-request-types/) — la
> condizione rende la scrittura idempotente, quindi non serve una contabilità separata del tipo «è
> già stato eseguito?». Senza di essa un job giornaliero produce una nuova opportunità di rinnovo
> ogni mattina per un anno.

### Escluda i contratti pluriennali dal conto alla rovescia annuale

Un contratto triennale non dovrebbe generare attività di rinnovo alla fine del primo e del secondo
anno. L'implementazione in produzione gestisce questo caso con un **flag pluriennale** esplicito
che, combinato con un **flag di gestione manuale**, sopprime il conto alla rovescia standard e
indirizza quegli account su un percorso separato con una data di rinnovo speciale.

Conviene prevederlo fin dall'inizio. Aggiungerlo a posteriori significa prima trovare ogni account
a metà contratto che ha ricevuto email di rinnovo che non avrebbe dovuto ricevere.

### Chiuda deliberatamente il periodo contrattuale

Quando un abbonamento termina davvero, qualcosa deve registrarlo. Un job pianificato eseguito il
giorno *dopo* la data di fine imposta la data di perdita, registra l'ultimo utilizzo e svuota i
campi di rinnovo rivolti al futuro. Senza di esso, gli abbonamenti terminati continuano a
comparire nella reportistica dei rinnovi come se fossero ancora in sospeso.

### Due note sulla forma

Un processo pianificato che filtra su una data richiede un confronto su un periodo relativo
anziché un valore fisso. E un processo il cui primo nodo è un'azione anziché un filtro viene
salvato correttamente e mostra un'area di lavoro vuota — la forma è trigger, poi filtro, poi
azioni, come descritto nel [Blueprint
002](https://blueprints.coevera.com/it/blueprints/ai-fields-read-documents/).

Se l'opportunità di rinnovo deve ereditare qualcosa da quella in scadenza — voci di riga, la
relazione con l'account, i valori dei campi personalizzati — anche questo è automazione. Una
regola di ricorrenza genera un record in una fase; non è un meccanismo di copia del contratto.

## 06 · Limiti e compromessi

### I tipi di periodo sono mese, trimestre o anno — nient'altro

Un piano si distribuisce su uno di questi tre. Una fatturazione irregolare — pagamenti a
milestone, un avvio graduale non uniforme, un acconto seguito da rate — non può essere espressa
come piano nativo. Quel caso richiede più opportunità oppure un'entità figlia che contenga il
piano dei pagamenti, con i prezzi gestiti come nel [Blueprint
007](https://blueprints.coevera.com/it/blueprints/pricing-one-product-many-prices/).

### Un solo piano per opportunità, nella modalità basata sul valore dell'opportunità

Quando Revenue Recognition opera sul valore dell'opportunità, il piano è un singolo allegato, non
una raccolta. Una trattativa che combina, per esempio, una licenza annuale e un servizio mensile
ha due cadenze e in quella modalità deve essere suddivisa in due opportunità — una decisione di
modellazione da prendere deliberatamente anziché doverla scoprire all'arrivo del primo contratto
di questo tipo.

L'articolo del centro assistenza citato in §3 descrive anche una modalità **Product Line**, in cui
Revenue Recognition si imposta su ogni voce di prodotto singolarmente; con una configurazione
mensile, ogni voce può avere il proprio periodo Month, Quarter o Year. Questa modalità è
l'alternativa documentata alla suddivisione; qui non è stata verificata.

### L'opportunità generata arriva in una fase fissa

La regola di ricorrenza richiede una fase di destinazione, quindi ogni occorrenza generata compare
nella stessa posizione della pipeline. Se i rinnovi devono entrare in fasi diverse a seconda del
rischio o della dimensione, quell'instradamento è un'automazione successiva, non parte della
regola.

### I campi memorizzati per anno di rinnovo diventano manutenzione annuale

> **Una trappola visibile solo in un'implementazione in funzione da anni.** Se memorizza «il
> rinnovo di quest'anno», «il rinnovo dell'anno scorso» e «il rinnovo dell'anno prossimo» come
> campi sull'account — perché la reportistica li vuole affiancati — si è impegnato in
> un'**operazione annuale di riallineamento**.
>
> L'implementazione in produzione che abbiamo esaminato esegue una catena di **quattro processi
> una volta per anno solare** per spostare precedente ← corrente, corrente ← successivo, e il
> successivo avanti di dodici mesi, con rami separati per i contratti pluriennali, e poi ricalcola
> le date di perdita. Viene eseguita manualmente, dalla persona che si ricorda che esiste.
>
> Calcoli questi valori dalla data di rinnovo al momento della lettura ovunque il livello di
> reportistica lo consenta. Li memorizzi solo dove è indispensabile, e in quel caso metta per
> iscritto che il passaggio d'anno esiste — è esattamente il tipo di attività annuale che viene
> dimenticata l'anno in cui la persona che se ne occupava cambia ruolo.

### Verificato sullo schema, non sul comportamento

> **Un limite dichiarato di questo blueprint.** L'orchestrazione del §5 e i compromessi sopra
> descritti provengono da un'implementazione in produzione da anni. La metà relativa all'*entità
> nativa* è più debole: le forme, i nomi delle proprietà, i tipi di periodo e le cadenze di
> ricorrenza sono stati letti direttamente dallo schema di uno spazio in produzione e sono
> accurati, ma **non abbiamo** creato un piano dei ricavi osservando la generazione dei periodi,
> né abbiamo eseguito una ricorrenza fino al completamento.
>
> Due comportamenti in particolare restano non osservati: come reagiscono esattamente i record di
> periodo quando viene impostata una data di cancellazione a metà contratto, e se la generazione
> delle ricorrenze è influenzata dal fatto che l'opportunità di origine sia vinta, persa o
> archiviata. Entrambi contano per la reportistica. Li verifichi in una sandbox prima di
> costruirvi sopra una previsione — e tenga presente che l'endpoint del piano dei ricavi non ha un
> proprio riferimento all'opportunità, quindi l'associazione si crea dal lato dell'opportunità.

### Il piano non può essere associato tramite REST

> **Tentato senza successo, così lei non deve farlo.** L'endpoint del piano dei ricavi non ha un
> proprio riferimento all'opportunità, e una creazione inviata con tale riferimento viene
> rifiutata. Associarlo dalla direzione opposta — aggiornando l'opportunità con un payload del
> piano — **restituisce un successo e non crea nulla.** Una lettura successiva non mostra alcun
> piano nello spazio.
>
> È la modalità di errore dominante dell'API di questa piattaforma, documentata in tutta questa
> raccolta: la scrittura viene accettata, non viene sollevato alcun errore e non succede nulla.
> Presuma che i piani debbano essere creati tramite l'interfaccia o l'API di amministrazione
> finché non sia dimostrato il contrario, e **rilegga sempre** dopo aver tentato di crearne uno.

### Una particolarità di scrittura da conoscere

Il valore dell'opportunità viene riletto come un composto di valore base, valore in valuta estera
e valuta — ma viene **scritto come un semplice numero**. Fornire la forma composta in fase di
creazione è stato accettato e ha prodotto silenziosamente un valore pari a zero; lo stesso campo
impostato come scalare ha funzionato. Se la sua previsione dipende dal corretto arrivo dei valori
delle trattative tramite un'integrazione, li controlli dopo la scrittura.

## 07 · Verifica

- **Riconcili il piano con la trattativa.** La somma dei valori dei periodi deve essere uguale al
  valore del contratto. Se non lo è, il piano e il valore principale raccontano storie diverse e i
  report saranno in disaccordo tra loro.
- **Confronti una vista dei ricavi per periodo con una vista per data di chiusura** e verifichi
  che differiscano nel modo che si aspetta. Se coincidono, probabilmente il piano non viene usato.
- **Imposti una data di cancellazione su un piano di test** e osservi che cosa accade ai periodi
  successivi a quella data, prima di fidarsi della reportistica sull'abbandono.
- **Lasci che una ricorrenza generi almeno due occorrenze** e ne controlli le date rispetto alla
  durata prevista — in particolare con una cadenza dopo N, dove un intervallo sfasato di uno è
  facile da configurare e difficile da notare.
- **Conti i record della pipeline attiva prima e dopo** aver attivato la ricorrenza. Se il
  conteggio aumenta di più dell'occorrenza successiva, la finestra è troppo ampia e le metriche
  della pipeline stanno per falsarsi.
- **Verifichi i valori delle trattative dopo ogni scrittura da un'integrazione**, visto il
  comportamento composto-contro-scalare descritto sopra.

**Che cosa segnalerebbe una regressione:** valori dei periodi la cui somma non corrisponde più al
valore del contratto; opportunità di rinnovo che compaiono più in là della finestra prevista; un
contratto cancellato che contribuisce ancora ai ricavi di periodi futuri; oppure un numero
crescente di opportunità ferme nella pipeline attiva, che è il sintomo del ritorno del problema
descritto nel §2.

## Blueprint correlati

- [Blueprint 014 — Come individua i clienti a rischio di abbandono prima del
  rinnovo?](https://blueprints.coevera.com/it/blueprints/customer-health-score-churn-risk/) — il
  segnale di rischio di abbandono di cui, secondo questo blueprint, un rinnovo ha bisogno,
  costruito a partire dal punteggio di salute nativo.
- [Blueprint 007 — Come fissa prezzi diversi per lo stesso prodotto per regione, segmento o
  contratto?](https://blueprints.coevera.com/it/blueprints/pricing-one-product-many-prices/) — da
  dove provengono il prezzo di un rinnovo e il suo aumento consentito.
- [Blueprint 010 — Come consegna un'opportunità vinta al team che la
  realizza?](https://blueprints.coevera.com/it/blueprints/handover-from-sales-to-delivery/) — una
  seconda pipeline per il lavoro che segue una trattativa vinta — lo stesso vincolo di un tipo per
  una pipeline.

## Domande frequenti

### Come si prevedono in un CRM i ricavi ricorrenti o da rinnovo prima che il rinnovo esista come trattativa?

Separando due domande che di solito vengono confuse. Quali ricavi un contratto pluriennale firmato impegna già lo dice un piano dei ricavi associato all'opportunità esistente: una data di inizio, un numero di periodi, un tipo di periodo mensile, trimestrale o annuale, e un insieme di record di periodo generati, ciascuno con una data e un valore — una struttura letta dallo schema; la generazione dei periodi non è stata osservata. Quei ricavi sono già nel sistema e non richiedono record di trattative future. Secondo il centro assistenza, Revenue Recognition è disponibile nel livello Business & Enterprise. Se il cliente rinnoverà davvero è una domanda di vendita separata, a cui si risponde generando un'opportunità futura — cosa che una regola di ricorrenza sull'opportunità originale può fare automaticamente.

### Un CRM può creare automaticamente la successiva opportunità di rinnovo?

In Coevera sì, in modo nativo. Un'opportunità può avere una regola di ricorrenza con una data di inizio, una data di fine facoltativa, una fase di pipeline di destinazione, il numero di occorrenze da generare e un tipo di ricorrenza. I tipi disponibili comprendono giornaliera e settimanale, mensile e annuale sia in forma assoluta (un giorno fisso del calendario) sia in forma relativa (per esempio l'ultimo venerdì), e dopo N giorni, settimane, mesi o anni — quest'ultima famiglia è quella che corrisponde alla durata di un contratto, poiché un rinnovo scade N mesi dopo il precedente anziché in una data fissa del calendario.

### Perché creare opportunità di rinnovo con anni di anticipo è una cattiva idea?

Perché inserisce nella pipeline attiva trattative su cui nessuno sta lavorando. Tassi di conversione, ciclo di vendita medio, invecchiamento per fase e previsione ponderata peggiorano tutti, perché la pipeline contiene ora record che resteranno fermi per un anno o più. Rende inoltre fittizie le date di chiusura, poiché una data di rinnovo lontana anni è un'ipotesi. La separazione migliore è lasciare che il piano dei ricavi porti i ricavi futuri già impegnati, e generare l'opportunità di rinnovo solo quando la scadenza è abbastanza vicina perché qualcuno ci lavori davvero.

### Come si rappresenta in un piano dei ricavi l'abbandono o la disdetta a metà contratto?

Il piano dei ricavi contiene una data di cancellazione accanto alla data di inizio e al numero di periodi. È quello il campo che esprime la fine anticipata di un contratto, anziché eliminare periodi o modificare il valore originale della trattativa. Tenga presente che il modo esatto in cui i record di periodo reagiscono all'impostazione di una data di cancellazione è un comportamento che abbiamo documentato a partire dallo schema ma non osservato in uno spazio in produzione, quindi lo verifichi prima di basarvi la reportistica.

---

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