Lead-to-account matching (L2A) is de geautomatiseerde stap die elke nieuwe lead in je CRM koppelt aan het bedrijfsrecord waar hij bij hoort, op basis van het e-maildomein, de website en de bedrijfsnaam van de lead. Zodra de match er is, draagt de lead alles mee wat je al over dat bedrijf weet: wie de eigenaar is, of er een lopende deal is en wie daar nog meer met je in gesprek is.

Zonder die stap behandelt een CRM elk ingevuld formulier als een onbekende. Een inkoopmanager van een bedrijf waarmee je AE al twee maanden onderhandelt, kan als gloednieuwe lead in de wachtrij van de SDR belanden en een koude eerste e-mail krijgen die de hele relatie negeert. De koper merkt dat, en de AE ook, meestal achteraf.

De stap klinkt mechanisch, en grotendeels is hij dat ook. Het lastige zit in de randgevallen: privé-e-mailadressen, regionale subdomeinen, dochterbedrijven die het domein van het moederbedrijf delen en bedrijfsnamen die op zes verschillende manieren zijn getypt. Die bepalen of de match klopt, en een verkeerde match richt meer schade aan dan helemaal geen match.

TL;DR

• Een match geeft de lead de eigenaar, de fase, de lopende deals en de betrokken collega's van het account mee. Zo wordt hij afgehandeld als onderdeel van een relatie, en niet als koud contact.

• Zet je matchingregels op volgorde van zekerheid: eerst het e-maildomein, dan bekende alternatieve domeinen, dan het websiteveld bij leads met een freemailadres en daarna de genormaliseerde bedrijfsnaam. Fuzzy matches op naam gaan naar iemand die ze controleert, en worden nooit automatisch gekoppeld of samengevoegd.

• Groepen en dochterbedrijven hebben een vastgelegde regel nodig. Match de lead aan de werkmaatschappij die de relatie heeft, en tel activiteit op bij het moederbedrijf via een parent-child-koppeling, in plaats van één gedeeld domein te laten beslissen.

• HubSpot koppelt contacten op e-maildomein aan bedrijven, maar maakt voor elk subdomein een apart bedrijf aan, en als meerdere bedrijven een domein delen, koppelt het het contact aan maar één ervan. Salesforce houdt leads gescheiden van accounts tot de conversie, en op dat moment kiest de rep het bestaande account met de hand.

• Ontbrekende of verkeerde matches zie je terug als leads die bij de verkeerde eigenaar belanden, dubbele bedrijfsrecords, koude pitches midden in lopende deals en account-based plays die nooit afgaan.

• Nebor bouwt de matchingregels, de lijst met freemaildomeinen en de reviewwachtrij in het CRM van de klant, welk systeem dat ook is, meestal met Clay voor de lookups, en legt elke regel vast voor het team dat het daarna onderhoudt.

Wat een gematchte lead weet en een kaal ingevuld formulier niet

Neem een ingevuld formulier van een facilitair bedrijf in Utrecht dat we Brinkhorst Facility Services noemen. Op zichzelf bevat het nieuwe record een naam, een e-mailadres op brinkhorst.nl, een functietitel en een vrij tekstveld met de bedrijfsnaam. Genoeg voor een nurture-e-mail, en weinig meer.

Gematcht aan het account van Brinkhorst vertelt dezelfde lead een ander verhaal. Het account is van een enterprise-AE, er ligt een voorstel van €120.000 in de onderhandelingsfase, en vier collega's hebben deze maand e-mails geopend of calls bijgewoond. Het nieuwe contact is de vijfde persoon van een bedrijf dat al diep in een koopproces zit, waarschijnlijk iemand van finance of IT bij wie de deal net is aangekomen.

Die context verandert de juiste volgende stap volledig. B2B-aankopen worden gedaan door een buying committee, dus het account is de eenheid die telt, en de individuele lead is één stoel aan tafel. Een gematchte lead gaat met een notitie naar de AE. Een ongematchte lead gaat naar wie er in de rotatie aan de beurt is, en die heeft geen idee dat de deal bestaat.

