Tutto ciò che serve per un'implementazione HubSpot che il tuo team usa davvero, spiegato dai principi fondamentali. Come si articola l'architettura degli hub, come progettare un CRM che rispecchi il processo reale, come costruire automazioni che si attivano correttamente, come migrare i dati senza romperli e come connettere HubSpot al resto dello stack. Nessun contenuto promozionale, nessuna funzionalità glissata. Solo la meccanica di farlo nel modo giusto.
La maggior parte delle implementazioni HubSpot fallisce in silenzio. Il portale viene configurato, il team riceve una panoramica e tre mesi dopo metà delle funzionalità è inutilizzata, i dati sono un disastro e qualcuno ha costruito un foglio di calcolo parallelo per tracciare ciò che HubSpot avrebbe dovuto gestire. Il problema non è la piattaforma. L'implementazione è stata fatta al contrario: prima le funzionalità, poi il processo, i dati mai. Quello che segue è come lo facciamo nel verso giusto.
HubSpot è costruito attorno a un database CRM condiviso con hub specializzati sovrapposti. Ogni hub, Marketing, Sales, Service, CMS e Operations, legge e scrive sugli stessi record di contatti, aziende, trattative e ticket. Questo livello condiviso è al tempo stesso il principale punto di forza della piattaforma e la fonte più comune di problemi quando non viene progettato con intenzione.
L'implicazione pratica è che la progettazione del CRM deve precedere la configurazione degli hub. Se costruisci i workflow di Marketing Hub prima di aver deciso come appare la progressione del lifecycle stage, passerai i sei mesi successivi a riempire le lacune logiche a posteriori. Iniziamo sempre dal modello degli oggetti e dal design della pipeline, poi costruiamo gli hub su una base che rispecchia davvero il business.
HubSpot include un ampio set di proprietà predefinite. La maggior parte delle implementazioni ne usa meno di un terzo, poi aggiunge duecento proprietà personalizzate sopra, una per ogni campo richiesto al momento senza pensare da dove verrebbero i dati o chi li avrebbe mantenuti. Il risultato è un record contatto con quaranta campi e venti di essi vuoti.
Una buona progettazione del CRM parte da tre domande: quale decisione supporta questa proprietà, chi è responsabile di tenerla aggiornata e qual è la fonte di verità? Una proprietà per cui nessuno sa rispondere a queste domande non appartiene al portale.
Una pipeline di trattative deve mappare esattamente come lavora davvero il tuo team di vendita, non come vorresti che lavorasse. Ciò significa fasi definite da ciò che ha fatto il compratore, non da ciò che il venditore vuole fare dopo. "Proposta inviata" è un'azione del venditore; "Proposta revisionata dal prospect" è un segnale del compratore e un indicatore molto più solido di dove si trova davvero la trattativa.
Costruiamo le pipeline intervistando le persone che le usano, poi mappiamo il percorso del compratore dal primo contatto alla chiusura, con un criterio di ingresso e uno di uscita chiari per ogni fase. I team che avevano una pipeline ma non la usavano in modo coerente di solito scoprono che le fasi erano state definite dal precedente responsabile vendite in un modo che non corrisponde a come le trattative si muovono effettivamente.
I quattro oggetti standard di HubSpot (contatti, aziende, trattative, ticket) coprono la maggior parte dei casi d'uso, ma le aziende con modelli di dati più complessi hanno bisogno di oggetti personalizzati. Un'azienda SaaS potrebbe aver bisogno di un oggetto Abbonamento per tracciare piano, MRR e data di rinnovo separatamente dalla trattativa. Una società di servizi professionali potrebbe aver bisogno di un oggetto Ingaggio per tracciare i deliverable del progetto. Gli oggetti personalizzati aggiungono potenza ma anche complessità, quindi la regola è: usarli quando gli oggetti standard non riescono genuinamente a modellare i dati, non perché sembra più ordinato in teoria.
Marketing Hub gestisce email, landing page, form, annunci, social e l'automazione che collega l'attività inbound ai record contatto. Il lavoro di configurazione che conta di più non è la parte visiva: è la logica sottostante.
Le quattro cose che determinano se Marketing Hub sta davvero funzionando per te:
Sales Hub offre ai rep la timeline dei contatti, il tracciamento email, la prenotazione meeting, la gestione trattative e le sequences. Il divario tra ciò che può fare e ciò che la maggior parte dei team usa effettivamente è enorme, e di solito si riduce agli stessi due problemi: il CRM non era configurato per rispecchiare il processo di vendita reale, quindi i rep si fidano del foglio di calcolo più che del portale; e le funzionalità che fanno risparmiare più tempo (sequences, template, meeting link) non sono mai state configurate da qualcuno che capisce come vende il team.
Il lavoro di configurazione che facciamo su Sales Hub:
Service Hub gestisce il supporto clienti tramite una casella condivisa, una pipeline di ticketing, una knowledge base e sondaggi sulla soddisfazione dei clienti. Il fallimento più comune è una pipeline di ticket che non è mai stata mappata sul processo di supporto reale, così i ticket rimangono in fasi che non significano nulla e il reporting è inutile.
Costruiamo la pipeline dei ticket dalla logica reale di triage ed escalation del team di supporto, aggiungiamo regole SLA che rispecchiano gli impegni effettivamente presi dal team e configuriamo il routing in modo che i ticket arrivino alla persona giusta senza intervento manuale. I sondaggi CSAT e NPS valgono la pena di essere condotti solo se i dati finiscono da qualche parte utile, quindi li colleghiamo alle proprietà contatto e alle dashboard che il team controlla regolarmente.
I workflow sono dove HubSpot recupera il costo della licenza, e sono dove avvengono gli errori più costosi. Un workflow che iscrive i contatti sbagliati, si attiva al momento sbagliato o ha un branch rotto corromperà i tuoi dati senza alcun errore visibile. Trattiamo la progettazione dei workflow nello stesso modo in cui trattiamo lo sviluppo software: prima i requisiti, spec prima della build, test prima dell'attivazione.
I tipi di workflow che costruiamo più spesso:
Il lead scoring è una delle funzionalità più richieste e una delle più spesso abbandonate dopo l'implementazione. Il motivo è quasi sempre lo stesso: il punteggio è stato costruito con valori che qualcuno ha stimato, non è mai stato validato rispetto alle trattative effettivamente chiuse e dopo un mese il team marketing aveva 600 MQL di cui il team vendite non si fidava.
Un modello di scoring che funziona ha due componenti. L'adeguatezza demografica (dimensione aziendale, settore, job title, area geografica) dice se questa è il tipo di azienda che compra da te. La profondità di engagement (visite alle pagine, click sulle email, invii di form, richieste di demo) dice se questo specifico contatto è davvero interessato adesso. I due punteggi devono essere tracciati separatamente e combinati alla soglia MQL, perché un'azienda perfettamente allineata senza engagement è solo una lista di prospect freddi, e un contatto altamente coinvolto in un'azienda troppo piccola o del settore sbagliato è uno spreco di tempo per il team di vendita.
La migrazione dati è dove le implementazioni subiscono ritardi, e il ritardo è quasi sempre dovuto al fatto che i dati sorgente erano più disordinati del previsto. La regola che applichiamo: non iniziare una migrazione finché non hai fatto un audit completo del sistema sorgente. Ciò significa capire il modello degli oggetti, mappare ogni campo su una proprietà HubSpot, profilare la qualità dei dati (completezza, duplicati, outlier) e concordare cosa viene migrato rispetto a cosa viene archiviato.
La migrazione stessa segue una sequenza specifica. Prima eseguiamo una migrazione di test su un portale sandbox, rivediamo l'output con il cliente, correggiamo i problemi di mapping, poi eseguiamo la migrazione completa in produzione con un passaggio di validazione prima del cutover. Le attività (email, chiamate, note, meeting) vengono migrate separatamente dai record perché hanno strutture dati diverse e diversi livelli di qualità accettabili.
Quasi ogni migrazione CRM porta alla luce duplicati. I contatti creati da form web, import e inserimento manuale nel corso degli anni raramente hanno indirizzi email e nomi di dominio coerenti che rendano affidabile la deduplicazione automatica. Eseguiamo un'analisi di fuzzy match su email, telefono, nome e azienda prima della migrazione, esaminiamo i match per livello di confidenza e uniamo o archiviamo in batch con un audit trail completo.
HubSpot ha uno strumento integrato di gestione dei duplicati che gestisce i casi ovvi. I casi più difficili (la stessa persona con due domini email diversi, o un record contatto e uno aziendale che dovrebbero essere associati ma non lo sono) richiedono revisione umana e a volte un workflow di data quality in Operations Hub per catturare i nuovi duplicati in futuro.
HubSpot si trova al centro dello stack, non ai suoi margini. Il valore dei dati che contiene dipende da quanto bene rimane sincronizzato con i sistemi che generano e consumano quei dati. Un contatto che esiste in HubSpot ma non nel tuo sistema di fatturazione è una lacuna nella tua visione del cliente. Una trattativa che si chiude in HubSpot ma non innesca una fattura Stripe è un processo rotto.
Opzioni di integrazione in ordine approssimativamente crescente di complessità:
Il reporting di HubSpot è potente e largamente sottoutilizzato. Le dashboard predefinite sono un ragionevole punto di partenza ma rispondono alle domande che HubSpot presume tu abbia, non alle domande che il tuo team deve davvero rispondere. Costruiamo il reporting dalle decisioni che devono essere prese, non dai grafici facili da creare.
I report che tendono a contare di più in un'implementazione iniziale:
| Report | Cosa ti dice |
|---|---|
| Distribuzione dei lifecycle stage dei contatti | Dove i contatti si accumulano o si fermano nel tuo funnel |
| Velocità trattative per fase | Quanto tempo le trattative restano in ogni fase e dove vanno quando escono |
| Tasso di conversione MQL in SQL | Se marketing e vendite concordano su come appare un buon lead |
| Deliverability email per campagna | Open rate, click rate e unsubscribe rate per invio, con una baseline di confronto |
| Errori di enrollment nei workflow | Contatti che non si sono iscritti o hanno colpito uno step rotto, catturati prima che diventino problemi di qualità dei dati |
| Riepilogo attività rep | Chiamate, email e meeting registrati, così l'adozione del CRM è visibile piuttosto che presupposta |
L'adozione è dove fallisce la maggior parte delle implementazioni, ed è la parte che la maggior parte dei partner di implementazione salta perché avviene dopo la consegna. Un portale tecnicamente corretto ma non utilizzato non è un'implementazione: è un archivio costoso.
I fattori che guidano l'adozione non sono complicati, ma richiedono che il team di implementazione se ne preoccupi. L'interfaccia deve essere configurata per mostrare alle persone le informazioni di cui hanno bisogno per fare il loro lavoro, non l'intera profondità di ciò che HubSpot può conservare. Un rep di vendita che apre un record contatto e vede quaranta campi, la maggior parte vuoti, tornerà al suo foglio di calcolo. Un rep che apre un record contatto e vede le cinque cose di cui ha bisogno prima di una chiamata lo userà.
Conduciamo sessioni di onboarding specifiche per ruolo piuttosto che una panoramica generica del prodotto. Il marketing vede il setup delle campagne, la logica dei form e gli strumenti email. Le vendite vedono la pipeline, le sequences e i meeting link. Il supporto vede la pipeline dei ticket e la knowledge base. Ogni sessione termina con il team che usa lo strumento per il proprio lavoro reale, non per uno scenario demo, così eventuali mancate corrispondenze di processo emergono prima del go-live piuttosto che in un ticket di supporto due settimane dopo.
I trenta giorni dopo il lancio sono il periodo ad alto rischio per l'adozione. Rimaniamo disponibili durante quel periodo, monitoriamo il portale per i segnali di utilizzo (errori di enrollment nei workflow, proprietà aggirate, fasi che non hanno mai trattative) e conduciamo una chiamata di check-in alla settimana due per affrontare ciò che è emerso nella pratica.
Un elenco onesto degli errori che vediamo più spesso e come evitarli:
Questa è la metodologia completa. Quando vuoi che venga applicata al tuo portale, il passo successivo è un audit gratuito: un'analisi reale del tuo setup effettivo, una roadmap prioritizzata e nessun obbligo di procedere.
Un audit gratuito sul tuo portale reale, le lacune e i loro costi quantificati, e un perimetro fisso per costruire ciò che mappa. Risultati in una settimana.
Richiedi un audit HubSpot gratuito