Een GTM-stack is de software die een bedrijf gebruikt om klanten te vinden, te winnen en te houden: een CRM in het midden, met daaromheen gekoppelde tools voor data, outreach, koopsignalen, automatisering en rapportage. Opent marketing, sales of customer success een tool op een gewone werkdag, dan hoort die waarschijnlijk bij de stack.

De tools opsommen is het makkelijke deel. Of een GTM-stack werkt, hangt af van wat er tussen de tools gebeurt: welke tool een contact aanmaakt, welke de functietitel mag wijzigen, waar een reactie wordt gelogd en welke waarde wint als twee systemen het oneens zijn over hetzelfde veld. Die beslissingen worden hoe dan ook genomen, of iemand ze nu plant of niet. In de meeste stacks heeft niemand dat gedaan.

Daarom hebben zoveel teams goede software en draaien ze hun pipeline toch vanuit spreadsheets. Elke tool werd gekocht voor één probleem, gekoppeld met de integratie die standaard meekwam en daarna aan zijn lot overgelaten, om met de andere tools te bakkeleien over dezelfde records.

TL;DR

• De meeste stacks hebben zes lagen: het CRM als system of record, data en enrichment, intent en signalen, outreach, automatisering en orchestration, en rapportage. Beoordeel elke laag op wat hij doorgeeft aan de volgende.

• Data beweegt op vier manieren: syncs, pushes vanuit een datatool, events zoals webhooks, en activiteit die terug in het CRM wordt gelogd. Elk belangrijk veld heeft één systeem nodig dat wint, en de Salesforce-connector van HubSpot laat je per veld kiezen uit vier syncregels.

• Duplicaten zijn een matchingprobleem. HubSpot ontdubbelt contacten op e-mailadres en bedrijven op domein, maar bedrijven die via de API of een sync-app worden aangemaakt, slaan de domeincheck over. Integraties horen daarom het record-ID uit het CRM mee te nemen.

• Een datalaag zoals Clay laat enrichment, signalen en outreach vanuit één record werken, zolang hij bijwerkt op record-ID en nooit een gevuld veld overschrijft met een lege waarde.

• Bepaal de motion voordat je tools koopt, en doe een audit met een datakaart die overlap, ongebruikte licenties en de nooit gebouwde koppeling zichtbaar maakt.

• Nebor ontwerpt en koppelt GTM-stacks in accounts die van de klant zijn, legt vast welk systeem eigenaar is van elk veld en draagt de opzet over aan de persoon die hem gaat draaien.

De zes lagen van een GTM-stack, en wat elke laag doorgeeft

Productnamen veranderen elk jaar. De taken eronder blijven vrijwel gelijk, en de meeste stacks passen in dezelfde zes lagen. In de tabel hieronder is vooral de derde kolom het lezen waard, want een laag die niets doorgeeft, is gewoon een tool die op zichzelf staat.

Automatisering is de laag die mensen vergeten mee te tellen, omdat hij vaak in andere tools zit: hier een HubSpot-workflow, daar een Zap. Gewone sales automation handelt losse taken af, terwijl workflow orchestration bepaalt welke flow eerst draait en wat er gebeurt als een stap faalt. Bij veel bedrijven zijn signalen uitgegroeid tot een eigen stack, waarin first-party intentdata en ingekochte feeds samenkomen. Het artikel over de sales signal stack legt dat verder uit.

De lagen laten ook zien waarom het aantal tools zo weinig zegt. Een team van vijf mensen kan alle zes afdekken met een CRM, één datatool, één verzendtool en de rapporten van het CRM zelf, terwijl een groot team drie producten in één laag kan hebben. Waar het om gaat, is of elke laag zijn output doorgeeft zonder dat iemand ertussen een CSV exporteert. Wil je per laag zien welke producten erin passen, lees dan het overzicht van de sales tech stack van Nebor.

Hoe data tussen de tools beweegt

