Ogni report sulla pipeline che esamino ha lo stesso punto debole. Le fasi sono obsolete. Le trattative rimangono in "Proposal Sent" due giorni dopo la firma del contratto perché un rappresentante si è dimenticato di spostare una card sulla board. È una piccola omissione, ma rende le tue previsioni sbagliate, i tuoi dati sulla velocità inaffidabili e le tue revisioni della pipeline un gioco d'azzardo.
C'è una soluzione semplice. Invece di affidarti agli esseri umani per aggiornare le fasi della trattativa, lasci che sia il documento stesso a innescare lo spostamento. Quando viene inviata una proposta, la trattativa avanza a "Proposal Sent." Quando viene inviata una richiesta di firma, si sposta a "Contract Sent." Quando il documento viene firmato, la trattativa passa a "Closed Won." Nessuna memoria necessaria.
Ecco come configurare la progressione automatica delle fasi del deal in HubSpot utilizzando la proprietà Document Status di Portant e i workflow standard di HubSpot. Se la tua pipeline sembra sempre essere in ritardo di qualche giorno rispetto alla realtà, questo è probabilmente il motivo.
Perché gli aggiornamenti manuali delle fasi di trattativa falliscono
I rappresentanti sono occupati. Sono in chiamata, scrivono email, fanno follow-up con i potenziali clienti. Aggiornare la fase di una trattativa è un'attività a bassa priorità che non aggiunge alcun valore alla vendita in sé. Quindi viene saltata, rimandata o fatta in blocco alla fine della settimana.
L'impatto è più grande di quanto la maggior parte dei leader realizzi. Se cinque rappresentanti dimenticano ciascuno di aggiornare tre trattative a settimana, ci sono quindici trattative ferme nella fase sbagliata in qualsiasi momento. Il tuo report sulla pipeline racconta una storia alla leadership. La realtà ne racconta un'altra.
La previsione dipende dalla fase. Se il tuo modello di previsione pondera le trattative in base alla probabilità della fase, le fasi obsolete producono numeri inaccurati. Una trattativa che è effettivamente chiusa ma che appare ancora come "Contract Sent" sottostima i tuoi ricavi chiusi. Una trattativa in cui la proposta ha generato un errore ma appare ancora come "Proposal Sent" sovrastima la tua pipeline. Entrambe le situazioni sono problematiche.
La soluzione non è più disciplina o un altro reminder su Slack. Non riuscirai mai ad abituare le persone ad aggiornare un campo del CRM ogni volta che si verifica un evento esterno. La soluzione è eliminare completamente il passaggio manuale e lasciare che sia l'evento stesso a innescare l'aggiornamento.
Il ciclo di vita del documento come segnale di pipeline
Quando utilizzi Portant con HubSpot, Portant salva ogni documento che generi come un record indipendente (un Custom Object) sull'affare. Quel record contiene una proprietà chiamata Document Status, che si aggiorna automaticamente man mano che il documento avanza nel suo ciclo di vita.
Questo è il segnale di cui ha bisogno la tua pipeline. Invece di chiedere ai tuoi rappresentanti di monitorare la posta in arrivo e poi aggiornare HubSpot manualmente, la proprietà Document Status cambia da sola quando succede qualcosa di concreto. Un documento viene inviato. Viene richiesta una firma. Il documento viene firmato. Qualcosa va storto. Ognuno di questi cambiamenti di stato corrisponde a un momento reale nel processo di vendita, il che significa che ognuno può essere mappato direttamente a una fase del deal.
Sembra che il testo sia incompleto. Potresti fornire il testo completo da tradurre? come allineare le fasi della trattativa con i tipi di documento questo copre la mappatura concettuale tra le fasi e i documenti. Questo articolo va un passo oltre. Automatizza quell'allineamento in modo che la pipeline si aggiorni da sola.
Portant Valori di stato del documento
Il Document Object di Portant tiene traccia di nove valori di stato. Ecco cosa significa ciascuno e quando si applica.
- In attesa: Portant ha creato il record del documento, ma la generazione non è ancora iniziata.
- Bozza: Portant ha generato il documento, ma è ancora in bozza, non ancora definitivo.
- Approvato: Il tuo team ha revisionato e approvato il documento internamente. Questo si applica se utilizzi Portant's flussi di approvazione.
- Inviato: Portant ha consegnato il documento al destinatario.
- Firma Richiesta: Portant ha inviato una richiesta di firma elettronica al firmatario o ai firmatari.
- Parzialmente Firmato: Almeno un firmatario ha completato la propria firma, ma altri devono ancora farlo.
- Firmato: Tutti i firmatari hanno completato le loro firme.
- Completato: Il ciclo di vita del documento è completato, inclusi eventuali passaggi successivi alla firma.
- Errore: Qualcosa è andato storto durante la generazione, l'invio o la firma.
Non ogni trattativa passerà attraverso tutti e nove gli stati. Un preventivo semplice potrebbe passare direttamente da In attesa a Inviato senza necessità di una firma. Un contratto potrebbe passare attraverso Inviato, Firma richiesta, Parzialmente firmato, Firmato e Completato. I flussi di lavoro che costruisci dovrebbero tenere conto degli stati che contano davvero nel tuo processo.
Per tutti i dettagli su come funzionano queste proprietà, consulta il Documentazione Portant sull'attivazione dei workflow HubSpot dalle modifiche allo stato del documento.
Costruzione dei workflow
La configurazione utilizza lo strumento workflow standard di HubSpot. Creerai workflow basati sui deal che si attivano in base alle modifiche alla proprietà Document Status sull'oggetto Portant Document associato.
Ecco la mappatura principale che consiglio per la maggior parte dei processi di vendita.
Workflow 1: Documento Inviato → Sposta in "Proposal Sent"
- Vai su Automation > Workflows in HubSpot.
- Crea un nuovo workflow basato sulle trattative.
- Imposta il trigger di iscrizione su: Associated Portant Document Object > Document Status è "Sent."
- Aggiungi un'azione: Imposta proprietà deal > Deal Stage su "Proposal Sent" (o qualunque fase equivalente tu abbia).
- Salva e attiva.
Quando Portant invia una proposta o un preventivo all'acquirente, lo stato del documento cambia in "Sent." Questo workflow rileva tale cambiamento e fa avanzare l'affare automaticamente.
Workflow 2: Firma Richiesta → Sposta in "Contratto Inviato"
Stessa struttura, trigger diverso.
- Trigger di iscrizione: Lo stato del documento è "Firma Richiesta."
- Azione: Imposta la fase del deal su "Contract Sent."
Questo copre il momento in cui il processo di firma ha inizio. L'acquirente ha ricevuto il documento con una richiesta di firma elettronica e la fase della trattativa dovrebbe riflettere questo.
Workflow 3: Firmato o Completato → Sposta in "Closed Won"
- Trigger di iscrizione: lo stato del documento è "Signed" OR "Completed."
- Azione: Imposta la fase del deal su "Closed Won."
Puoi usare "Signed" o "Completed" a seconda di come funziona il tuo processo. Se hai bisogno che tutte le fasi successive alla firma vengano completate prima di chiudere il contratto, attiva il trigger su "Completed." Se la firma finale è il tuo evento di chiusura, attiva il trigger su "Signed."
Workflow 4: Errore → Notifica il responsabile del deal
- Trigger di iscrizione: lo stato del documento è "Errore."
- Azione: Invia una notifica interna al proprietario del deal con un messaggio come: "Un documento relativo a [Deal Name] contiene un errore. Controlla il documento e invialo di nuovo se necessario."
Questo è importante perché gli stati di errore sono invisibili senza un avviso. Un rappresentante potrebbe non accorgersi che un contratto non è stato generato o che una richiesta di firma è stata respinta. Una notifica immediata impedisce che le trattative si blocchino in silenzio.
Alternativa: un workflow con rami
Se preferisci gestire meno workflow, puoi creare un singolo workflow basato sui deal con un ramo If/Then che controlla il valore di Document Status e indirizza all'azione appropriata. La logica è identica, cambia solo l'organizzazione. Di solito parto con workflow separati perché sono più facili da analizzare e correggere, per poi consolidarli in seguito se il team vuole una vista più ordinata.
Aggiunta di tag per le trattative per la visibilità della pipeline
I tag delle trattative sono etichette con codice colore che appaiono sulle schede delle trattative nella visualizzazione a schede di HubSpot. Forniscono ai rappresentanti e ai manager un rapido indicatore visivo durante la scansione della pipeline, senza dover aprire ogni singola trattativa.
Portant ti permette di aggiungere tag alle trattative in base allo stato del documento, così la tua bacheca pipeline mostra a colpo d'occhio a che punto si trova ogni trattativa nel ciclo di vita del documento. Ad esempio:
- Un tag verde per le trattative "Firmate"
- Un tag giallo per le trattative "Firma Richiesta"
- Tag rosso per le trattative con "Errore"
- Un tag blu per i deal "Inviati"
Questo è particolarmente utile nelle revisioni della pipeline. Invece di cliccare su ogni trattativa per verificare l'avanzamento dei documenti, i manager possono scorrere la board e individuare immediatamente le trattative che richiedono attenzione, che si tratti di una firma bloccata o di un errore che è passato inosservato.
Per le istruzioni di configurazione, consulta il Guida Portant per aggiungere tag alle trattative utilizzando gli stati dei documenti.
Casi limite da considerare
Nessuna automazione funziona alla perfezione fin dal primo giorno. Ecco le situazioni in cui vedo i team andare in difficoltà, e come gestirle.
Più documenti per deal
Un singolo deal può avere un preventivo, una proposta e un contratto, ciascuno con il proprio Document Status. Se il preventivo è "Completed" ma il contratto è "Pending," quale stato deve guidare la fase del deal?
La mia raccomandazione: usa lo stato del documento più recente come segnale principale. Nell'iscrizione al workflow, puoi filtrare per template o nome del documento se utilizzi convenzioni di denominazione coerenti. Richiede qualche test, ma farlo bene evita che un preventivo completato chiuda il deal prematuramente quando il contratto non è ancora stato inviato.
Proposte reinviate
Se un rappresentante reinvia una proposta perché il cliente ha richiesto modifiche, il Document Status scorrerà di nuovo attraverso i suoi valori. Il tuo workflow dovrebbe gestire la re-iscrizione in modo che la fase del deal si aggiorni correttamente quando un nuovo stato "Sent" compare su un documento diverso.
Tieni presente che questo può far arretrare un deal nella pipeline. Se viene inviata una nuova proposta dopo che un contratto era già in corso, il deal potrebbe tornare a "Proposal Sent." Valuta se i tuoi workflow debbano spostare le fasi solo in avanti e mai indietro. Per la maggior parte dei team, consiglio una logica solo-in-avanti, con un workflow separato e deliberato per qualsiasi movimento in senso contrario.
Stati di errore
Un errore non significa che il deal è perso. Significa che qualcosa è andato storto a livello tecnico, come un errore di merge del template o un timeout del servizio di firma. Il workflow di notifica nel Workflow 4 è la tua rete di sicurezza in questi casi. Assicurati che la notifica includa abbastanza contesto affinché il rappresentante possa agire: il nome del deal, il nome del documento e un rimando a verificare lo stato in Portant.
Documenti parzialmente firmati
Per i contratti con più firmatari, "Partially Signed" è uno stato intermedio utile. Non hai necessariamente bisogno di una fase del deal separata, ma un tag sul deal come "In attesa di firme" aiuta i manager a tenere traccia dei contratti in corso rispetto a quelli bloccati in attesa di un firmatario specifico.
Cosa cambia nei report sulla pipeline
Quando le fasi del deal si aggiornano automaticamente in base a eventi reali sui documenti, tre aspetti migliorano.
Accuratezza delle previsioni. Le fasi riflettono ciò che è accaduto davvero, non ciò che un rappresentante si è ricordato di registrare. Se il tuo modello di previsione utilizza le probabilità per fase, quelle probabilità sono ora basate sulla realtà invece che su una stima del venerdì scorso durante la pulizia dei dati.
Velocità della pipeline. Le metriche di tempo per fase diventano significative. Puoi misurare quanto tempo occorre davvero per passare da "Proposal Sent" a "Contract Sent" perché entrambe le transizioni sono legate a eventi sui documenti, non a clic manuali. Questo ti fornisce dati reali su dove i deal rallentano.
Igiene della pipeline. I deal obsoleti diventano più facili da individuare. Se un deal è in "Contract Sent" da due settimane e il Document Status mostra ancora "Signature Requested," il problema è nel deal, non nei dati. I manager possono concentrare le revisioni della pipeline sul coaching invece che sulla verifica dell'inserimento dei dati.
Lo configuri una volta sola, e ogni deal che scorre nella pipeline ottiene una fase più accurata senza che nessuno debba pensarci.
Come iniziare
Se stai già usando Portant con HubSpot, la proprietà Document Status è già presente nei tuoi record documento. Inizia con i quattro workflow principali che ho descritto sopra. Testali su una manciata di deal prima di distribuirli all'intero team.
Se vuoi approfondire come fasi e documenti dovrebbero connettersi concettualmente, leggi il mio articolo precedente sulla mappatura delle fasi del deal ai tipi di documento.
E se non stai ancora usando Portant, la pagina di integrazione con HubSpot spiega cosa fa e come configurarlo.
Domande frequenti
Funziona con qualsiasi pipeline di deal in HubSpot?
Sì. I workflow si attivano sulla proprietà Document Status degli Portant Document Objects associati, che non è legata a una pipeline specifica. Puoi impostare mappature di fasi diverse per pipeline diverse utilizzando i rami del workflow.
E se le mie fasi del deal non corrispondono agli esempi?
La mappatura è completamente flessibile. Gli esempi che ho usato ("Proposal Sent," "Contract Sent," "Closed Won") sono etichette comuni, ma dovresti mappare le modifiche al Document Status sulle fasi che la tua pipeline utilizza effettivamente. L'importante è che ogni cambio di stato corrisponda a una transizione di fase significativa per il tuo processo.
Questo sovrascriverà le modifiche manuali alle fasi?
Dipende da come configuri i workflow. Se un rappresentante sposta manualmente un deal su "Closed Won" prima che il documento sia firmato, il workflow non lo ripristinerà a meno che tu non lo abbia impostato espressamente per farlo. Consiglio di creare workflow che spostino le fasi solo in avanti. Se hai bisogno di movimenti in senso contrario, aggiungili come workflow separato con salvaguardie aggiuntive e una documentazione chiara per il team.
Posso usarlo anche con i workflow di approvazione?
Sì. Se il tuo team usa il workflow di approvazione di Portant, il Document Status si aggiorna a "Approved" dopo la revisione interna. Puoi aggiungere un workflow che sposti il deal a una fase come "Pending Send" o "Ready for Buyer" quando ciò accade. È utile per i team che hanno bisogno dell'approvazione del manager prima che qualsiasi proposta venga inviata a un cliente.
