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 vostro go-live, state debuggando l’infrastruttura di ricavo mentre le persone provano a venderci sopra.

Perché sbagliare costa di più nel 2026

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 avete 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 collegate 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.

Che il lavoro sia fatto non vuol dire che funzioni

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 vostro 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 possiate comprare prima di un CRM go-live, ed è il passo che si taglia quando la data di launch si stringe.

Cos’è davvero un dry run

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 state per lanciare, eseguita dalle persone che presidiano ogni parte, con lo sguardo preciso su ciò che si rompe.

Ciò che consiglio: bloccate due ore, mettete un record sullo schermo, e fatelo 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 state testando se i pezzi esistono. State 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 vedete solo quando un record percorre l’intero tragitto in un’unica seduta.

Uno schema visto sul campo

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 pagate due CRM per farne funzionare uno. Abbiamo intercettato entrambe le cose prima del launch perché abbiamo percorso il journey, non la checklist.

Il playbook del dry run

1. Prenotate 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. Trattatelo come un gate che il go-live deve superare, non come un nice-to-have.
2. Fate percorrere a un record reale tutto il tragitto, dal primo contatto al deal vinto. Scegliete uno scenario rappresentativo e seguitelo fino in fondo: creazione del lead, routing, qualificazione, ogni stage, la chiusura e il handoff dopo la chiusura. Non saltate alla parte interessante. È nelle transizioni noiose che si nascondono i vicoli ciechi.
3. Testate le giunture, non i pezzi. A ogni handoff, chiedetevi 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 vostro compito nel dry run sono le connessioni tra di essi.
4. Migrate lo storico, non solo i record aperti. Decidete 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 potete portare tutto, portatene abbastanza perché nessun rep abbia motivo di riaprire il vecchio CRM.
5. Standardizzate 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: cambiate 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. Scrivete la documentazione dalla versione funzionante. Registrate il dry run, poi costruite la guida utente dal flusso che avete 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. Mettete il dry run presto nella giornata e prenotate il tempo per le correzioni dopo. Date per scontato che il dry run troverà falle, perché le troverà, e che alcune richiederanno nuovi workflow. Fatelo 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 conoscete e non potete risolvere prima del launch.

Non complicate più del necessario

Non vi serve un programma formale per questo. Vi servono due ore, un record, le persone giuste nella stanza, e la disciplina di seguire tutto il journey invece delle parti di cui siete sicuri. 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 vi costa il go-live e un pezzo della vostra adoption.

Se state pianificando un CRM go-live e volete 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. Leggete l’articolo di accompagnamento su il gap di adoption del CRM che si apre dopo il launch, oppure vedete come affrontiamo le revenue operations end-to-end.

Fonti

• 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