Geautomatiseerde documenten zijn alleen zo goed als de CRM-velden erachter. Ik breng veel tijd door met HubSpot-admins die offertes en contracten willen die "gewoon werken." In bijna elk geval is de blokkade niet de template. Het zijn inconsistente properties, dubbele velden, en het ontbreken van consensus over welke waarde de bron van waarheid is.

Dit is de checklist die ik gebruik als ik wil dat HubSpot -data netjes doorstroomt naar door Portant gegenereerde offertes, voorstellen en contracten. Het doel is eenvoudig: één canoniek veld per gegeven, met een naam die reps begrijpen, en gevalideerd zodat slechte data niet ongemerkt een klant-pdf kan bereiken.

Voor het volledige overzicht van hoe documentgeneratie, samenvoegen van data en eSignature samenwerken in HubSpot, zie de complete gids voor documentautomatisering in HubSpot.

Begin met wat het document moet zeggen

Voordat ik HubSpot-instellingen aanraak, maak ik een lijst van de gegevens die op een ondertekende overeenkomst of een formeel voorstel moeten staan. Juridische naam, factuuradres, ondertekenaar, commerciële voorwaarden, startdatums en regelitems zijn de gebruikelijke verdachten. Intern jargon laat ik buiten beschouwing totdat de klantgerichte lijst helder is.

Vervolgens koppel ik elk gegeven aan een bestaand HubSpot-object. Company bevat entiteits- en facturatiegegevens. Contact bevat personen en rollen. Deal bevat de commerciële structuur en fase. Line items bevatten de berekeningen op SKU-niveau. Aangepaste objecten horen thuis waar relaties daadwerkelijk bestaan, niet waar we geen ruimte meer hadden op de deal.

Als die mapping klopt, kan Portant live waarden ophalen voor voorstellen en contracten zonder dat reps cellen uit spreadsheets hoeven te kopiëren. Als de mapping onduidelijk is, schaalt automatisering fouten alleen maar sneller op.

Naamgeving en groepen die reps echt gebruiken

Ik groepeer properties in HubSpot zodat een rep die documenten voorbereidt één blok ziet met het label "Contractbasisgegevens" of "Invoer voorstel", in plaats van vijftig verspreid staande velden. Namen zijn in begrijpelijke taal: "Juridische naam entiteit" is beter dan "co_legal_nm." Helptekst bestaat uit één zin: waar de waarde vandaan komt en wie het oplost als die onjuist is.

Ik vermijd bijna-dubbele velden. Niets brengt teams sneller in verwarring dan "Jaarlijkse contractwaarde" op de deal én "ACV kopie" in een spreadsheetkolom die niemand beheert. Als twee velden met elkaar in tegenspraak kunnen zijn, verwijder ik er één of maak ik er één berekend en alleen-lezen.

Voor keuzelijsten en dropdowns houd ik opties kort en wederzijds uitsluitend. Vrije tekst is prima voor nuance, maar niet voor zaken die prijstabellen of jurisdictieclausules aansturen. Die horen thuis in gecontroleerde woordenlijsten zodat templates voorspelbaar kunnen vertakken.

Verplichte velden moeten overeenkomen met echte drempelwaarden. Als een contract niet kan worden verstuurd zonder een inkooporderregel, zorg dan dat dit zichtbaar is vóór "contract verzonden", niet nadat finance de pdf heeft afgewezen. Ik gebruik verplichte properties op de deal of het bedrijf bij de fase waarin het team zich committeert aan die voorwaarden.

Waar HubSpot het toelaat, voeg ik eenvoudige waarborgen toe: getalformaten voor bedragen, e-mailvalidatie voor ondertekenaars, en minimale lengtes waar lege waarden eerder problemen hebben veroorzaakt. Het gaat niet om bureaucratie. Het gaat erom die ene foutieve waarde te voorkomen die uitmondt in een nachtmerrie vol opmerkingen en wijzigingen.

