GTM engineering is het bouwen van het go-to-market-werk van een bedrijf als geautomatiseerde systemen. Accounts vinden, records verrijken, leads scoren en routeren, outreach starten en het CRM bijwerken lopen dan via gekoppelde workflows, in plaats van via mensen die elke stap met de hand doen. Een GTM engineer is degene die die systemen ontwerpt, bouwt en onderhoudt.

Clay, het platform waar veel van deze systemen omheen gebouwd zijn, schrijft in zijn gids over GTM engineering dat het de rol in 2023 heeft bedacht. Het idee eronder is ouder en eenvoudiger. Heb je meer pipeline nodig, dan kun je iemand extra aannemen om het werk te doen. Je kunt ook iets bouwen dat het werk doet en daar iemand verantwoordelijk voor maken.

Dit is wat Nebor de hele dag doet, dus we hebben er een mening over. De belangrijkste: de software is het makkelijke deel. De meeste GTM-engineeringprojecten die tegenvallen, hadden prima tools en geen helder antwoord op drie simpele vragen. Aan wie verkopen we, wat zeggen we, en wie is eigenaar zodra het gebouwd is?

TL;DR

• GTM engineering vervangt repetitief go-to-market-werk door systemen. Wat je oplevert is een draaiende workflow in plaats van een lijst met afgevinkte taken, bijvoorbeeld een workflow die elk nieuw account onderzoekt zodra het binnenkomt.

• De rol groeide omdat aannemen niet meer schaalde en de tools eindelijk goed genoeg werden. Volgens onderzoek van Bridge Group uit 2025 duurt het gemiddeld 3,0 maanden voordat een SDR is ingewerkt, en blijft een SDR gemiddeld 1,9 jaar. Tegelijk maakten Clay, n8n en Make serieuze automatisering mogelijk zonder softwareteam.

• Een typische opzet brengt een inbound demo-aanvraag in een paar minuten van ingevuld formulier naar een verrijkt, gescoord en gerouteerd record, met een melding in Slack. Het meeste echte werk zit in wat eromheen gebeurt: API-limieten, foutmeldingen en een menselijke check voordat er iets bij een koper terechtkomt.

• RevOps houdt de bestaande systems of record schoon en meetbaar. Een GTM engineer bouwt nieuwe systemen die pipeline opleveren en verwerken. In kleine bedrijven doet één persoon meestal allebei.

• De toolkit is grotendeels no-code, en Clay zegt zelf dat de rol geen productiecode vraagt. De lastigste helft van de skills is commercieel: weten wat het waard is om te bouwen voor een echte koper.

• Projecten lopen vast als ze bij de tool beginnen, een aanpak automatiseren die met de hand nog niet werkt, te complex worden om te onderhouden of in de accounts van een ander draaien.

• Bouw de systemen in je eigen CRM, Clay-workspace en automatiseringsaccounts, want infrastructuur groeit alleen in waarde als je hem volgend jaar nog hebt. Zo bouwt Nebor ze voor klanten, voordat we ze overdragen.

Waarom bedrijven gingen bouwen in plaats van aannemen

Het grootste deel van het afgelopen decennium was het antwoord op "we hebben meer pipeline nodig" simpelweg headcount. Nog een SDR om accounts te onderzoeken en e-mails te sturen, nog een coördinator om het CRM op te ruimen, nog een rep om de binnenkomende leads op te volgen. In dat model zit een kostencurve ingebouwd: elke nieuwe persoon kost vanaf de eerste dag een volledig salaris en haalt pas later zijn volle tempo.

Het SDR-rapport van de Bridge Group uit 2025, gebaseerd op 351 B2B-bedrijven, zet de gemiddelde inwerktijd van een SDR op 3,0 maanden en de gemiddelde dienstduur op 1,9 jaar. Dat is de kortste inwerktijd die het onderzoek sinds 2010 heeft gemeten. Toch gaat nog steeds ongeveer een achtste van de tijd dat een gemiddelde SDR blijft op aan op snelheid komen. Daarna komt de stoel leeg te staan en begint de cyclus opnieuw.

