Come consegna un'opportunità vinta al team che la realizza?

01Il problema di business

Una trattativa si chiude. Ora qualcosa deve essere costruito, configurato, migrato o insegnato prima che il cliente tragga un qualsiasi valore da ciò che ha acquistato, e le persone che se ne occupano non sono quelle che l'hanno venduto.

È nel passaggio di consegne che di solito tutto questo risiede:

• Una conversazione, o un messaggio in un canale, e un foglio di calcolo che il team di delivery tiene per conto proprio.
• Quello che il venditore ha scritto per caso nelle note della trattativa, che non è mai ciò che il team di delivery ha bisogno di sapere.
• Una data di inizio su cui nessuno concorda, perché "vinta" e "pronta per iniziare" sono eventi diversi separati da una fattura.

Le conseguenze sono prevedibili e costose. Nessuno sa dire quanti clienti sono a metà implementazione in questo momento, né quali sono in ritardo, perché la risposta sta in un foglio di calcolo. L'assistenza scopre che un cliente è andato in produzione quando quel cliente apre il suo primo ticket. E la reportistica del team di vendita si degrada in silenzio, perché le trattative che ha chiuso restano nella sua pipeline per mesi.

02Perché l'approccio ovvio non funziona

Aggiungere fasi di delivery alla pipeline di vendita

È il primo istinto ed è quello costoso. La pipeline ha già delle fasi, il record della trattativa esiste già, quindi le fasi della delivery vengono accodate: Vinta → Configurazione → Formazione → Consegnata.

Corrompe ogni metrica della pipeline contemporaneamente, perché una pipeline misura un solo ciclo di vita e ora ne porta due:

• Il ciclo di vendita diventa tempo di vendita più tempo di delivery. Una trattativa chiusa a marzo e in produzione a luglio riporta un ciclo di quattro mesi su cui nessun venditore ha influito.
• Il tasso di conversione smette di significare qualcosa, perché i record escono dalla pipeline per ragioni di delivery, non di vendita.
• La previsione ponderata conteggia ricavi già acquisiti come se fossero ancora da conquistare.
• L'invecchiamento per fase, il report che chiunque usa per trovare le trattative bloccate, si riempie di record che non sono bloccati, ma semplicemente in fase di delivery.

Impone inoltre un unico insieme di campi e un unico responsabile a due team. Il venditore si tiene un record su cui non agisce più; il team di delivery eredita un modulo pieno di campi su concorrenti e approvazione degli sconti.

Monitorarla invece sull'account

Istinto migliore, forma ancora sbagliata. L'account è il cliente, e un cliente può acquistare più di una volta: un secondo progetto, un upsell che richiede una propria configurazione. Lo stato della delivery sull'account può descrivere un solo incarico, quindi il secondo sovrascrive il primo e la cronologia va persa.

Un elenco di attività

Le attività sono lo strumento giusto per i passaggi e quello sbagliato per un ciclo di vita. Una checklist di dieci attività non può dirle in quale fase si trovi un progetto, non può essere rappresentata come un funnel nei report e non ha alcuna nozione di un progetto in ritardo, a differenza di un'attività in ritardo.

03Modello dati: due pipeline, una relazione

La delivery riceve una propria pipeline, con fasi proprie, un responsabile proprio e un insieme di campi proprio. L'opportunità di vendita vinta vi viene clonata.

In Coevera un tipo di opportunità corrisponde uno a uno a una pipeline, quindi una seconda pipeline significa necessariamente un secondo tipo, il che qui è comodo, perché è esattamente la separazione che si desidera: un record di delivery è una cosa di natura diversa da un record di vendita, con un modulo diverso.

Fonte. Centro assistenza Coevera, Adding another pipeline.

Le fasi descrivono la delivery, non la vendita

L'implementazione in produzione da cui è tratto questo schema ne usa quattro, e la struttura è generalizzabile:

Noti la prima fase. Vinta e pronta per iniziare sono eventi diversi, di solito separati da una fattura, e dare a quell'intervallo una fase propria è ciò che impedisce alla coda del team di delivery di riempirsi di lavoro che non può ancora cominciare.

Cloni in modo condizionato

Non tutte le trattative vinte richiedono una delivery. Il clone scatta solo quando la trattativa contiene un vero elemento da realizzare: una configurazione, una formazione, una migrazione di dati, un pacchetto di ore di consulenza. Un semplice rinnovo di licenza non produce alcun record di delivery e non compare mai nella coda di quel team.

