La settimana scorsa un founder mi ha fatto una domanda del tutto ragionevole: a che punto è davvero questo progetto? Nessuno in sala sapeva rispondere. Non perché mancasse il dato, ma perché viveva in due sistemi e nessuno dei due era proprietario della risposta.
È la domanda più costosa in un’organizzazione revenue in crescita, e la soluzione a cui i team ricorrono è quasi sempre quella sbagliata. Sentono una richiesta di visibilità e iniziano a definire un’integrazione. Sei settimane dopo c’è una sincronizzazione che gira nelle due direzioni e il founder ancora non sa rispondere alla domanda.
Perché sta peggiorando, non migliorando
Il motivo per cui continua a incontrare questo problema è che il mercato non ha stabilito dove risiede la verità, quindi ogni azienda lo decide silenziosamente per conto proprio. Analizzando l’acquisizione di Momentum da parte di Salesforce a febbraio, Anthony McPartlin di Forrester ha inquadrato la scelta davanti agli acquirenti: un approccio CRM-as-a-platform, che le compra “simplicity, centralized governance, and a single point of accountability”, oppure una piattaforma di verità best-of-breed, che le compra “faster innovation and advanced specialization”. La sua previsione è che le suite continueranno ad assorbire quegli strati di orchestrazione invece di lasciare che gli specialisti si collochino tra il CRM e il workflow.
Quella è una battaglia tra vendor. La sua versione è più piccola e più urgente. Ha un CRM, ha un secondo sistema dove avviene il lavoro vero, e ha un dirigente che vuole una sola frase su dove sono le cose. Nessuno ha deciso quale sistema abbia il diritto di rispondere.
La diagnosi sbagliata
Il punto è questo. Quando qualcuno chiede visibilità, l’istinto è collegare i sistemi: sincronizzazione bidirezionale, mappatura dei campi, record duplicati da entrambe le parti. È moltissimo lavoro di build, è onestamente costoso da mantenere, e il giorno in cui la duplicazione va alla deriva ha creato un problema nuovo, con due team che puntano il dito sui dati dell’altro invece che sul lavoro.
Inoltre risolve la cosa sbagliata. Il dirigente che chiede visibilità non vuole i record dell’altro sistema. Vuole tre fatti: in che fase siamo, chi ne risponde adesso e se è bloccato. È un problema di reporting con una superficie piccolissima, e può rispondere senza spostare un solo campo.
Qui applicherei lo schema keep / edit / delete prima che qualcuno scriva una specifica di integrazione. Keep: i dati che rispondono alla domanda del dirigente. Edit: il journey, perché la responsabilità sia esplicita. Delete: l’assunto che entrambi i sistemi debbano sapere tutto ciò che sa l’altro. L’integrazione è un modo di comprare visibilità, ed è il più caro del menù.
Costruisca uno strato di stato sopra il journey
Ciò che produce davvero visibilità è uno strato leggero che sta sopra il suo customer journey e lo riassume. Non un’altra pipeline. Un piccolo insieme di property sull’oggetto che per lei è la vera unità di lavoro: l’account, il progetto, il portfolio.
È la parte che quasi tutti saltano, perché uno strato di stato sembra troppo semplice per essere la risposta a un problema che sembrava architetturale.
Quattro campi reggono quasi tutto il peso:
- Milestone corrente. Un valore da un elenco breve, da sei a dieci opzioni, non ogni singolo micro-passaggio.
- Owner corrente. La persona indicata per nome che risponde dell’avanzamento, e che cambia quando cambia la milestone.
- Bloccato. Un booleano più una riga di motivazione.
- Data della prossima azione. La data in cui dovrebbe succedere qualcosa.
Quello strato tocca le milestone portanti e ignora deliberatamente il dettaglio sottostante. Se il sistema operativo esegue una checklist da cinquanta passaggi, allo strato di stato non interessano i passaggi dall’undici al diciannove. Gli interessa che siete in build, che una persona indicata per nome ne risponda e che non sia fermo. La granularità vive dove si svolge il lavoro. Il riassunto vive dove guarda il dirigente.
Ogni fase dichiara il suo sistema
La seconda metà della soluzione è documentazione, e costa un ordine di grandezza in meno dell’integrazione. Percorra il journey fase per fase e scriva in modo esplicito in quale sistema le persone lavorano in quella fase e cosa ci fanno.
La maggior parte della confusione tra sistemi non è affatto un problema di dati. È che nessuno ha scritto dove avviene il lavoro, quindi ciascuno dei due team ha dato per scontato che stesse guardando l’altro. Nel momento in cui una fase dice “da qui in avanti si lavora nello strumento operativo, e l’unica cosa che il CRM le chiede è il valore della milestone”, l’ambiguità sparisce e la sincronizzazione che stava per costruire si riduce a un campo.
Poi sfrutti i punti di forza di ciascuna piattaforma invece di appiattirli. Routing dei casi, ticketing ed e-mail in entrata appartengono al CRM, dove quel meccanismo esiste già. L’esecuzione appartiene al sistema costruito per eseguire. Accetti che una persona, di solito un gatekeeper del routing, lavorerà su entrambi. È un ruolo, non un difetto.
Metta un gate sul passaggio di consegne invece di sincronizzarlo
Il passaggio di consegne è il punto in cui la visibilità muore davvero, e le evidenze sono insolitamente nette. Un panel di SaaStr su come le aziende AI più veloci hanno ricostruito il customer success indica il passaggio di consegne come “the place most failure and data loss happens”. Un’azienda di quel panel ha spostato il closed-won fuori dal sales e dentro l’implementazione come soglia, così che un contratto firmato ma mai avviato non venisse mai conteggiato. Il loro churn è passato dal 4% al mese a circa mezzo punto percentuale mentre scalavano da 8 milioni a 200 milioni di dollari di ARR.
Non è una storia di integrazione. È una storia di definizioni. Hanno cambiato che cosa significa una fase e chi ha il diritto di dichiararla.
Faccia lo stesso con i suoi gate. Una fase deve avere criteri di ingresso, e non vi si entra finché non sono soddisfatti. Non passi mai un cliente a un nuovo team mentre il team precedente ha ancora punti aperti, perché è esattamente il momento in cui la responsabilità diventa ambigua e la visibilità sparisce per chiunque stia sopra al lavoro. Se ha checkpoint go/no-go binari sepolti dentro una fase, e la maggior parte dei processi di verifica tecnica ne ha due o tre, promuova ciascuno a fase dedicata con un proprio owner. Un checkpoint che nessuno vede è un checkpoint di cui nessuno risponde.
Pipeline parallele, responsabilità parallele
Per i team in cui il lavoro commerciale e quello operativo procedono davvero insieme, una sola pipeline non regge. Ne usi due: una pipeline commerciale e una pipeline operativa che si apre in parallelo, ciascuna con le proprie fasi, entrambe che confluiscono nello stesso strato di stato.
La responsabilità si divide allo stesso modo. Sull’account tenga campi owner separati per la relazione commerciale e per quella operativa, più chi possiede l’onboarding e chi possiede l’account dopo la vendita. Sembrano più campi. Sono meno discussioni, perché in ogni momento c’è esattamente un nome per ciascun tipo di domanda.
Come è andata sul campo
Stiamo lavorando con un piccolo team DACH, sotto le venti persone, che sta facendo due cose difficili insieme: migrare da un CRM legacy e costruire un proprio strumento operativo interno. Il criterio di successo dichiarato dal founder per l’intero programma era una vista unica che mostrasse dove si trova ogni progetto, dal primo lead in entrata fino all’operatività.
La proposta sul tavolo era collegare i due sistemi. Il founder ha ribattuto che non sarebbe bastato, e aveva ragione, anche se non per il motivo che pensava. Il problema non è mai stato che il dato fosse in due posti. Era che una fase di verifica tecnica in più passaggi risultava invisibile a chiunque fosse fuori dal team che la eseguiva, e che nessuno aveva messo per iscritto quale sistema possedesse lo stato di un progetto in un dato momento.
Quello che abbiamo definito invece: otto milestone sul record di progetto, un campo owner per milestone, un link in sola lettura dal record CRM allo strumento operativo per chi ha bisogno del dettaglio, e tre punti di verifica promossi da sotto-passaggi nascosti a fasi con un nome. La sincronizzazione bidirezionale è uscita del tutto dalla roadmap. Costo totale: una frazione dell’integrazione, e la visibilità che il founder chiedeva arriva in settimane invece che in un trimestre.
Il playbook
- Scriva prima la domanda. Si faccia dare la frase esatta che il dirigente vuole poter dire, con le sue parole. Ogni decisione di design qui sotto si giudica rispetto a quella.
- Scelga la casa del reporting. Un solo sistema risponde a “dove siamo”. Di solito è il CRM, perché lì vivono già la vista funnel e il forecast. Lo decida ad alta voce.
- Definisca da sei a dieci milestone. Solo le transizioni portanti. Se gliene servono più di dieci, sta descrivendo attività, non milestone.
- Metta un owner su ogni milestone. Una persona indicata per nome, che cambia man mano che la milestone avanza.
- Dichiari il sistema di lavoro per fase. Una riga per fase nel documento di journey: qui si lavora in questo sistema, in questo modo.
- Scriva i criteri di ingresso e li faccia rispettare. Nessun avanzamento di fase finché la fase precedente ha punti aperti. Promuova ogni go/no-go nascosto a fase visibile.
- Colleghi, non duplichi. Un puntatore in sola lettura da un record all’altro copre il caso del dettaglio. Sincronizzi solo il valore della milestone, e in una sola direzione.
- Riveda ogni settimana rispetto al punto uno. Se il dirigente ancora non riesce a dire quella frase, è lo strato a essere sbagliato, e si corregge lo strato, non l’integrazione.
La maggior parte dei team chiude tutti e otto i punti in un paio di settimane. L’integrazione che stavano per commissionare avrebbe richiesto un trimestre e comunque non avrebbe risposto alla domanda.
Se il suo leadership team chiede a che punto sono le cose e ottiene una risposta diversa a seconda di chi interpella, ha una lacuna di visibilità per come è progettato il sistema, non un problema di strumenti. Possiamo costruire lo strato di stato sopra il suo journey esistente, oppure, se il secondo sistema è un CRM che sta comunque lasciando, partire dalla migrazione. In ogni caso, ci dica cosa il suo dirigente vuole vedere e le diremo se le serve davvero un’integrazione.
Fonti
- Forrester. “What Salesforce’s Acquisition Of Momentum Means.” Anthony McPartlin, febbraio 2026. forrester.com
- SaaStr. “Lovable, Harvey and Assembly AI: How the Fastest AI Companies Rebuilt Customer Success.” Jason Lemkin, giugno 2026. saastr.com