Elke koppeling in een stack is een van vier soorten, en elke soort gaat op zijn eigen manier stuk.

1. Syncs. Twee tools houden dezelfde velden gelijk, zoals een CRM en een sequencer, of HubSpot en Salesforce die naast elkaar draaien. De beslissing die telt, is welke kant wint. De Salesforce-connector van HubSpot vraagt voor elk gemapt veld om een regel: Salesforce voorrang geven tenzij het veld leeg is, altijd Salesforce gebruiken, in twee richtingen synchroniseren, of niet synchroniseren. Bij twee richtingen overschrijft de meest recente waarde de andere kant en gaan verwijderingen ook beide kanten op, dus één onzorgvuldige bulkwijziging komt in allebei de systemen terecht.

2. Pushes. Een datatool verrijkt of scoort records en schrijft het resultaat volgens een schema of na een trigger naar het CRM. Een schone push werkt het bestaande record bij in plaats van een nieuw record aan te maken, en dat lukt alleen als je het ID van het record kent (daarover hieronder meer).

3. Events. Er gebeurt iets, zoals een ingevuld formulier, een geboekte meeting of een reactie, en een webhook brengt het meteen naar een automatiseringstool. n8n omschrijft zijn Webhook-node als een manier om data van apps en diensten te ontvangen zodra er een event plaatsvindt. Events maken een stack snel, omdat niets hoeft te wachten op de nachtelijke sync.

4. Activiteit loggen. Verzonden berichten, calls, reacties en meetings worden teruggeschreven naar het contact en de deal in het CRM. Het is de minst spannende koppeling, en de koppeling waar je rapportage het zwaarst op leunt.

De regel die voorkomt dat deze vier elkaar in de weg zitten, is één eigenaar per veld. Kies voor elk veld dat ertoe doet (lifecycle stage, eigenaar, functietitel, bedrijfsgrootte, leadscore) het ene systeem dat het mag schrijven, en laat elke andere tool het alleen lezen. Passen enrichment en een rep allebei functietitels aan, of zetten een sequencer en een HubSpot-workflow allebei de lifecycle stage, dan springt de waarde heen en weer en kan niemand zeggen welke versie klopt. In welke volgorde flows afgaan, en wat er gebeurt als er een faalt, hoort bij de orchestration-laag uit het artikel over workflow orchestration.

Eén detail overvalt teams als ze een sync toevoegen aan een bestaande opzet. Volgens de documentatie van HubSpot worden bestaande waarden in een nieuw aangemaakte mapping niet met terugwerkende kracht gesynchroniseerd. Een veld dat in maart is gemapt, blijft op elk ouder record leeg tot iemand een resync of een import draait, en rapporten die op dat veld leunen, lijken kapot om redenen die niemand ziet.

De meeste dubbele records zijn een matchingprobleem

Als twee tools aan elkaar gekoppeld zijn, moet elk van beide kunnen weten dat het record dat hij heeft, hetzelfde is als het record aan de andere kant. Die sleutel is de plek waar de meeste duplicaten ontstaan.

De deduplicatieregels van HubSpot matchen contacten op e-mailadres en bedrijven op domeinnaam. Voor formulieren werkt dat goed. Voor integraties minder, want hetzelfde artikel zegt dat bedrijven die via de API worden aangemaakt, inclusief geïnstalleerde sync-apps van derden, niet worden ontdubbeld op de eigenschap bedrijfsdomein. Een datatool die bedrijven aanmaakt in plaats van ze bij te werken, kan je CRM vullen met tweede exemplaren van accounts die je al had, elk met een eigen eigenaar en een lege historie.

Contacten zonder e-mailadres zijn het andere gat. Veel records uit LinkedIn-sourcing of eventlijsten komen binnen met een naam, een functie en een bedrijf en verder niets, dus matchen op e-mail heeft niets om zich aan vast te houden.

