I documenti automatizzati valgono solo quanto i campi CRM che li alimentano. Passo molto tempo con gli amministratori HubSpot che vogliono proposte e contratti che "funzionino e basta." Nella quasi totalità dei casi, il problema non è il modello. Sono le proprietà incoerenti, i campi duplicati e il fatto che nessuno si mette d'accordo su quale valore sia la fonte di verità.

Questa è la checklist che uso quando voglio che i dati HubSpot confluiscano in modo pulito nei preventivi, nelle proposte e nei contratti generati da Portant. L'obiettivo è semplice: un campo canonico per ogni dato, denominato in modo che i rappresentanti lo capiscano, e validato affinché i dati errati non raggiungano silenziosamente un PDF destinato al cliente.

Per un quadro completo di come la generazione di documenti, l'unione dei dati e la firma elettronica si integrano in HubSpot, consulta la guida completa all'automazione dei documenti in HubSpot.

Parti da ciò che il documento deve comunicare

Prima di toccare le impostazioni di HubSpot, elenco i dati che devono comparire in un accordo firmato o in una proposta formale. Ragione sociale, indirizzo di fatturazione, firmatario, condizioni commerciali, date di inizio e voci di dettaglio sono gli elementi ricorrenti. Ignoro il gergo interno finché non ho chiaro l'elenco rivolto al cliente.

Poi associo ogni dato a un oggetto HubSpot esistente. Company contiene i dati dell'entità e di fatturazione. Contact contiene le persone e i ruoli. Deal contiene la struttura commerciale e la fase. Le voci (line items) contengono la matematica a livello di SKU. Gli oggetti personalizzati vanno dove le relazioni sono reali, non dove abbiamo esaurito lo spazio sul deal.

Quando questa mappatura è precisa, Portant può inserire valori in tempo reale nelle proposte e nei contratti senza che i rappresentanti debbano copiare celle dai fogli di calcolo. Se la mappatura è approssimativa, l'automazione non fa altro che moltiplicare gli errori più velocemente.

Nomi e gruppi che i rappresentanti usano davvero

Raggruppo le proprietà in HubSpot in modo che un rappresentante che prepara un documento veda un unico blocco etichettato "Elementi essenziali del contratto" o "Input per la proposta", non cinquanta campi sparsi. I nomi si leggono in modo semplice e diretto: "Nome legale dell'entità" è molto meglio di "co_legal_nm." Il testo di aiuto è di una sola frase: da dove proviene il valore e chi lo corregge in caso di errore.

Evito i campi quasi duplicati. Niente confonde i team più velocemente di "Valore annuo del contratto" nel deal e "Copia ACV" in una colonna di un foglio di calcolo che nessuno gestisce. Se due campi possono essere in disaccordo, ne elimino uno o lo rendo calcolato e di sola lettura.

Per le liste di selezione e i menu a tendina, mantengo le opzioni brevi e mutualmente esclusive. Il testo libero va bene per le sfumature, ma non per gli elementi che alimentano tabelle di prezzi o clausole di giurisdizione. Quelli devono rientrare in vocabolari controllati, così i modelli possono ramificarsi in modo prevedibile.

I campi obbligatori devono corrispondere a veri punti di controllo. Se un contratto non può essere inviato senza una regola sull'ordine di acquisto, rendila visibile prima di "contratto inviato", non dopo che il team finanziario ha rifiutato il PDF. Uso le proprietà obbligatorie sul deal o sulla company nella fase in cui il team si impegna su quelle condizioni.

Dove HubSpot lo consente, aggiungo semplici controlli: formati numerici per gli importi, validazione delle email sui firmatari, lunghezze minime dove i valori vuoti hanno già causato problemi in passato. L'obiettivo non è la burocrazia. L'obiettivo è bloccare quel singolo valore errato che si trasforma in un incubo di revisioni e controproposte.

Quando l'automazione dei documenti si basa su questi campi, le approvazioni si accorciano perché i revisori si fidano degli input. Questo è il vantaggio pratico di una progettazione rigorosa delle proprietà.

Proprietà personalizzate o sovraccarico dei campi standard

HubSpot offre proprietà standard per buone ragioni. Le uso quando la semantica corrisponde. Aggiungo proprietà personalizzate quando abbiamo un concetto di business specifico, come "Data di efficacia del MSA" o "Finestra di preavviso per il rinnovo automatico", che non deve mai essere inserito in un campo note generico.

Monitoro anche l'"abuso del campo note", ovvero quando termini critici vivono solo nelle note del deal. Le note non appartengono ai documenti destinati al cliente senza una traduzione umana, il che reintroduce il copia-incolla. Se un dato deve comparire su carta, deve stare in una proprietà strutturata.

Per i team che usano i workflow per generare file al cambio di fase, i campi strutturati sono ciò che rende affidabili le sezioni condizionali. "Se il termine di rinnovo è uguale a 12 mesi, includi il blocco clausola A" funziona solo quando il termine di rinnovo è un campo reale.

Report che dimostrano la salute dei dati

Costruisco un piccolo set di liste e report che rispondono a una sola domanda: possiamo generare un documento pulito per ogni deal in questa fase? Il report filtra le proprietà obbligatorie mancanti, i valori di lista non validi e i deal con voci il cui totale non corrisponde all'importo del deal.

RevOps esamina quella lista settimanalmente all'inizio, poi mensilmente quando il tasso di errore si stabilizza. Anche i responsabili delle vendite la consultano, perché spesso la soluzione è la formazione, non un'altra integrazione.

Proprietà in buona salute rendono significative anche le metriche di coinvolgimento. Quando i record dei documenti in HubSpot riflettono l'account e il contatto corretti, puoi fidarti di chi ha aperto cosa e quando.

Passaggio ai responsabili dei modelli

Una volta che le proprietà sono stabili, documento un "dizionario dei campi" di una pagina per chi gestisce i modelli Google Docs o Word. Ogni tag è associato a una proprietà HubSpot, all'oggetto in cui si trova e a un valore di esempio. Chi modifica i modelli non deve mai dover indovinare se "città di fatturazione" proviene dalla company o dal contact.

In Portant, quei tag recuperano i dati HubSpot in tempo reale, così i file generati rimangono sincronizzati quando i record vengono aggiornati. Il metodo che preferisco è: prima la disciplina CRM, poi la cura del modello, poi l'automazione.

Domande frequenti

Quante proprietà personalizzate sono troppe?

Se i rappresentanti non riescono a trovare i campi di cui hanno bisogno senza cercarli, ne hai troppe nella visualizzazione predefinita. Puoi mantenere un numero totale più elevato, a patto che le visualizzazioni intelligenti, i moduli e i playbook mostrino il sottoinsieme corretto per ogni ruolo. Preferisco meno campi con un utilizzo più rigoroso rispetto a un'infinità di opzioni facoltative disorganizzate.

Le voci (line items) devono essere la fonte di verità per i prezzi?

Per tutto ciò che è basato su SKU, sì. L'importo del deal deve coincidere con le voci oppure è necessario un processo documentato per le eccezioni. I modelli di documento devono leggere dalle voci quando le tabelle sono dettagliate, e dai campi a livello di deal quando vendi un pacchetto con un unico totale.

E se il team vendite insiste sul testo libero per le condizioni?

Acquisisci flag strutturati per gli elementi rilevanti dal punto di vista legale e finanziario, e usa un campo di testo lungo per la parte narrativa se necessario. Poi insegna al team quali elementi possono essere uniti tramite data merge e quali richiedono una revisione legale. Il testo non strutturato non deve mai essere l'unico contenitore per la durata del rinnovo o i massimali di responsabilità.