Ondertussen veranderden de tools. Clay bracht tientallen dataproviders, AI-onderzoeksstappen en logica samen in één tabel. Met n8n en Make werd het haalbaar om een formulier, een CRM en een Slack-kanaal te koppelen zonder een applicatie te schrijven. Taalmodellen werden goed genoeg om de website van een bedrijf samen te vatten of een openingszin te schrijven die iemand daarna controleert.

Zet die twee verschuivingen naast elkaar en een ander soort hire wordt logisch: iemand die commercieel genoeg is om te snappen hoe een deal tot stand komt, en technisch genoeg om de repetitieve delen van dat proces om te zetten in infrastructuur. Over de economie van die keuze schreven we in salessystemen versus headcount, en over de eerste praktische stappen in je prospecting vanaf nul automatiseren.

Mensen verdwijnen in dit model niet. Ze schuiven op. Reps besteden meer van hun week aan echte gesprekken, en iemand is eigenaar van de machine die ze voedt.

Hoe GTM engineering eruitziet bij één inbound lead

Beschrijvingen van de rol blijven vaak abstract, dus hier is één concreet voorbeeld. Een B2B-softwarebedrijf krijgt demo-aanvragen binnen via een formulier op de prijspagina.

Zonder engineering is het pad handmatig. Het formulier maakt in HubSpot een contact aan met een naam, een e-mailadres en een bedrijfsnaam. Een SDR ziet het de volgende ochtend, zoekt de persoon op LinkedIn op, schat de bedrijfsgrootte in, beslist of een call de moeite waard is, wijst een eigenaar toe en stuurt een agendalink. Op een goede dag is dat twintig minuten werk, verpakt in bijna een hele dag wachten. Tegen die tijd praat de koper misschien al met een concurrent.

Een GTM engineer bouwt hetzelfde pad opnieuw op als systeem:

1. Het ingevulde formulier vuurt direct een webhook af, dus niets wacht tot iemand het CRM opent.

2. Het record gaat door data enrichment in Clay, met een waterfall die de ene provider na de andere probeert tot bedrijfsgrootte, branche, functietitel en LinkedIn-URL zijn ingevuld.

3. Een fit-check legt het bedrijf en de rol naast het ideal customer profile. Privé-e-mailadressen, studenten en concurrenten vallen hier af, in plaats van op het bureau van een rep te belanden.

4. Regels voor lead routing kiezen een eigenaar op basis van regio en segment, en het record gaat terug naar HubSpot met elk verrijkt veld.