De oplossing is het record-ID uit het CRM overal de sleutel te maken. Verlaat een record het CRM voor enrichment, scoring of een sequence, dan reist zijn ID mee, en elke terugschrijving gebruikt dat ID. Records zonder ID gaan eerst door een lookup die matcht op e-mail, domein of LinkedIn-URL, en worden pas aangemaakt als die lookup niets vindt. Het is saai werk, en het bepaalt of je CRM-hygiëne overeind blijft als vijf tools naar dezelfde database schrijven. Eén persoon of bedrijf herkennen over veel bronnen heen is een vak op zich, en dat behandelen we onder identity resolution.

De datalaag in het midden

De grootste verandering in hoe stacks de afgelopen jaren worden gebouwd, is een laag tussen het CRM en al het andere. Tools zoals Clay halen records uit het CRM en uit allerlei dataproviders, laten er logica en AI-onderzoek op los en pushen de resultaten terug naar het CRM, de sequencer en Slack.

Met die middelste laag werken enrichment, signalen en outreach vanuit één record in plaats van drie. Een bezoek aan de prijspagina, een functiewissel en een fitscore komen op dezelfde rij terecht, en de outreach die volgt, kan uit alle drie putten. Het is de werkende kern van signal-based selling en van de meeste moderne revenue engines.

Het concentreert ook risico, want één tabel kan nu schrijven naar elk systeem dat je hebt. De gids voor het synchroniseren van HubSpot-data van Clay zelf noemt de twee gewoontes waar wij op zouden staan. Gebruik de update-actie met het HubSpot-record-ID als sleutel en bewaar create voor objecten die echt nieuw zijn. En zet de instelling aan die lege waarden negeert, zodat een veld dat je niet kon verrijken nooit een veld wist dat al gevuld was. Dezelfde logica geldt voor Salesforce of elk ander CRM, en het stuk van Nebor over de integratie tussen Clay en HubSpot loopt de opzet stap voor stap door.

Het andere risico is het denkwerk achter de tabel. Een datalaag vermenigvuldigt de logica die je hem meegeeft, en daarom vallen zoveel Clay-builds tegen: het resultaat is een prachtig verrijkte lijst met bedrijven die nooit iets nodig hadden van wat jij verkoopt.

Waarom nog een tool de motion zelden repareert

De meeste stacks groeien klacht voor klacht. De reply rates dalen, dus het team koopt een nieuwe verzendtool. Reps mopperen over slechte data, dus iemand sluit een tweede provider af. Niemand doet iets met intent, dus er komt een intentplatform bij. Elke aankoop is logisch op de dag zelf, en een jaar later heeft de stack meer logins en dezelfde resultaten.

De tool was meestal niet het ontbrekende stuk. Een nieuwe sequencer repareert geen lijst met bedrijven die niet nodig hebben wat jij verkoopt, en een intentfeed verandert niets als geen enkele regel een signaal omzet in een taak voor een rep. Software is capaciteit die wacht op een proces dat haar gebruikt. Koop je haar voordat dat proces bestaat, dan krijg je er alleen een factuur, een login en nog een kopie van je klantdata bij.

De volgorde die werkt, loopt andersom. Begin bij de kopers die je wilt bereiken en de route die een deal hoort af te leggen van eerste contact tot handtekening. Zet op een rij welke overdrachten die motion nodig heeft, zoals van nieuwe lead naar eigenaar, van signaal naar sequence, van reactie naar meeting en van gesloten deal naar onboarding. Vraag pas daarna welke tool elke overdracht draagt. Vaak is het antwoord iets wat al in de stack zit, mits goed ingericht. Zo blijft de stack in dienst van je go-to-market-strategie in plaats van dat hij de plek ervan inneemt.

Je GTM-stack doorlichten vanuit de datakaart

Voelt een stack duur en traag, dan vertelt een lijst met tools en facturen je niet waarom. Een datakaart wel. Teken elke tool als een vak en elke koppeling als een pijl, zet bij elke pijl wat erover gaat en hoe (sync, push, event of log), en markeer daarna welk systeem eigenaar is van elk belangrijk veld.

