Iedereen heeft het over workflows, AI, lead scoring en automatiseringen. Maar bijna niemand praat over de fundering waarop dit allemaal draait. Want voordat je ook maar één workflow bouwt, één dashboard maakt of één marketingcampagne live zet, moet je eerst weten hoe jouw data in elkaar zit. En precies daar gaat het bij veel organisaties mis.
Ze beginnen met HubSpot inrichten, maken een paar properties aan, bouwen wat workflows en voegen steeds meer data toe. Na een jaar weet niemand meer:
Het resultaat? Een CRM dat steeds moeilijker te onderhouden wordt.
In deze blog laat ik zien hoe je een CRM opzet zoals softwarearchitecten dat doen: door eerst je datamodel te ontwerpen.
Veel mensen zien HubSpot als een marketing- of salestool. Technisch gezien is dat niet helemaal waar. HubSpot is in de basis een database waarin verschillende soorten gegevens worden opgeslagen die onderling met elkaar verbonden zijn.
Denk bijvoorbeeld aan:
Binnen HubSpot worden deze Objects genoemd.
Een object kun je zien als een verzameling van één bepaald type informatie. Een contactpersoon bevat persoonsgegevens, een bedrijf bevat bedrijfsinformatie, een product bevat productgegevens en een contract bevat contractinformatie.
Elk object bestaat vervolgens uit eigenschappen. In HubSpot heten deze Properties. In het Nederlands kun je deze vergelijken met velden.
Bijvoorbeeld:
Properties zijn niets anders dan de individuele stukjes data waaruit een object bestaat. Samen vormen ze de informatie waarop je CRM draait.
Nu wordt het interessant. Vrijwel geen enkel object staat op zichzelf. Een contactpersoon werkt bijvoorbeeld bij een bedrijf, een bedrijf heeft contracten, een contract bevat producten en een deal wordt gesloten door een contactpersoon.
Deze relaties moet je vooraf bepalen. Binnen HubSpot noemen we dit Associaties. Zij bepalen uiteindelijk hoe je kunt rapporteren, automatiseren, segmenteren en processen kunt ondersteunen.
Er bestaan drie veelgebruikte relatievormen.
Een object hoort precies bij één ander object.
Bijvoorbeeld:
Dit is veruit de meest voorkomende relatie.
Bijvoorbeeld:
Hier kunnen beide kanten meerdere relaties hebben.
Bijvoorbeeld:
Deze relaties bepalen uiteindelijk hoe je CRM functioneert.
Een van de grootste fouten die organisaties maken, is dezelfde informatie op meerdere plekken opslaan.
Bijvoorbeeld:
Contractwaarde staat op:
Welke is dan leidend?
Niemand weet het.
Daarom bepaal je vooraf de Source of Truth. Voor iedere eigenschap stel je jezelf één vraag:
Waar hoort deze informatie oorspronkelijk thuis?
Bijvoorbeeld:
| Gegeven | Source of Truth |
|---|---|
| Contractwaarde | Contract |
| Bedrijfsnaam | Bedrijf |
| Voornaam | Contact |
| SKU | Product |
| Omzet | ERP |
Vanuit deze bron synchroniseer je eventueel naar andere systemen, maar er is altijd maar één eigenaar van de data.
Niet alle data ontstaat op dezelfde manier. Vraag jezelf daarom bij iedere property af:
Leg dit ook vast. Wanneer een API iedere nacht gegevens overschrijft, heeft het immers weinig zin dat medewerkers dezelfde property handmatig aanpassen.
Nog een veelgemaakte fout: organisaties maken van iedere gebeurtenis een property. Terwijl sommige informatie helemaal geen vaste eigenschap is, maar een gebeurtenis.
Bijvoorbeeld:
Dit zijn geen eigenschappen van een contactpersoon. Dit zijn gebeurtenissen.
HubSpot kent hiervoor onder andere:
Events vertellen wat er is gebeurd. Properties vertellen wat iets op dit moment is. Dat verschil is ontzettend belangrijk voor een schaalbaar CRM.
Voordat je HubSpot gaat inrichten, zou ik altijd eerst een Entity Relationship Diagram (ERD) maken.
Hierin teken je:
Pas daarna ga je HubSpot configureren. Niet andersom.
Een CRM groeit. Er komen nieuwe collega's, nieuwe processen en nieuwe integraties. Zonder duidelijke afspraken ontstaat vanzelf chaos.
Leg daarom vast:
Zo voorkom je dat je CRM na een paar jaar nauwelijks nog beheersbaar is.
Veel bedrijven zien HubSpot als een marketingtool. In werkelijkheid is het veel meer dan dat. Je CRM is de digitale weergave van je organisatie. Hier komen sales, marketing, operations, finance en klantenservice samen.
Als de datastructuur klopt:
Investeer daarom niet als eerste in workflows. Investeer eerst in je datamodel. Een goed ontworpen CRM is namelijk geen verzameling properties, maar de blauwdruk van hoe jouw organisatie werkt.
Van objecten en properties tot events en ERD's. Hieronder vind je de antwoorden op de vragen die marketeers en CRM-specialisten het vaakst stellen.