5. De eigenaar krijgt een Slack-bericht met de context al verzameld (wie de persoon is, wat het bedrijf doet, welke pagina's diegene las) en kan bellen terwijl de interesse nog warm is.

Die vijf stappen zijn wat mensen in demo's laten zien. Het werk zit vooral in wat eromheen gebeurt.

Levert een webinar in één weekend 3.000 aanmeldingen op, dan loopt het terugschrijven naar HubSpot tegen de API-limieten aan. De richtlijnen voor API-gebruik van HubSpot beperken private apps op Professional en Enterprise tot 190 requests per 10 seconden. De workflow moet zijn updates dus in een wachtrij zetten en bundelen, in plaats van ze allemaal tegelijk af te vuren. Valt een enrichment-provider uit door een time-out, dan moet iets dat opmerken. In n8n is dat een error workflow, die draait zodra de uitvoering van een andere workflow mislukt en dan degene die dienst heeft kan waarschuwen.

Niets daarvan zie je in een schermopname van het eindresultaat, en alles daarvan bepaalt of het systeem in maand zes nog werkt. Daarom omschrijven we de rol als bedrading, workfloworkestratie en reparatie, waarbij reparatie meer van de week kost dan iemand verwacht.

Hetzelfde patroon zie je terug in de andere systemen waar een GTM engineer meestal eigenaar van is: lijsten met doelaccounts bouwen uit meerdere bronnen, outreach starten zodra er een koopsignaal verschijnt en CRM-velden actueel houden zonder dat iemand iets hoeft te typen. Onze workflow voor inbound meetings is een uitgebreidere versie van het voorbeeld hierboven.

Bouwer of beheerder: de grens tussen GTM engineering en RevOps

RevOps en sales ops zijn eigenaar van de systems of record. Ze houden het CRM accuraat, bouwen de rapportages die het management leest, beheren de toolstack en bewaken het proces dat een salesteam consistent houdt. Een GTM engineer bouwt nieuwe systemen die pipeline opleveren of verwerken, meestal met tools die dichter bij code zitten, zoals webhooks, API's, Clay-tabellen en automatiseringsplatformen.

De overlap is echt. Beide rollen leven in het CRM en beide geven om schone data. De nuttige vraag bij het aannemen is welk soort output je de komende zes maanden het hardst nodig hebt. Vertrouwt niemand de forecast, dan heb je RevOps nodig. Zijn je reps elke ochtend bezig met accounts onderzoeken en data kopiëren tussen tabbladen, dan heb je iemand nodig die bouwt.

In kleinere bedrijven doet één persoon meestal allebei. Dat werkt zolang iedereen weet welke helft er blijft liggen. In grotere teams werken de twee naast elkaar: RevOps stelt de regels op (definities, fases, eigenaarschap) en de GTM engineer bouwt systemen die zich daaraan houden.

De toolkit van GTM engineering, en de helft van de skills die mensen onderschatten

De meeste GTM engineers zetten Clay in het midden van wat ze bouwen, omdat het enrichment-providers, AI-onderzoeksstappen en logica op één plek samenbrengt. Daaromheen zitten automatiseringsplatformen als n8n, Make of Zapier om data tussen systemen te verplaatsen, een taalmodel zoals Claude voor onderzoek en teksten, signaalbronnen voor de timing en een CRM zoals HubSpot of Salesforce als system of record. Samen vormen ze de GTM-stack waarin de engineer bouwt.

Heel weinig hiervan vraagt om een software engineer. De gids van Clay zegt zonder omwegen dat een GTM engineer geen productiecode hoeft te schrijven. Wat de baan wel vraagt: je thuis voelen bij API's en JSON, gevoel voor hoe data kapotgaat (duplicaten, lege velden, drie spellingen van hetzelfde land) en het geduld om een workflow op vijftig records te testen voordat je hem op vijftigduizend loslaat.

De helft die mensen onderschatten, is commercieel. Een GTM engineer die nooit heeft verkocht, bouwt vaak indrukwekkende AI-workflows die de pipeline niet in beweging krijgen. Denk aan een prachtig verrijkte lijst met bedrijven die nooit gaan kopen, of gepersonaliseerde openingszinnen die kloppen en toch nergens over gaan. De goede zijn eerst practitioner en dan pas bouwer. Ze hebben zelf meetings geboekt of deals gedraaid, en ze blijven zich afvragen of wat ze bouwen iets verandert aan wat een koper ziet.

Daar gaan GTM engineering en gewone sales-automatisering ook uit elkaar. Automatisering is een set mogelijkheden. Engineering is kiezen welke je combineert, in welke volgorde en voor welke koper, en het resultaat draaiend houden als de input verandert.

Waarom GTM-engineeringprojecten vastlopen

We bouwen elke week in Clay, dus we zeggen dit met liefde: de gebruikelijke reden dat een GTM-engineeringproject tegenvalt, heeft niets met de tool te maken. Een team koopt een Clay-abonnement, iemand bouwt een tabel met twaalf enrichment-kolommen en een AI-agent, en drie maanden later heeft dat veel data opgeleverd en heel weinig meetings. Niemand had de targeting of de boodschap vastgelegd voordat het bouwen begon. Het gebeurt vaak genoeg dat we er een stuk over schreven: waarom de meeste Clay-implementaties mislukken.

Drie andere oorzaken volgen op korte afstand.

• Een aanpak automatiseren die nog niet werkt. Komt de boodschap niet aan als een goede rep hem met de hand verstuurt, dan stuurt automatisering er alleen meer van. Engineering vermenigvuldigt wat eronder ligt, problemen inbegrepen.

• Meer bouwen dan iemand kan onderhouden. Een systeem met veertig stappen, zes tools en geen documentatie draait prima tot de bouwer op vakantie gaat. Een eenvoudiger systeem dat het grootste deel van het werk dekt en door iemand anders te repareren is, is meer waard.

• Bouwen waar je niet in kunt kijken. Draaien de workflows in de accounts van een leverancier of een bureau, dan kun je ze niet inzien, niet aanpassen en niet meenemen. Het werk wordt dan nooit iets wat van jou is.

De oplossingen zijn weinig spectaculair. Zorg dat het ideal customer profile en de boodschap eerst met de hand werken. Schoon de data op voordat je er automatisering op bouwt. Houd een human in the loop bij alles wat een koper leest. Leg vast wat elke workflow doet en wie erop let.

Wie hoort eigenaar te zijn van de systemen als ze eenmaal gebouwd zijn?

GTM engineering is de laag onder je strategie. Je go-to-market-strategie bepaalt de markten, de kopers en de boodschap, en de engineering zet die beslissingen om in een werkend GTM-systeem dat elke dag draait. Zonder de engineering blijft de strategie een slidedeck. Zonder de strategie bouwt de engineering slimme dingen die op niemand in het bijzonder gericht zijn.

Dan is er de vraag waar die systemen staan. Veel uitbestede pipeline draait op infrastructuur van de leverancier: hun domeinen, hun Clay-workspace, hun sequencer, hun data. Loopt het contract af, dan stoppen de meetings en hou je niets over. Dat is de kern van het verschil dat we maken tussen een GTM-bureau en een bureau voor lead generation.

Wij vinden dat de systemen vanaf de eerste dag in je eigen accounts horen: je CRM, je Clay-workspace, je automatiseringsplatform, je verzenddomeinen. Bouw je het zo, dan is elke nieuwe workflow goedkoper dan de vorige, omdat de data en de leidingen al op hun plek liggen. Zo wordt een verzameling automatiseringen een revenue engine in plaats van een maandelijkse factuur, en daarom hoort een schriftelijke overdracht bij wat we opleveren.

Samenvatting

Haal de functietitel weg en GTM engineering is een keuze over hoe een bedrijf groeit. Je bouwt de repetitieve delen van go-to-market één keer, als systemen, en je zet mensen in waar hun oordeel telt: in gesprekken met kopers en bij de beslissing wat de systemen hierna moeten doen.

Het vakmanschap zit vooral in de delen die niemand in een demo laat zien. De fit-check die studenten uit het CRM houdt, de wachtrij die de API-limieten van HubSpot respecteert, de melding die afgaat als een enrichment-stap 's nachts faalt, de notitie die uitlegt waarom een routingregel bestaat. Teams die GTM engineering behandelen als een toolaankoop, houden dure tabellen over. Teams die het als engineering behandelen en beginnen bij een aanpak die met de hand al werkt, bouwen infrastructuur die elk kwartaal nuttiger wordt.

Twijfel je of je erin wilt investeren? Begin kleiner dan ambitieus voelt. Kies één systeem, zoals inbound routing of accountonderzoek, bouw het goed en kijk hoeveel tijd het je reps teruggeeft.

Dat is het werk dat we bij Nebor doen. We bouwen deze systemen in je eigen CRM-, Clay- en automatiseringsaccounts en dragen ze over met de onderbouwing op papier. Zo is de machine vanaf de dag dat we klaar zijn van je team, om zelf te draaien en aan te passen.

Veelgestelde vragen