Questa sola condizione fa la differenza tra una pipeline di delivery di cui il team si fida e una che ignora perché è piena di cose che non sono lavoro suo.

Alternative scartate

• Un'entità personalizzata per il progetto anziché un secondo tipo di opportunità. Difendibile, ma le costa la pipeline: fasi, vista a funnel, invecchiamento per fase e reportistica in stile previsione sono tutte incluse con un'opportunità e vanno ricostruite su un'entità personalizzata. La scelga solo se la delivery non ha davvero alcuna progressione per fasi: per questa decisione veda il Blueprint 003.
• Spostare il record da una pipeline all'altra invece di clonarlo. In tal caso la pipeline di vendita perde la trattativa che ha chiuso, e la reportistica storica delle vendite cambia retroattivamente ogni volta che qualcosa viene consegnato.
• Un solo record, due campi di stato: uno stato di vendita e uno stato di delivery sulla stessa opportunità. Ogni report, vista e processo deve allora sapere quale campo gli interessa, e la pipeline ne mostra comunque uno solo.

04Configurazione a livello di campo

Il record di delivery ha bisogno di un piccolo insieme di campi che al record di vendita non servono.

05Automazione e logica

Il clone, e un processo per ciascuna pipeline di origine

Il clone si attiva quando lo stato dell'opportunità di vendita diventa vinto, filtrando le trattative che contengono qualcosa da realizzare. Crea il record di delivery nella prima fase, copia i campi di base, applica le quantità predefinite per servizio e invia al cliente una conferma il cui testo varia in base a ciò che ha acquistato.

Le trattative possono arrivare da più di una pipeline di vendita, di solito nuovo business e upsell. Il parco di automazioni in produzione usa un processo gemello per ciascuna pipeline di origine anziché un unico processo con una condizione composta. Un po' più di manutenzione, e ne vale la pena: ciascuno è leggibile da solo, ciascuno può essere disattivato in modo indipendente e nessuno dei due sviluppa una condizione che nessuno può modificare in sicurezza.

Tratti il go-live come una diramazione, non come un unico processo

Quando un progetto va in produzione, devono accadere diverse cose non collegate tra loro. Scriverle come un unico processo produce qualcosa che fra un anno nessuno toccherà. Scriverle come quattro dà quattro elementi che si possono leggere, disattivare e rieseguire in modo indipendente:

Il terzo è quello che i team dimenticano, ed è il vero passaggio di consegne. La fine della delivery non è la fine della storia: chi risponde al primo ticket di assistenza di questo cliente deve sapere che cosa è stato implementato, e un avviso che riporta il perimetro è ciò che gli evita di partire da zero.

Il quarto scatta di proposito il giorno dopo anziché il giorno stesso. Il giorno del go-live è intenso, e un sollecito di follow-up è accolto meglio quando il cliente ha già usato il prodotto.

Differenzi la scadenza per tipo, non per convenzione

Lo stesso campo richiede un calcolo diverso per ogni tipo di incarico: per un progetto il conteggio parte dal go-live, per un pacchetto di ore di consulenza da quando è stato venduto, e il pacchetto scade che sia stato usato o no. Due diramazioni in un unico processo, guidate dal campo del tipo di implementazione, sono tutto ciò che serve, e impediscono che la scadenza sia qualcosa che le persone devono ricordarsi di impostare.

06Limiti e compromessi

Un clone è un'istantanea, e nulla riconcilia le copie

È il costo di questa architettura, e vale la pena pagarlo, ma va messo in conto. Al momento della clonazione i due record concordano. In seguito entrambi continuano a cambiare e nessun meccanismo della piattaforma li mantiene allineati.

L'implementazione in produzione esegue riallineamenti in entrambe le direzioni:

• Un processo pianificato giornaliero che compila il link al portale clienti sui record di delivery aperti a partire dall'account, per i record creati prima che l'account ne avesse uno.
• Un processo manuale che copia la data di go-live dall'account al progetto, per il caso in cui qualcuno l'abbia registrata prima sull'account.

Nessuno dei due è elegante. Entrambi sono necessari. Li scriva quando scrive il clone: l'alternativa è scriverli di corsa la prima volta che qualcuno chiede perché due record non concordano.