Regels voor lead-to-account matching, van de meest zekere naar de minst zekere

Elke L2A-setup is een gerangschikte lijst regels. Het systeem probeert eerst de sterkste en valt alleen terug op zwakkere regels als het moet. Dit is de volgorde die wij zouden gebruiken voor een gemiddeld B2B-CRM, met Brinkhorst als voorbeeld.

Een paar details laten de bovenste rijen werken. Domeinen moet je opschonen voordat je ze vergelijkt: alles in kleine letters, "www." eraf en alles weg wat vóór het registreerbare deel van het domein staat. Landextensies maken dat lastiger dan het lijkt, want brinkhorst.co.uk en brinkhorst.com.au hebben allebei een extensie uit twee delen. De meeste codebibliotheken gebruiken de Public Suffix List om het registreerbare domein te vinden, een lijst met extensies zoals com en co.uk waaronder iedereen een naam kan registreren.

Freemailadressen hebben een eigen lijst nodig. Gmail, Outlook en Hotmail liggen voor de hand, maar Nederlandse leads komen ook binnen vanaf adressen van internetproviders, zoals ziggo.nl en kpnmail.nl. Een matcher die die niet kent, maakt vrolijk een bedrijf aan dat Ziggo heet en hangt daar de helft van je inbound aan. Heeft een lead alleen een freemailadres als identifier, verrijk hem dan eerst. Levert dat niets op, zet hem dan in een korte wachtrij of stuur hem naar nurture, en ga niet gokken.

Bij bedrijfsnamen komt fuzzy matching in beeld, en daar richt het de meeste schade aan als het te los staat afgesteld. Normaliseer eerst: haal rechtsvormen zoals B.V., N.V., GmbH en Ltd weg, zet alles in kleine letters, laat leestekens vallen en trek "&" en "en" gelijk. De regels om dat consequent in het hele CRM te doen, lees je bij data normalization. Pas daarna mag een fuzzy vergelijking draaien, en die doet voorstellen zonder zelf te beslissen. "Brinkhorst Facility Services" en "Brinkhorst Bouw" kunnen zusterbedrijven met verschillende eigenaren zijn, of onbekenden die toevallig een achternaam delen.

Fuzzy matches blijven weg van automatische merges om dezelfde reden die door identity resolution heen loopt: een gemiste match laat een gat dat iemand later kan dichten, terwijl een verkeerde match een lead en zijn historie bij de verkeerde rep neerlegt.

Dochterbedrijven, regiokantoren en gedeelde domeinen

De lastigste gevallen ontstaan door bedrijfsstructuren, en veel minder door typfouten. Stel dat Brinkhorst een Belgisch dochterbedrijf heeft, Brinkhorst België NV, met een eigen accountmanager in Antwerpen en een eigen contract. Sommige Belgische medewerkers gebruiken brinkhorst.be, maar velen hebben een adres op brinkhorst.nl, omdat de groep één e-mailsysteem deelt.

Een pure domeinregel stuurt al die Belgische leads naar het Nederlandse account en de Nederlandse eigenaar. Niemand merkt het, tot de accountmanager in Antwerpen van de klant hoort dat er een meeting was. De oplossing is een beslissing die je vooraf vastlegt: leads matchen aan de werkmaatschappij die de relatie heeft, en de groep staat daarboven als parent-account, zodat je de activiteit nog steeds over de hele groep kunt lezen. Kan het domein de twee niet uit elkaar houden, dan beslist een veld dat dat wel kan, zoals het land, de kantoorlocatie of de business unit die de lead op het formulier noemt.

