CRM go-live: il dry run che trova ciò che il piano di progetto dimentica

La maggior parte delle migrazioni CRM viene gestita come una lista di attività. Mappare i dati, costruire i workflow, pianificare la formazione, scegliere una data di launch. La lista diventa verde, qualcuno dichiara il progetto concluso, e la mattina del go-live il team a contatto con i clienti accede a un sistema che nessuno ha davvero usato end-to-end. È quello il momento in cui le falle emergono, in produzione, con clienti reali nei record.

Il problema è che una lista di attività conferma che il lavoro è fatto. Non conferma che il flusso funziona. Un workflow può essere costruito e scattare comunque sul trigger sbagliato. Una property può essere mappata e finire comunque in una view che il rep non apre mai. Una pipeline può essere configurata e non avere comunque un percorso dalla stage in cui un lead entra alla stage in cui un deal si vince. Niente di tutto questo compare in uno status sheet. Compare la prima volta che un record reale prova a percorrere tutto il journey, e se quella prima volta è il suo go-live, sta debuggando l’infrastruttura di ricavo mentre le persone provano a venderci sopra.

Un tempo c’era margine nel sistema per assorbire un launch difficile. Qualcuno spegneva i workflow rotti per una settimana, l’admin correggeva dal vivo, e il team arrivava all’adoption alla meno peggio. Quel cuscinetto è quasi sparito. L’analisi GTM 2026 di SaaStr mostra che l’azienda mediana prevede una crescita di headcount RevOps pari a zero per cento quest’anno, con org GTM dal 20 al 30 per cento più snelle e molto più piatte di prima. Le persone che assorbivano un cutover andato male non esistono più nell’organigramma.

Anche dall’altra parte la posta è più alta. Non ha molti tentativi. Come scrive SaaStr nel suo articolo 2026 sul lock-in del CRM, la migrazione è di solito «troppo dolorosa da giustificare» una seconda volta, e man mano che collega agent e automazioni sopra il CRM, il passaggio va da fastidioso a «di fatto impossibile». Il CRM go-live è quasi una porta a senso unico. Il dry run è il modo per assicurarsi che si apra sulla stanza giusta.

Ecco la distinzione che inciderei in ogni piano di migrazione. Esistono due tipi di conferma, e i team raccolgono regolarmente il primo e saltano il secondo.

Il primo è la conferma delle attività: i dati sono mappati, i workflow costruiti, le view configurate, il deck di formazione scritto. È necessario ed è ciò che il suo piano di progetto traccia. Il secondo è la conferma del flusso: un record reale, che parte da dove partirebbe un cliente reale, arriva fino al deal vinto, e ogni stage, property, workflow e view che tocca lungo la strada fa ciò che deve. Quasi nessuno riserva tempo per il secondo. È l’assicurazione più economica che possa comprare prima di un CRM go-live, ed è il passo che si taglia quando la data di launch si stringe.

Un dry run non è una demo e non è uno UAT in una sandbox dove l’admin clicca sugli happy path. È una prova cronometrata ed end-to-end di tutto il customer journey nel sistema che sta per lanciare, eseguita dalle persone che presidiano ogni parte, con lo sguardo preciso su ciò che si rompe.

Ciò che consiglio: blocchi due ore, metta un record sullo schermo, e lo faccia percorrere dal primo contatto al deal vinto davanti a tutto il team. Entra un lead. Atterra nella pipeline giusta? Il workflow che dovrebbe scattare scatta davvero? Quando il rep apre il contact, vede la stessa view del collega, o ci sono cinque layout diversi così nessuno guarda gli stessi dati? Quando il deal cambia stage, viene creata l’azione successiva? Quando si vince, scatta il handoff verso onboarding o service? Non sta testando se i pezzi esistono. Sta testando se i pezzi si collegano.

Il motivo per farlo dal vivo, insieme e ad alta voce è che le falle vivono nelle giunture tra il lavoro delle diverse persone. Chi ha costruito il workflow di lead-routing e chi ha costruito le deal stage hanno testato ciascuno il proprio pezzo in isolamento, e ogni pezzo ha passato. Il journey attraversa entrambi, e la rottura è quasi sempre alla giuntura. La giuntura la vede solo quando un record percorre l’intero tragitto in un’unica seduta.

Di recente abbiamo lavorato con un’azienda B2B SaaS in Series B nella regione DACH che migrava da Salesforce a HubSpot, con una data di go-live fissa e un team a contatto con i clienti che non aveva mai toccato il nuovo setup. Il piano di progetto era in buona forma: mapping dei dati definito, workflow costruiti, formazione pianificata.

