La 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.
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.
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, dove l'espediente di automazione comunemente raccomandato duplica qualcosa che esiste già come pulsante di opzione.
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 e 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.
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.
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 — 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.
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.
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.
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.
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.
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.