Il clone scatta sullo stato, e le righe di prodotto potrebbero non essere ancora collegate

Il trigger è la trattativa che diventa vinta; i valori predefiniti per servizio vengono letti da ciò che la trattativa contiene. Se lo stato cambia prima che le righe di prodotto siano sul record (un venditore ottimista, un'importazione, un'integrazione che scrive prima lo stato), la diramazione sul mix di servizi vede un elenco di prodotti vuoto e i valori predefiniti risultano silenziosamente sbagliati. Nessun errore, solo un record di delivery senza nulla di pianificato.

Rimedi, in ordine di preferenza: attivare il processo su un segnale successivo che implichi l'esistenza dei prodotti; oppure accettarlo e dare al team di delivery una vista dei record in cui le quantità sono tutte vuote, che è un filtro da cinque minuti e intercetta ogni caso.

Non esiste una conversione nativa in progetto

La piattaforma non ha un'operazione integrata del tipo "trasformare questa trattativa vinta in un record di delivery". Quanto descritto qui è assemblato a partire da un'automazione di creazione di un record collegato e da una mappatura dei campi che è lei a mantenere. Quando il modulo di vendita acquisisce un campo di cui il record di delivery ha bisogno, il clone deve esserne informato: nulla se ne accorge al posto suo.

La reportistica tra pipeline va assemblata

"Quanto tempo passa dalla trattativa vinta alla messa in produzione, per mix di servizi" abbraccia due insiemi di record, e nessuna delle due pipeline può rispondere da sola. È il prezzo diretto di metriche pulite per ciascuna pipeline: si ottengono una reportistica di vendita veritiera e una reportistica di delivery veritiera, e la domanda che le abbraccia entrambe costa un join. La copia della data di go-live sull'account esiste in parte per rendere la versione più comune di quella domanda risolvibile da un unico punto.

07Verifica

Tutto qui fallisce in silenzio, quindi le verifiche riguardano record che dovrebbero esistere e non esistono, anziché errori.

• Vinca una trattativa per ciascuna combinazione di servizi e verifichi che compaia un record di delivery con le quantità giuste. Che una combinazione funzioni non significa che la tabella delle diramazioni sia giusta; i valori predefiniti sono per mix e ogni mix è un percorso separato.
• Vinca una trattativa senza nulla da realizzare e verifichi che non venga creato nulla. Il clone condizionato riguarda altrettanto ciò che non fa.
• Cerchi i record di delivery con tutte le quantità vuote. È l'impronta del rischio di ordinamento descritto nel §6, e dovrebbe essere una vista salvata anziché un controllo occasionale.
• Imposti una data di go-live e controlli tutte e quattro le conseguenze: la copia sull'account, entrambe le scadenze derivate, l'avviso all'assistenza e l'attività di follow-up il giorno successivo. Poi cambi la data e verifichi che si aggiornino tutte. Di solito è la riattivazione dopo una modifica il punto in cui questo si rompe.
• Riconcili le due copie con una query: i record di delivery la cui data di go-live non concorda con quella del loro account. Non dovrebbe restituire nulla. Quando restituisce qualcosa, il riallineamento o non è stato eseguito o sta andando nella direzione sbagliata.
• Esegua i gemelli manuali su un record già corretto e verifichi che nulla cambi. Un processo rieseguibile che non è idempotente è uno strumento di riparazione peggiore di nessuno.

Che cosa segnalerebbe una regressione: una trattativa vinta con qualcosa da realizzare e nessun record di delivery; record di delivery la cui fase non si è mossa per più tempo di un'implementazione tipica, il che indica o un progetto bloccato o un processo che ha smesso di scattare; qualsiasi campo data in cui un gran numero di record condivide un unico valore, il che significa che qualcosa ha impresso "oggi" su un intero lotto.

Blueprint correlati

• Blueprint 003 — la domanda preliminare. È lì che si decide se la delivery meriti una pipeline, un'entità personalizzata o nulla del tutto.
• Blueprint 008 — lo stesso ragionamento sull'igiene della pipeline, applicato ai rinnovi: i record che restano in una pipeline per ragioni estranee alla vendita degradano ogni metrica che la pipeline produce.
• Blueprint 009 — perché una derivazione rieseguibile è lo strumento di ripristino, e che cosa succede all'automazione che imprime date quando scatta in ritardo.