Dall’insistere su un dry run prima del cutover sono emerse due cose. Primo, facendo percorrere un record al journey, diversi workflow erano stati costruiti correttamente in isolamento ma non erano mai stati collegati al trigger che il vero customer journey produce, così un contact poteva entrare e restare lì, senza un passo successivo. Uno status sheet avrebbe mostrato quei workflow come «fatti». Il dry run li ha mostrati come vicoli ciechi. Secondo, il team non aveva previsto di migrare note e attività storiche dal vecchio sistema, solo i record aperti. Sembra ragionevole finché non ci si accorge che al primo giorno un rep prende in carico un account attivo, non vede storico, e apre di nascosto il vecchio CRM in un’altra scheda per ritrovarlo. Nel momento in cui le persone tengono aperto il sistema vecchio, l’adoption è già persa, e paga due CRM per farne funzionare uno. Abbiamo intercettato entrambe le cose prima del launch perché abbiamo percorso il journey, non la checklist.

1. Prenoti il dry run come evento a sé, prima del go-live. Due ore, tutto il team, a calendario come working session, non come status call. Se non è a calendario con un owner chiaro, verrà schiacciato dalla data di launch. Lo tratti come un gate che il go-live deve superare, non come un nice-to-have.
2. Faccia percorrere a un record reale tutto il tragitto, dal primo contatto al deal vinto. Scelga uno scenario rappresentativo e lo segua fino in fondo: creazione del lead, routing, qualificazione, ogni stage, la chiusura e il handoff dopo la chiusura. Non salti alla parte interessante. È nelle transizioni noiose che si nascondono i vicoli ciechi.
3. Testi le giunture, non i pezzi. A ogni handoff, si chieda se la cosa successiva scatta: il workflow, l’attività, la notifica, il cambio di view, l’assegnazione. I singoli oggetti sono già stati testati da chi li ha costruiti. Il suo compito nel dry run sono le connessioni tra di essi.
4. Migri lo storico, non solo i record aperti. Decida esplicitamente quale storico cliente passa: note, attività passata, contesto precedente. Se i rep non vedono cosa è successo prima del go-live, terranno aperto il vecchio sistema, ed è il modo più rapido per perdere l’adoption. Se non può portare tutto, ne porti abbastanza perché nessun rep abbia motivo di riaprire il vecchio CRM.
5. Standardizzi le view prima del launch, non dopo. Una view comune e adeguata al ruolo, così tutti vedono gli stessi dati quando condividono un record. La mia regola: cambi la view in base a dove si trova il record nel suo lifecycle, non in base a chi lo guarda. Un contact prima di diventare cliente dovrebbe avere un aspetto diverso da un contact che è cliente. Cinque layout personali al primo giorno significano cinque persone che si parlano addosso nella prima settimana.
6. Scriva la documentazione dalla versione funzionante. Registri il dry run, poi costruisca la guida utente dal flusso che ha appena confermato, con screen grab dei passi reali. Una documentazione scritta prima che il sistema sia confermato documenta un sistema che ancora non esiste.
7. Metta il dry run presto nella giornata e prenoti il tempo per le correzioni dopo. Dia per scontato che il dry run troverà falle, perché le troverà, e che alcune richiederanno nuovi workflow. Lo faccia di mattina, così chi deve correggere ha ancora il pomeriggio. Un dry run senza tempo per le correzioni prenotato dopo è solo una lista di problemi che ora conosce e non può risolvere prima del launch.

Non le serve un programma formale per questo. Le servono due ore, un record, le persone giuste nella stanza, e la disciplina di seguire tutto il journey invece delle parti di cui è sicuro. Il dry run è la differenza tra trovare le falle in una working session a calendario una settimana prima del launch e trovarle in produzione con un cliente in linea. Una è economica. L’altra le costa il go-live e un pezzo della sua adoption.

Se sta pianificando un CRM go-live e vuole un partner che esegua il dry run prima del cutover, è esattamente il tipo di lavoro che facciamo: definire lo scope della migrazione, collegare i workflow e provare tutto il customer journey prima che qualcuno debba venderci sopra. Legga l’articolo di accompagnamento su il gap di adoption del CRM che si apre dopo il launch, oppure veda come affrontiamo le revenue operations end-to-end.

• SaaStr. «The Modern GTM Org in 2026: Leaner, Flatter, and More Revenue Per Rep.» SaaStr, gennaio 2026. saastr.com
• SaaStr. «Which CRM Should You Use in 2026/2027? Follow the Agents.» SaaStr, febbraio 2026. saastr.com