Er komen bijna altijd drie dingen boven.

• Overlap: twee of drie tools die hetzelfde werk doen met verschillende data, zoals twee enrichment-providers die verschillende bedrijfsgroottes in hetzelfde veld schrijven.

• Shelfware: tools die nog elke maand factureren zonder dat er pijlen in of uit gaan, omdat degene die ze opzette is vertrokken of de use case is weggevallen.

• De ontbrekende pijl: de overdracht die nooit is gebouwd, zoals reacties die het CRM niet bereiken of productgebruik dat sales niet kan zien. Vaak is dit precies het probleem dat de laatste aankoop had moeten oplossen.

Met wat je bespaart door de overlap en de shelfware te schrappen, betaal je meestal de ontbrekende pijl. Voordat er iets nieuws binnenkomt, doen drie vragen het meeste filterwerk: welk deel van de motion dient het, kan iets wat al in de stack zit het werk doen, en hoe wordt het aan het CRM gekoppeld? Een product zonder goed antwoord op die derde vraag wordt een eiland, hoe sterk de featurelijst ook is.

Teken de kaart opnieuw zodra er een tool bijkomt of verdwijnt. Je RevOps-lead heeft dan een document om bij te werken in plaats van een stack om naar te raden, en de volgende aankoopbeslissing wordt een vraag over één pijl in plaats van over een hele categorie.

De tools, de mensen die ze koppelen en in wiens accounts ze staan

Drie termen worden bijna door elkaar gebruikt, en dat zou niet moeten. De GTM-stack is de verzameling tools. GTM engineering is het vak van die tools koppelen tot workflows die draaien zonder dat iemand data tussen tools kopieert. Een werkend GTM-systeem is het resultaat: de motion die elke dag op de stack draait, met de overdrachten ingebouwd.

Het verschil telt het zwaarst als iemand van buiten het bedrijf de koppelingen legt. Draait een bureau je outbound vanuit zijn eigen Clay-workspace, verzenddomeinen en sequencer, dan krijg je de resultaten zonder de stack. Loopt het contract af, dan vertrekken de workflows, de data en de opgewarmde inboxen mee. Een stack die in je eigen accounts is gebouwd, wordt met de tijd nuttiger, omdat elke nieuwe workflow de records, velden en koppelingen hergebruikt die de vorige heeft neergelegd.

Eigenaar zijn betekent ook dat je het begrijpt. De datakaart uit de audit, een korte notitie over waarom elk veld de eigenaar heeft die het heeft, en iemand met naam binnen het bedrijf die op de koppelingen let: samen maken ze van een verzameling logins iets wat het team met vertrouwen kan aanpassen.

Tot slot

Een GTM-stack is makkelijk te beschrijven als een lijst producten, en dat is de minst nuttige manier om ernaar te kijken. De nuttige blik is de stroom: wat elke laag doorgeeft aan de volgende, welk systeem elk veld wint en welke sleutel een record in de ene tool verbindt met hetzelfde record in een andere.

Zo bekeken lijken de meeste stackproblemen niet langer op ontbrekende software. Het blijkt een syncregel te zijn die niemand koos, een datatool die bedrijven aanmaakt in plaats van ze bij te werken, of een reactie die nooit bij de deal aankomt. Die los je op met configuratie en een paar uur zorgvuldig mappen. Daar is geen nieuw contract voor nodig.

Weet je niet waar je moet beginnen? Teken de kaart. Dat kost een middag, en meestal wijst hij de ene koppeling aan die het bouwen waard is voordat er iets anders wordt gekocht.

Bij die kaart begint ook ons eigen werk voor klanten. Nebor koppelt de lagen in accounts die van de klant zijn, legt vast welk systeem over elk veld gaat en laat de afgeronde stack achter bij de mensen die hem blijven draaien.

Veelgestelde vragen