HubSpot modelleert een groep met de standaardlabels Parent company en Child company, waarbij een parent veel children kan hebben en elk child maar één parent. Het primaire bedrijf doet er meer toe dan het lijkt. De documentatie van HubSpot over records koppelen zegt dat activiteiten op de tijdlijn van een contact automatisch alleen aan het primaire bedrijf worden gekoppeld, en dat segmenten, workflows en rapporten over meerdere objecten naar de primaire koppeling verwijzen. Is het primaire bedrijf van een Belgische lead het Nederlandse moederbedrijf, dan behandelt elke workflow die op Company owner draait hem als Nederlandse lead.

Overnames en rebrands veroorzaken hetzelfde probleem vanaf de andere kant. Koopt een klant een concurrent, dan moet het domein van het overgenomen bedrijf als alternatief domein aan het juiste account worden toegevoegd. Anders maakt elke lead van dat domein een nieuw bedrijf aan, of matcht hij met niets.

Hoe HubSpot en Salesforce zelf lead-to-account matching aanpakken

Geen van beide CRM's laat je met lege handen staan, en geen van beide handelt de randgevallen hierboven zonder hulp af.

De HubSpot-instelling Automatically create and associate companies with contacts matcht het domein in het e-mailadres van een contact met het domein van een bedrijf. Bestaat er nog geen bedrijf, dan maakt de instelling er een aan, en dat doet ze voor elk uniek domein, subdomeinen inbegrepen. @example.com en @info.example.com worden dus twee bedrijven. Bij freemailadressen valt ze terug op het websiteveld van het contact. Delen meerdere bedrijven hetzelfde domein, dan wordt het contact aan maar één ervan gekoppeld, en welke dat is, kun je niet kiezen. HubSpot raadt ook af om deze instelling aan te zetten als je de integratie tussen HubSpot en Salesforce gebruikt, omdat dat dubbele bedrijfsrecords kan opleveren.

Daarmee is de ingebouwde matching van HubSpot een goede eerste regel en een slechte laatste. Schone domeinen werken. Subdomeinen, gedeelde groepsdomeinen en duplicaten die al in de database staan, hebben allemaal extra logica nodig, meestal een workflow of een Clay-tabel die alternatieve domeinen en genormaliseerde namen checkt voordat HubSpot iets nieuws aanmaakt. Hetzelfde probleem in de GTM-stack duikt op als andere tools via de API bedrijven in HubSpot schrijven en de domeincheck overslaan.

Salesforce werkt anders, omdat leads en accounts aparte objecten zijn. Een lead is aan geen enkel account gekoppeld tot hij wordt geconverteerd, en de Trailhead-module over leads converteren van Salesforce beschrijft het kiezen van het bestaande account als iets wat de rep doet: werkt de lead voor een bestaand account, dan selecteer je dat account in plaats van een nieuw account aan te maken. Tot dat moment kan het CRM het eigenaarschap van het account niet gebruiken voor routing of rapportage. Duplicate rules en matching rules kunnen reps waarschuwen voor waarschijnlijke duplicaten, maar ze koppelen een lead niet aan zijn account.

Salesforce-teams voegen daarom bijna altijd een eigen L2A-laag toe. Dat kan een flow zijn die accounts op domein opzoekt en een lookupveld op de lead vult, een enrichmentstap in Clay die het ID van het gematchte account terugschrijft, of een aparte app voor matching en routing uit de AppExchange. Wat je ook kiest, het resultaat moet een veld op de lead zijn dat het account noemt voordat er ook maar één routingregel draait.

Naar de verkeerde eigenaar gerouteerd, of naar een gloednieuw duplicaat

Als matching ontbreekt of fout gaat, duikt de schade op in de cijfers van andere teams. Daarom stelt vaak maandenlang niemand de juiste diagnose.

De eerste plek is eigenaarschap. Lead routing kan een lead alleen aan de accounteigenaar geven als de lead een account heeft. Een ongematchte lead van een klant valt in de round-robin, en een verkeerd gematchte lead gaat naar een collega die eigenaar is van een ander bedrijf. Allebei vertragen ze het eerste antwoord, en speed to lead lijdt eronder op een manier die op een probleem met de rep lijkt.

