Le guide all'implementazione crm sono quasi tutte scritte dal punto di vista di chi implementa: elenchi di cinque, sei o nove passi che descrivono le attività del fornitore. Un committente ha bisogno dell'informazione inversa: non che cosa succede in ogni fase, ma che cosa deve ricevere alla fine di ognuna e da quale segnale capisce che una fase è stata saltata.
Questo articolo assume la scelta della piattaforma come già fatta e guarda al progetto. Tre blocchi di lavoro, un deliverable per blocco, un criterio di accettazione per deliverable.
Key takeaways
- Il perimetro di un progetto CRM si decide prima del kickoff, e le condizioni da chiudere sono tre.
- Ogni fase produce un artefatto verificabile: se non esiste, la fase non è stata fatta.
- Migrazione dei dati e integrazioni sono le fasi che sforano, e sforano per la qualità del dato di partenza.
- Il go-live si dichiara chiuso sull'adozione, non sulla consegna.
Perché un'implementazione CRM si decide prima del kickoff
Il contesto europeo aiuta a inquadrare la partenza. Nel 2025 il 28,51% delle imprese dell'Unione usava un CRM, con un divario per dimensione molto ampio: 24,69% fra le piccole e 65,43% fra le grandi (Fonte). Molte implementazioni non partono quindi da zero: partono da un'organizzazione che ha già altri sistemi, spesso un ERP, presente nel 46,45% delle imprese europee.
Tre condizioni vanno chiuse prima che il progetto cominci. La prima è un obiettivo commerciale misurabile, formulato come cambiamento di un numero e non come funzionalità da avere. Il piano implementazione crm parte da lì. La seconda condizione è uno sponsor con potere di decisione sui processi, non solo sul budget: un progetto CRM modifica il modo in cui le persone lavorano, e chi non può cambiare un processo non può sponsorizzarlo. La terza è il perimetro dei processi inclusi, dichiarato per iscritto insieme a quelli esclusi.
Quando una di queste condizioni manca, il progetto la sostituisce con una decisione tecnica presa in corsa: è il motivo per cui, mesi dopo, il sistema riflette la configurazione predefinita del prodotto invece del modello commerciale dell'azienda.
Le tre fasi e il deliverable da pretendere in ognuna
| Fase | Domanda a cui risponde | Deliverable | Criterio di accettazione | Segnale che è stata saltata |
|---|---|---|---|---|
| Assessment | Com'è oggi il processo, e in che stato sono i dati | Mappa dei processi commerciali e referto sulla qualità dei dati | Chi esegue il processo si riconosce nella mappa | Si comincia a configurare senza aver mai intervistato chi vende |
| Blueprint | Come deve funzionare il sistema | Modello dati, pipeline, ciclo di vita del contatto, integrazioni, regole di governance | Un responsabile che non usa la piattaforma capisce il documento | La discussione si sposta subito su schermate e proprietà |
| Attivazione | Il sistema fa quello che il blueprint dichiara | Configurazione, migrazione, formazione per ruolo, verbale di collaudo | Il collaudo è firmato da chi userà il sistema, non da chi lo ha costruito | La formazione è una sola sessione uguale per tutti |
Il blueprint è un documento, non uno screenshot di configurazione
La distinzione sembra formale e non lo è. Un blueprint è un documento che descrive oggetti, proprietà, stati e regole in linguaggio di business, e che sopravvive al fornitore che lo ha scritto. Una raccolta di schermate della piattaforma già configurata documenta una decisione presa da qualcun altro, e nel momento in cui va cambiata nessuno sa più perché era stata presa così.
Il criterio di accettazione è pratico: il documento va dato da leggere a un responsabile commerciale che nella piattaforma non entra mai. Se capisce come si muove una trattativa dal primo contatto alla firma, il blueprint è fatto. Se ha bisogno che qualcuno glielo spieghi a voce, non lo è.
Process-first: perché i processi si mappano prima di configurare
L'approccio opposto è il più diffuso e ha una logica apparente: la piattaforma è già pronta, la si attiva e poi la si adatta. Il risultato tipico è un sistema che replica il processo esistente senza che nessuno lo abbia mai esaminato, compresi i passaggi che esistono solo perché prima si usava un foglio di calcolo.
Il caso più riconoscibile è la pipeline. Molte pipeline appena implementate hanno stadi che corrispondono a colonne di un vecchio prospetto, non a decisioni reali del cliente. Nessuno sa dire che cosa deve accadere perché una trattativa passi da uno stadio al successivo, e il risultato è che gli stadi vengono aggiornati a memoria o non vengono aggiornati affatto.
Correggere dopo il go-live è caro: cambiare il modello dati significa rifare la migrazione, i report costruiti sopra e le automazioni che vi si appoggiano. A monte sarebbe stato un pomeriggio di interviste. La stessa logica vale per le integrazioni con gli altri sistemi, che vanno progettate a partire dal processo e non dalle possibilità tecniche del connettore: il tema è trattato nella guida alle integrazioni HubSpot.
Migrazione dei dati e integrazioni: le due fasi che sforano
Il vincolo di calendario di un progetto CRM non è quasi mai la configurazione. È la qualità del dato di partenza, che si scopre solo quando la migrazione comincia davvero. Anagrafi duplicate, aziende scritte in tre modi diversi, contatti senza consenso tracciabile, storici incompleti: ogni categoria richiede una decisione, e ogni decisione richiede qualcuno che abbia l'autorità di prenderla.
Quattro decisioni vanno anticipate: le regole di deduplica, cioè quale campo determina l'identità di un'azienda e di una persona; i campi obbligatori alla creazione, tenuti al minimo; il criterio di esclusione, cioè che cosa resta in archivio consultabile; il responsabile del collaudo dei dati, che firma dichiarando utilizzabile il contenuto migrato.
Sulle integrazioni con i sistemi gestionali vale un principio di sequenza. Integrare erp con crm ha senso quando entrambi i lati hanno un modello dati stabile; farlo mentre il modello del CRM è ancora in discussione significa costruire due volte lo stesso collegamento. La decisione sull'edizione della piattaforma incide anche qui, ed è utile conoscerne in anticipo i limiti funzionali, come nel confronto fra le edizioni Professional ed Enterprise di HubSpot.
Come si governa il progetto: ruoli, cadenza, criteri di uscita
La governance del progetto ha bisogno di quattro ruoli nominati: lo sponsor, che decide sui processi; l'owner di processo, che rappresenta chi il processo lo esegue; l'owner del dato, che decide su regole e qualità; il referente tecnico, che risponde delle integrazioni. Un progetto senza owner del dato produce quasi sempre un sistema con centinaia di proprietà personalizzate e nessuna regola su chi può crearle.
Il budget deve comprendere anche il costo dell'avvio assistito, che non è sempre facoltativo. Il catalogo pubblico di HubSpot, per esempio, dichiara l'onboarding obbligatorio per Marketing Hub Professional con una fee una tantum di 3.000 dollari e per Marketing Hub Enterprise con una fee di 7.000 dollari (Fonte). È una voce che va messa a piano insieme alle licenze, non scoperta in fase di firma.
I criteri di uscita, infine, cambiano la natura del go-live. Dichiararlo concluso alla consegna significa misurare il fornitore; dichiararlo concluso sull'adozione significa misurare il risultato. Quattro indicatori dei primi novanta giorni bastano: quota di trattative aperte nel sistema rispetto a quelle reali, aggiornamento degli stadi entro un tempo definito, attività registrate automaticamente sul totale, campi obbligatori compilati alla prima interazione. Hanno senso perché il tempo commerciale è la risorsa in gioco: i venditori passano già il 60% delle giornate in attività che non sono vendita (Fonte), e un CRM che non riduce quella quota non ha ancora prodotto il suo ritorno. La logica di misurazione continua poi a regime, con l'uso dei dati del CRM come base delle decisioni commerciali.
Digital360 Connect struttura i progetti di Customer Platform in questa sequenza, con il blueprint come artefatto contrattuale e i criteri di uscita concordati prima dell'attivazione.
Conclusione
Un progetto CRM non si giudica dalla piattaforma che consegna, ma dai tre documenti che lascia: la mappa dei processi, il blueprint e il verbale di collaudo firmato da chi userà il sistema. Chi li pretende in fase di offerta compra un progetto; chi non li pretende compra una configurazione.
FAQ: implementazione CRM
Quali sono le fasi di un'implementazione CRM?
Tre: assessment dei processi e dei dati, blueprint del modello operativo, attivazione con configurazione, migrazione, formazione e collaudo. Ogni fase produce un artefatto verificabile.
Quali deliverable deve consegnare un partner in un progetto CRM?
Una mappa dei processi in cui chi vende si riconosce, un blueprint leggibile da chi non entra nella piattaforma e un verbale di collaudo firmato dagli utenti. Senza questi tre documenti non esiste un criterio oggettivo di accettazione.
Quanto costa l'onboarding di un CRM?
Dipende dalla piattaforma e dall'edizione. HubSpot dichiara a catalogo pubblico un onboarding obbligatorio per Marketing Hub Professional a 3.000 dollari una tantum ed Enterprise a 7.000. La voce va prevista a budget insieme alle licenze.
Che cosa significa approccio process-first in un progetto CRM?
Significa mappare e ridisegnare i processi commerciali prima di configurare la piattaforma, così che il sistema rifletta il modello di vendita dell'azienda invece delle impostazioni predefinite del prodotto.