Un case study sulla migrazione da Salesforce a HubSpot dovrebbe dimostrare quattro cose: cosa non è stato trasferito, in che stato era il data dictionary prima e dopo, quanti workflow sono stati ricostruiti anziché copiati e se i commerciali usano ancora il sistema a distanza di tre mesi. Un titolo come "completata in sei settimane, senza interruzioni dell'attività" non ne dimostra nessuna. Vi dice quanto in fretta è finito il progetto, non se ciò che è andato in produzione funziona.
Ne leggo parecchi. La testimonianza sulla homepage di un partner HubSpot, per esempio, dirà che il passaggio si è concluso in sei settimane senza interruzioni. Ci credo. So anche che "nessuna interruzione" e "non si è rotto nulla" sono affermazioni diverse, e nella citazione compare solo la prima.
Perché la velocità è la prova più debole in un case study di migrazione
La velocità è facile da riportare e poco costosa da ottenere. Si possono spostare i record in fretta se si salta il lavoro che li rende utili: deduplica, decisioni di mappatura dei campi, definizione degli stage, permessi. Il calendario sembra splendido. Il conto arriva al terzo mese.
La mia regola pratica è che un case study si guadagna fiducia in proporzione a quanto ammette. Se nella storia non ci sono perdite, l'autore o non ha guardato o non voleva che guardaste voi. Quindi, quando leggete un case study sulla migrazione da Salesforce a HubSpot, saltate la timeline e cercate la colonna delle perdite.
Cosa non è stato trasferito è la prima cosa da chiedere
Ogni migrazione lascia qualcosa indietro. La domanda è se il partner sapeva cosa, l'ha deciso di proposito e l'ha comunicato al cliente prima del go-live.
I candidati tipici sono lo storico dell'attribuzione, file e allegati, automazioni che dipendono da funzionalità esclusive di Salesforce, la logica dei report e le strutture dei permessi. Conta anche l'ordine degli oggetti: la documentazione di HubSpot sull'importazione chiarisce che le associazioni dipendono da come e quando i record vengono caricati, per cui una sequenza sbagliata elimina silenziosamente le relazioni tra contatti, aziende e deal.
Ecco il test. Chiedete al partner la lista di ciò che è stato "lasciato indietro" in un progetto passato. Non un riepilogo: la lista. Una buona lista contiene voci, ciascuna con una motivazione (archiviato, ricostruito in modo diverso, eliminato perché nessuno lo usava) e un responsabile che ha dato il proprio benestare. Se la risposta è "non è stato perso nulla di importante", avete imparato qualcosa, ma non ciò che intendevano farvi sapere.
Lo stato del data dictionary in un case study sulla migrazione da Salesforce a HubSpot
Il data dictionary è il documento che dice cosa significa ogni campo, chi ne è responsabile, quali valori sono ammessi e quali sistemi vi scrivono. La maggior parte delle org Salesforce di cinque anni non ne ha uno di cui qualcuno si fidi. Centinaia di campi, alcuni che significano la stessa cosa, una manciata che nessuno sa spiegare.
Migrare quel caos uno a uno è ciò che chiamo lift and shift, ed è il motivo più comune per cui un nuovo portale sembra il vecchio con un logo diverso. Un buon case study indica il numero di campi prima e dopo. Se un'azienda è passata da 400 proprietà personalizzate a 150, è la prova che qualcuno ha preso decisioni. Se è passata da 400 a 400, il progetto ha solo spostato i mobili.
I duplicati sono la stessa storia in miniatura. Un cliente con cui abbiamo parlato aveva circa 1.300 record duplicati nel CRM di origine e transizioni degli stage di pipeline mai testate, con una scadenza che incalzava. Questi due fatti sono il progetto. Il cambio di piattaforma è la parte facile. Poiché le due piattaforme gestiscono i duplicati in modo diverso, come spiega la guida di HubSpot alla deduplica, un case study dovrebbe dire quando è avvenuta la pulizia e chi ha deciso quale record sopravvive.
Ricostruzione dei workflow: contateli e chiedete cosa è stato dismesso
Le automazioni non si migrano. Si ricostruiscono, ed è nella ricostruzione che sta il giudizio. Un partner che ricostruisce in HubSpot ogni flow di Salesforce ha copiato il vostro debito tecnico dall'altra parte.
Chiedete tre numeri: workflow nel vecchio sistema, workflow ricostruiti, workflow dismessi. Poi chiedete un esempio per ciascuno. Per esempio, una regola di assegnazione dei lead che nessuno sapeva spiegare va dismessa, un promemoria di rinnovo su cui tutti fanno affidamento va ricostruito e un trigger di cambio stage che alimentava una dashboard che nessuno apre va eliminato. Se un case study non riesce a mostrare questa suddivisione, la ricostruzione è stata meccanica.
Qui vengono messi alla prova anche il routing e le definizioni degli stage. Il nostro articolo su come distinguere un portale rotto da un preventivo di ricostruzione tratta lo stesso istinto da un'altra angolazione.
L'adozione dopo il go-live è l'unico risultato che conta
I risultati di ricerca su questo tema si fermano per lo più al go-live. È lì che si ferma la fattura, ed è lì che inizia il rischio. I commerciali tornano ai fogli di calcolo, i manager smettono di fidarsi del forecast e il marketing ricostruisce in silenzio i propri report.
Non ho un benchmark di settore affidabile sull'adozione da parte dei commerciali a novanta giorni da una migrazione CRM, e diffido di chi ne cita uno. Ciò che chiederei a un case study è semplice: accessi e attività registrate per commerciale a 30, 60 e 90 giorni, accuratezza del forecast rispetto al trimestre precedente e la data in cui il vecchio sistema è stato spento definitivamente. E anche il report firmato sia dalla finanza sia dalle vendite. Se l'attribuzione faceva parte della vecchia configurazione, verificate che fine ha fatto: molto traffico influenzato dall'AI e privo di tag finisce già come direct in HubSpot, come abbiamo spiegato in referral AI classificati come traffico direct.
Il case study sulla migrazione da Salesforce a HubSpot riguarda un'azienda come la vostra?
Un case study è una prova solo se il protagonista vi somiglia. Chiedete quattro cose: volume di record, numero di oggetti personalizzati, numero di integrazioni attive e numero di utenti. Un team da 15 postazioni senza oggetti personalizzati e un team da 300 postazioni con CPQ sono progetti diversi che condividono solo il titolo.
Poi chiedete quanto è costato in totale. Il preventivo è un solo numero. Aggiungete le parcelle del partner, la sovrapposizione delle licenze mentre i due sistemi restano attivi, il tempo dei commerciali perso per la riqualificazione e le rilavorazioni. Esempio, basato solo su ipotesi: se 40 commerciali perdono due ore a settimana per sei settimane, sono 480 ore di vendita, prima di qualsiasi rilavorazione. I buoni partner ripercorreranno questo calcolo insieme a voi, perché è la versione onesta del prezzo.
Una breve checklist per qualsiasi case study sulla migrazione da Salesforce a HubSpot
Prima di firmare, chiedete al partner di mostrarvi, da un progetto reale:
- La lista di ciò che è stato lasciato indietro, con i responsabili
- Numero di campi e proprietà prima e dopo
- Workflow ricostruiti rispetto a quelli dismessi
- Dati di adozione e di forecast a 30, 60 e 90 giorni
- Costo totale a confronto con il preventivo iniziale
Sono cinque documenti. Un team che li ha ve li consegnerà in pochi minuti, perché anche noi andiamo fieri di documentare i nostri progetti, per quanto possa sembrare strano. Un team che non li ha vi ha già detto quello che dovevate sapere.
Se volete vedere che aspetto ha questa evidenza nel nostro lavoro, partite dal nostro case study sulla migrazione CRM e dall'ambito del nostro servizio di migrazione da Salesforce a HubSpot. Giudicateci con la stessa lista. La stessa abitudine vale anche fuori dal lavoro sul CRM: le prove battono il posizionamento, come sostengono SEO rankings versus AI citations e perché aggiungere l'AEO a una società di implementazione non basta.