La maggior parte delle implementazioni HubSpot che vanno male non vanno male perché il team ha scelto il tool sbagliato o il consulente sbagliato. Vanno male perché qualcuno ha compresso una fase. L'arco di implementazione ha cinque fasi, Discovery, Design, Build, Launch, Optimize, e ognuna finisce con un artifact che il team difenderà. Salti l'artifact e la fase successiva poggia su conversazione invece che su impegno. Il costo emerge due mesi dopo, quando Build riapre decisioni che avrebbero dovuto chiudersi nella seconda settimana.
Perché conta proprio adesso
Il brief HBR sul perché gli investimenti digitali falliscono nel creare valore lo dice piano: il failure mode non è il tooling, è il non riuscire a ridisegnare il modo in cui l'organizzazione commerciale genera insight, prende decisioni e coordina l'azione. Un'implementazione HubSpot è uno dei pochi momenti in un'azienda B2B SaaS in cui quel ridisegno viene forzato allo scoperto, schema, pipeline, ownership, reporting, tutto sul tavolo nello stesso momento. La metodologia in cinque fasi esiste perché il ridisegno è il lavoro. La configurazione della piattaforma è l'artifact alla fine.
Discovery
Discovery è la fase che i team comprimono più spesso, e dove la compressione è più costosa. Il lavoro non è parlare con la gente. Il lavoro è uscirne con un artifact scritto su cui l'intero team ha firmato, definizioni di pipeline, owner nominati per ogni oggetto, una mappa di integrazione, casi d'uso in-scope e out-of-scope, e i criteri di successo contro cui l'implementazione sarà misurata. Due settimane sono un budget equo. Una settimana produce una fase di Design da rifare.
Cosa significa fatto male, un deck di Discovery che elenca i tool in uso, qualche citazione di intervista e un set vago di obiettivi. Nessuno disaccorda perché niente è abbastanza specifico per disaccordare. Design poi scopre i disaccordi una decisione per volta, davanti a uno sviluppatore in attesa di indicazioni.
Design
Design è dove vivono le decisioni di schema. Ogni oggetto che esisterà nel portale di produzione: Contact, Company, Deal, l'oggetto custom subscription, l'oggetto portfolio se c'è, viene definito qui, per iscritto, prima che si costruisca qualsiasi cosa. Le proprietà ottengono un tipo di dato, una picklist se rilevante, un owner e una definizione di una frase. Le fasi di pipeline ottengono criteri di ingresso, criteri di uscita e una definizione di cosa significhi davvero la fase. Le etichette di associazione vengono esplicitate. Il deliverable alla fine di Design è un documento di schema più un inventory dei workflow che il team possa leggere end-to-end senza fare domande.
Cosa significa fatto male, un Design che avviene dentro la UI di HubSpot a colpi di click. Le proprietà vengono aggiunte live. Le fasi di pipeline vengono rinominate tre volte. Il documento di schema, se esiste, va in ritardo sul build di una settimana. Tre mesi dopo, nessuno si ricorda perché esiste la deal stage «Verbale», e l'unica persona che potrebbe rispondere se n'è andata.
Build
Build è la fase di sprint. Fatto bene, è una sequenza di due-sei settimane di deliverable piccoli, scopati e revieweabili: schema deployato in sandbox, workflow cablati, integrazioni connesse, report alzati, permission set configurati. La cadenza che regge è settimanale, una working session per confermare la prossima fetta, uno sprint di build a metà settimana, una demo alla fine. La cadenza che non regge è il check-in quindicinale dove il team di build sparisce e riappare con un portale finito che nessuno ha visto.
Build funziona solo se Discovery e Design hanno tenuto. Se hanno tenuto, Build è esecuzione contro una lista. Se non hanno tenuto, Build è discussioni travestite da standup. Il test diagnostico, in una qualsiasi settimana di Build, quante decisioni vengono riaperte? Se la risposta è più di una o due, il lavoro a monte non era finito.
Launch
Launch è cutover, training, e i primi dieci giorni. Il cutover è un venerdì, preferibilmente uno prima di una settimana tranquilla, e viene provato in sandbox prima di accadere in produzione. Il training viene erogato contro il sistema post-build, non quello legacy, ed è erogato a chi userà davvero il sistema, non solo ai leader che hanno scopato. I primi dieci giorni sono una finestra di hypercare, il team di build è on call, gli issue user-facing vengono triagati in ore anziché giorni, e i piccoli fix che emergono dall'uso reale atterrano prima che il team formi memoria muscolare attorno a workaround.
Cosa significa fatto male, un Launch che avviene un mercoledì perché il calendario diceva di sì, un deck di training registrato una volta e fatto girare come video, e un team di build smobilitato il giorno dopo il cutover. Per la terza settimana i workaround sono abitudini, i workaround sono ora il sistema, e la fase di Optimize li starà disfacendo invece di migliorarli.
Optimize
Optimize è la fase per cui nessuno pianifica un budget. L'implementazione viene scopata fino a Launch; Optimize viene trattato come il lavoro part-time di amministrazione di qualcuno. È l'errore. Ogni istanza HubSpot accumula, nuove proprietà vengono richieste, i workflow ottengono casi limite, i bisogni di reporting evolvono, il team impara cosa vuole davvero vedere rispetto a cosa pensava di volere. Optimize è la fase in cui quei segnali vengono triagati su una cadenza, mensile è giusto per la maggior parte delle aziende, invece di essere assorbiti dentro il rumore quotidiano.
Cosa significa fatto male, Optimize è quel che la persona ops senior riesce a fare tra un incendio e l'altro. Sei mesi dentro, il sistema è andato alla deriva rispetto allo schema documentato, nessuno ha auditato i workflow dal lancio, e la prossima persona che si unisce al team eredita un'istanza che è due-terzi disegno originale e un-terzo improvvisazione. Il budget di ottimizzazione che nessuno ha pianificato è ora il progetto di migrazione che nessuno voleva.
Schema dal campo
Un team B2B SaaS sul finale di Series A è venuto per un'implementazione HubSpot su una timeline di sei settimane. La Discovery era scopata in quattro giorni. Abbiamo respinto e l'abbiamo fatta girare per due settimane. L'artifact è stato un documento che copriva definizioni di pipeline, ownership, scope di integrazione, criteri di successo, e una lista di casi d'uso che il team concordava fossero out-of-scope per la v1. Design ha preso tre settimane e ha prodotto un documento di schema più un inventory dei workflow. Build è stato uno sprint pulito di quattro settimane: demo settimanali, nessuna decisione riaperta. Il Launch è stato un cutover di venerdì con una finestra di hypercare di una settimana presidiata dal team di build. Optimize è partito trenta giorni dopo il lancio su cadenza mensile e sta ancora girando. Il pezzo che vale la pena nominare, la prima quarterly business review del team sul nuovo sistema non ha richiesto una pulizia manuale dei dati. Ecco cosa Le compra una Discovery che non è stata compressa, dieci mesi dopo.
Risoluzione, scegliere il modello di engagement che mappa su ogni fase
Le cinque fasi non devono per forza vivere dentro un solo tipo di engagement. Fasi diverse premiano forme diverse di supporto. La mappatura che regge sulla maggior parte degli engagement B2B SaaS:
- Discovery è un workshop o un progetto strettamente scopato. Ha bisogno di attenzione senior, di una prospettiva esterna, e di un deliverable su cui il team interno firmerà. Non ha bisogno di un retainer di lunga durata.
- Design è un progetto. Il deliverable è un documento di schema e workflow, il budget è fisso, la timeline è due-quattro settimane. Lo tratti come tale.
- Build è un progetto o un engagement embedded, a seconda di quanto del lavoro di configurazione il team interno possa assorbire. Se ha un admin HubSpot in seat, la forma progetto funziona. Se non ce l'ha, embeddi qualcuno per la durata.
- Launch è un progetto con una coda di hypercare. Scopi cutover, training e i primi dieci giorni come un blocco. Non si appoggi alla buona volontà del team di build per presidiare la coda.
- Optimize è dove il supporto retainer o frazionale si guadagna il pane. Cadenza mensile, ore scopate, un backlog definito. L'errore è comprare un retainer prima che Discovery sia finita; l'altro errore è lasciarlo decadere il giorno dopo Launch.
- Cross-fase: se il team interno non ha ancora una funzione RevOps senior, un ruolo embedded frazionale che attraversa Discovery, Design e Optimize è spesso la forma giusta. Build resta un progetto.
- Stage check: in seed e pre-Series A, la forma progetto è quasi sempre giusta, il team interno non è ancora pronto ad assorbire un retainer. Da Series B in poi, il modello retainer o frazionale di solito ripaga dentro due trimestri, perché Optimize smette di essere il side gig di qualcuno.
Dove entra in gioco Checkpoint
La metodologia in cinque fasi è la spina dorsale di ogni engagement HubSpot e CRM che facciamo da Checkpoint. Le implementazioni greenfield fanno girare le fasi in ordine. Le migrazioni brownfield iniziano Discovery con l'audit. I redesign allungano Design e accorciano Build. Le fasi restano; le proporzioni cambiano. Se sta scopando un'implementazione adesso e la timeline non nomina tutte e cinque, ne parli con noi prima del kickoff. Facciamo questo lavoro come HubSpot implementation, come parte di GTM strategy, e come supporto RevOps embedded sull'intero stack.
Fonti
- Sinha, Shastri, Lorimer. «Why Your Digital Investments Aren't Creating Value». Harvard Business Review, 16 febbraio 2026. hbr.org
- Lemkin, Jason. «Which CRM Should You Use in 2026/2027? Follow the Agents». SaaStr, 6 aprile 2026. saastr.com