Wanneer documentautomatisering op basis van deze velden wordt uitgevoerd, worden goedkeuringen korter omdat reviewers de invoer vertrouwen. Dat is de praktische opbrengst van strak property-ontwerp.

Aangepaste properties versus het overbelasten van standaardvelden

HubSpot biedt standaard properties om goede redenen. Ik gebruik ze wanneer de semantiek overeenkomt. Ik voeg aangepaste properties toe wanneer we een specifiek bedrijfsconcept hebben, zoals "Ingangsdatum MSA" of "Opzegtermijn automatische verlenging", dat nooit in een algemeen notitienveld mag worden gestopt.

Ik let ook op "misbruik van het notitienveld", waarbij cruciale voorwaarden alleen in dealnotities staan. Notities horen niet in klantdocumenten zonder menselijke vertaling, waardoor kopiëren en plakken opnieuw wordt geïntroduceerd. Als iets op papier hoort, hoort het in een gestructureerde property.

Voor teams die workflows gebruiken om bestanden te genereren bij een fasewijziging, zijn gestructureerde velden wat conditionele secties betrouwbaar maakt. "Als verlengingstermijn gelijk is aan 12 maanden, neem clausuleblok A op" werkt alleen als verlengingstermijn een echt veld is.

Rapportage die bewijst dat de data gezond is

Ik bouw een kleine set lijsten en rapporten die één vraag beantwoorden: kunnen we voor elke deal in deze fase een schoon document genereren? Het rapport filtert op ontbrekende verplichte properties, ongeldige keuzelijstwaarden en deals met regelitems die niet optellen tot het dealsbedrag.

RevOps bekijkt die lijst in het begin wekelijks, daarna maandelijks wanneer de foutpercentages stabiel worden. Sales leaders zien hem ook, omdat de oplossing vaak coaching is en geen extra integratie.

Gezonde properties maken betrokkenheidsstatistieken ook zinvol. Wanneer documentrecords in HubSpot het juiste account en de juiste contactpersoon weerspiegelen, weet je wie wat heeft geopend en wanneer.

Overdracht aan template-eigenaren

Zodra properties stabiel zijn, maak ik een "veldwoordenboek" van één pagina voor degene die Google Docs- of Word-templates beheert. Elke tag verwijst naar een HubSpot-property, het object waarop die staat en een voorbeeldwaarde. Template-editors mogen nooit hoeven raden of "factuurstad" afkomstig is van het bedrijf of de contactpersoon.

In Portant halen die tags live HubSpot-data op, zodat gegenereerde bestanden gesynchroniseerd blijven wanneer records worden bijgewerkt. Het patroon dat ik prefereer is: eerst CRM-discipline, dan template-verfijning, dan automatisering.

Veelgestelde vragen

Hoeveel aangepaste properties is te veel?

Als reps de velden die ze nodig hebben niet kunnen vinden zonder te zoeken, heb je er te veel in de standaardweergave. Je kunt een groter totaal aantal bijhouden zolang slimme weergaven, formulieren en playbooks de juiste subset per rol tonen. Ik geef de voorkeur aan minder velden met stricter gebruik boven eindeloze optionele rommel.

Moeten line items de bron van waarheid zijn voor prijzen?

Voor alles op SKU-basis: ja. Het dealsbedrag moet overeenkomen met de line items, anders heb je een gedocumenteerd uitzonderingsproces nodig. Documenttemplates moeten line items uitlezen wanneer tabellen gespecificeerd zijn, en velden op dealniveau wanneer je een gebundeld pakket verkoopt met één totaalprijs.

Wat als sales erop staat om vrije tekst te gebruiken voor voorwaarden?

Leg gestructureerde markeringen vast voor wat juridisch en financieel van belang is, en gebruik een lang tekstveld voor beschrijvende tekst als dat nodig is. Leg het team vervolgens uit welke onderdelen samengevoegd kunnen worden met data en welke juridische review vereisen. Ongestructureerde tekst mag nooit de enige plek zijn voor verlengingstermijnen of aansprakelijkheidsgrenzen.