De tweede is duplicaten. Elke lead die zijn bedrijf niet vindt, is een kans voor het CRM of een integratie om er nog een aan te maken. Brinkhorst eindigt als drie records met drie eigenaren, met de deal-historie over alle drie verdeeld en een accountoverzicht dat een fractie van de echte activiteit laat zien. Duplicaten maken de volgende match weer moeilijker. Daarom moet je matching en CRM-hygiëne samen aanpakken, net als de bredere data hygiene van de bronnen die het CRM voeden.

De derde is verspilde targeting. Bij account-based marketing zet je op de targetlijst bedrijven die je bij naam kiest omdat ze passen bij het profiel van je beste klanten, en een lead van een tier-one-account op die lijst is nieuws. Die hoort de eigenaar te alarmeren, mee te tellen in account scoring en aan te sluiten bij de play waar dat account in zit. Een ongematchte lead van hetzelfde bedrijf ziet eruit als elk ander inbound contact. De play hoort er dan nooit van, en het geld dat je uitgaf om dat account te bereiken, levert niets op wat je kunt zien. Rapportages lijden er ook onder: de conversieratio van je lijst met target accounts ziet er slechter uit dan hij is, omdat een deel van de pipeline op records staat die er niet aan gekoppeld zijn.

Matchregels lopen scheef zodra ze live staan

L2A-logica veroudert. Bedrijven gaan door een rebrand, worden overgenomen, openen regiokantoren en wisselen van e-maildomein, en een set regels die bij de lancering klopte, raakt steeds verder los van het CRM waarvoor hij bedoeld is.

De simpelste gewoonte is een wekelijkse blik op wat niet matchte. Haal de leads op die de afgelopen zeven dagen zonder account zijn aangemaakt, groepeer ze op e-maildomein, en de gaten laten zich vanzelf zien: een nieuw alternatief domein om toe te voegen, een freemailprovider die op de lijst ontbreekt, een dochterbedrijf dat een eigen regel nodig heeft. Volg het aandeel leads dat matcht door de tijd heen, zoals je elke match rate zou volgen. Een plotselinge daling wijst meestal naar één bron of formulier dat is veranderd.

Twee andere gewoontes helpen. Verrijk dunne leads voordat de matching draait, want inbound enrichment kan het bedrijfsdomein aanvullen dat een lead met een freemailadres je niet gaf. En maak één persoon in revenue operations verantwoordelijk voor de reviewwachtrij met fuzzy voorstellen, zodat die elke week leeg gaat en niet blijft groeien tot iemand hem verwijdert.

Tot slot

Lead-to-account matching is leidingwerk. Niemand bedankt het als het werkt, en als het stukgaat, duiken de symptomen ergens anders op: in een traag antwoord, een dubbel bedrijf, een AE die van de klant hoort dat er een nieuwe stakeholder is.

Het werk zelf bestaat vooral uit dingen vooraf beslissen. Welke regels automatisch koppelen en welke alleen voorstellen. Wat er met een lead met een freemailadres gebeurt als enrichment niets vindt. Welk bedrijf in een groep eigenaar is van een lead die op het domein van het moederbedrijf binnenkomt. Schrijf die antwoorden op, bouw ze in volgorde van zekerheid en check elke week wat niet matchte. Doe je dat goed, dan worden de accounts iets waar andere processen op kunnen vertrouwen, van routing en scoring tot de prospecting-automatisering die nieuwe contacten in het CRM schrijft. Elk onderdeel van een go-to-market-setup die op accountdata draait leest die records, dus een match die één keer goed is gemaakt, blijft zich terugbetalen.

Pakt Nebor dit op, dan gaan de matchingregels, de lijst met freemaildomeinen en de reviewwachtrij in het CRM van de klant, of dat nu HubSpot of Salesforce is, met Clay voor de lookups die het CRM zelf niet kan doen. De klant houdt van elke regel een beschrijving in gewone taal, zodat een domein of een nieuw dochterbedrijf toevoegen een klein klusje is voor de eigen beheerder.

Veelgestelde vragen