Hoe ontwerp je een CRM? Zo organiseer je jouw data in HubSpot

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:

• waar gegevens vandaan komen;
• welke property leidend is;
• waarom dezelfde informatie op drie plekken staat;
• welke automatisering welke data overschrijft.

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.

Een CRM is eigenlijk een database

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:

• Contactpersonen
• Bedrijven
• Deals
• Producten
• Tickets
• Contracten
• Marketingcampagnes
• Custom Objects

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.

Properties: de bouwstenen van elk object

Elk object bestaat vervolgens uit eigenschappen. In HubSpot heten deze Properties. In het Nederlands kun je deze vergelijken met velden.

Bijvoorbeeld:

Contact

• Voornaam
• Achternaam
• E-mailadres
• Telefoonnummer

Bedrijf

• Bedrijfsnaam
• Branche
• KvK-nummer
• Website

Contract

• Contractnummer
• Startdatum
• Einddatum
• Contractwaarde

Properties zijn niets anders dan de individuele stukjes data waaruit een object bestaat. Samen vormen ze de informatie waarop je CRM draait.

Objecten bestaan niet los van elkaar

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.

Welke relaties bestaan er?

Er bestaan drie veelgebruikte relatievormen.

1. One-to-One (1:1)

Een object hoort precies bij één ander object.

Bijvoorbeeld:

• één abonnement heeft één serienummer.

2. One-to-Many (1:N)

Dit is veruit de meest voorkomende relatie.

Bijvoorbeeld:

• één bedrijf heeft meerdere contactpersonen;
• één bedrijf heeft meerdere contracten;
• één contract bevat meerdere producten.

3. Many-to-Many (N:N)

Hier kunnen beide kanten meerdere relaties hebben.

Bijvoorbeeld:

• één marketingcampagne promoot meerdere producten;
• één product komt terug in meerdere campagnes.

Deze relaties bepalen uiteindelijk hoe je CRM functioneert.

Denk na over de Source of Truth

Een van de grootste fouten die organisaties maken, is dezelfde informatie op meerdere plekken opslaan.

Bijvoorbeeld:

Contractwaarde staat op:

• Company
• Deal
• Contract

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:

Vanuit deze bron synchroniseer je eventueel naar andere systemen, maar er is altijd maar één eigenaar van de data.

Waar komt de data vandaan?

Niet alle data ontstaat op dezelfde manier. Vraag jezelf daarom bij iedere property af:

• Wordt deze handmatig ingevuld?
• Komt deze uit een API?
• Komt deze uit een ERP?
• Wordt deze berekend?
• Komt deze uit een formulier?
• Wordt deze door een workflow gevuld?

Leg dit ook vast. Wanneer een API iedere nacht gegevens overschrijft, heeft het immers weinig zin dat medewerkers dezelfde property handmatig aanpassen.

Niet alles hoeft een property te zijn

Nog een veelgemaakte fout: organisaties maken van iedere gebeurtenis een property. Terwijl sommige informatie helemaal geen vaste eigenschap is, maar een gebeurtenis.

Bijvoorbeeld:

• e-mail geopend;
• website bezocht;
• formulier ingevuld;
• contract ondertekend;
• webinar bijgewoond.

Dit zijn geen eigenschappen van een contactpersoon. Dit zijn gebeurtenissen.

HubSpot kent hiervoor onder andere:

• Timeline Events
• Custom Events

Events vertellen wat er is gebeurd. Properties vertellen wat iets op dit moment is. Dat verschil is ontzettend belangrijk voor een schaalbaar CRM.

Teken eerst een ERD

Voordat je HubSpot gaat inrichten, zou ik altijd eerst een Entity Relationship Diagram (ERD) maken.

Hierin teken je:

• alle objecten;
• alle relaties;
• cardinaliteit (1:1, 1:N of N:N);
• de Source of Truth;
• welke systemen eigenaar zijn van welke data.

Pas daarna ga je HubSpot configureren. Niet andersom.

Governance: wie mag wat aanpassen?

Een CRM groeit. Er komen nieuwe collega's, nieuwe processen en nieuwe integraties. Zonder duidelijke afspraken ontstaat vanzelf chaos.

Leg daarom vast:

• wie properties mag aanmaken;
• wie objecten mag wijzigen;
• wie eigenaar is van ieder object;
• hoe wijzigingen worden aangevraagd;
• hoe naming conventions eruitzien;
• wanneer een property verwijderd mag worden.

Zo voorkom je dat je CRM na een paar jaar nauwelijks nog beheersbaar is.

Zie HubSpot als het fundament van je organisatie

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:

• worden automatiseringen eenvoudiger;
• worden rapportages betrouwbaarder;
• werken AI-oplossingen beter;
• voorkom je dubbele data;
• groeit je CRM mee met je organisatie.

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.

De meestgestelde vragen

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.