GTM-Engineering vs. RevOps: Wer baut, wer betreibt und welche Rolle in Ihrem Team fehlt

Drei verschiedene Dinge, die sich ein Wort teilen

Sagt jemand GTM, hört jeder etwas anderes. Im Marketing denkt man an einen Launch-Plan, im Vertrieb an Outbound-Vertrieb und im Operations-Team an Tools. Es lohnt sich, die drei Ebenen zu trennen, die im Gespräch ständig durcheinandergeraten.

GTM-Strategie (Go-to-Market) beantwortet vier Fragen: an wen Sie verkaufen, was Sie diesen Kunden sagen, zu welchem Preis und über welchen Kanal. Das Ergebnis ist eine Entscheidung: ICP, Positionierung, Preis und ein Launch-Plan. Die Geschäftsführung erarbeitet sie gemeinsam mit Vertrieb und Marketing, Tools braucht es dafür noch keine.

RevOps (Revenue Operations) steuert den gesamten Umsatzzyklus: das CRM und das Datenmodell, die Definitionen (was ist ein Lead, was eine qualifizierte Opportunity), die Übergaben zwischen Marketing, Vertrieb und Customer Success, Reporting und Forecast. Sales Ops und Marketing Ops sind Teile davon, und RevOps verbindet sie zu einem Prozess mit einer gemeinsamen Zahlenbasis. Im Mai 2021 prognostizierte Gartner, dass bis 2025 75 % der wachstumsstärksten Unternehmen der Welt ein Revenue-Operations-Modell einsetzen würden. Das war eine Prognose, eine spätere Messung habe ich nicht gefunden. Verstehen Sie sie daher als unbestätigte Einschätzung der Entwicklungsrichtung.

GTM-Engineering baut Systeme, die Daten in Aktionen verwandeln. Ein typisches Beispiel: Ein Workflow beobachtet, welches Unternehmen beginnt, Vertriebsstellen zu besetzen, die Technologie wechselt oder Ihre Preisseite ansieht, ergänzt Kontakte dieses Unternehmens, verifiziert sie und startet den Outreach. Früher hat das ein SDR mit einer Tabelle erledigt. Heute kann es automatisch laufen, aber jemand muss es bauen: Tools über APIs verbinden, Abfragen auf den Daten schreiben und KI-Agenten dort einsetzen, wo früher Menschen kopiert und eingefügt haben. Unser Artikel über Go-to-market engineering zeigt Schritt für Schritt, wie ein solcher Workflow aussieht.

Die Bezeichnung GTM-Engineer stammt von Clay und ist mit Yash Tekriwal verbunden. Laut einem Gainsight-Podcast und Beiträgen in der Clay-Community war das 2023, und der Name kam erst, nachdem es die Arbeit längst gab. Das ist die Darstellung des Unternehmens selbst, sie deckt sich aber mit dem, was wir bei Kunden sehen: Jemand beginnt, Automatisierungen zusammenzustecken, und den Namen findet man erst danach.

Bauen und Betreiben: die nützlichste Vereinfachung und wo sie an ihre Grenze stößt

Die meisten Artikel zu diesem Thema teilen die Rollen gleich auf. GTM-Engineering heißt Bauen: neue Systeme schaffen. RevOps heißt Betreiben: bestehende Systeme führen, absichern und verbessern. Apollo stellt es als Wahl zwischen zwei Einstellungen dar: Wollen Sie jemanden, der Ihr Umsatzsystem baut, oder jemanden, der es betreibt? Für die Einstellung ist das ein guter Anfang. Im Detail trägt die Vereinfachung nicht weit.

Bloomberry hat mehr als tausend Stellenanzeigen für GTM-Engineers ausgewertet und festgestellt, dass neun der zehn häufigsten Aufgaben auch in RevOps-Anzeigen vorkommen. Der Unterschied liegt in der Reihenfolge. RevOps-Anzeigen beginnen mit der CRM-Verantwortung und ergänzen die Forecast-Genauigkeit, GTM-Engineer-Anzeigen beginnen mit Automatisierung und Integrationen und nennen die CRM-Arbeit etwa an dritter oder vierter Stelle.

Bei den technischen Fähigkeiten hängen die Zahlen davon ab, was gezählt wird. In der Analyse von OnFire über 209 Stellenanzeigen verlangten 56 % SQL, Python oder JavaScript. Einen Vergleich mit RevOps gibt es dort nicht, aber die Richtung ist klar: Code und Abfragen gehören für einen GTM-Engineer zur Standardausstattung.

Ein Hinweis zu den Quellen. Die meisten Vergleiche stammen von Unternehmen, die Software an eine der beiden Seiten verkaufen, und kommen deshalb zu dem Schluss, dass es sich um zwei sich ergänzende Rollen handelt und man am besten beide besetzt. Die tatsächlichen Definitionen unterscheiden sich von Firma zu Firma. Suchen Sie die Grenze daher bei den Zuständigkeiten, denn die Berufsbezeichnung sagt darüber wenig aus. Der Satz, ein GTM-Engineer sei bloß RevOps mit Python, ist übertrieben, kommt aber nicht von ungefähr: Beide Rollen greifen auf dasselbe CRM und dieselben Daten zu.

Der Vergleich auf einen Blick

Wer wofür zuständig ist, wenn beide Rollen im selben CRM arbeiten

Das praktische Problem beginnt, wenn ein GTM-Engineer einen Workflow startet und RevOps nichts davon weiß. Stellen Sie sich ein Unternehmen mit zwanzig Personen im Vertrieb vor. An einem Abend baut der GTM-Engineer einen Flow, der tausend Unternehmen aus öffentlichen Quellen zieht und ins CRM schreibt. Hat RevOps nie Regeln für Dubletten, Account-Eigentümer und Pflichtfelder festgelegt, liegen am nächsten Morgen tausend Datensätze im CRM, die der Vertrieb erst bereinigen muss. Gibt es die Regeln, sind es tausend brauchbare Kontakte mit klarem Verantwortlichen.

Die Regel, die sich bei uns bewährt hat: RevOps verantwortet die Regeln und die Zahlen, GTM-Engineering verantwortet die Workflows und Integrationen. RevOps legt fest, was ein Lead ist, wer ihn bekommt, welche Felder Pflicht sind und wann das System einen Datensatz überschreiben darf. Der GTM-Engineer hält sich an diese Regeln, schreibt nur im Rahmen dieser Regeln ins CRM und dokumentiert jede Änderung an Workflows in einem Changelog. Forecast, Vertriebsgebiete und Vergütung sollten bei RevOps bleiben.

Und wenn eine Person alles übernimmt? RevPartners schreibt, dass ein Unternehmen in der Frühphase mit einer Hybridrolle auskommt, während eine wachsende Organisation für jede Funktion eine eigene Person braucht. Das leuchtet ein: Ein kleines Unternehmen hat wenige Regeln zu hüten. Auch eine Hybridrolle muss die Arbeit in zwei Warteschlangen trennen. Der laufende Betrieb darf nie liegen bleiben, und das Bauen wird in Sprints geplant.

Was Fachleute aus der Praxis sagen

Jemand aus der Community r/gtmengineering fragte kürzlich, worin der eigentliche Unterschied zwischen GTM und RevOps besteht, und vermutete, GTM sei gezielter Outbound-Vertrieb, während RevOps allgemein für den Zustand der Pipeline sorge. Die Antworten liefen auf eine andere Aufteilung hinaus. GTM entscheidet, wie das Unternehmen verkauft: wen man anspricht, mit welcher Botschaft, über welchen Vertriebsansatz und wer an wen übergibt. RevOps betreibt und misst es: CRM, KPIs, Quoten, Vertriebsgebiete, Reporting und oft auch Provisionen. Die kürzeste Fassung aus dem Thread: Vertrieb und GTM erledigen die Arbeit, RevOps misst die Arbeit. Outbound ist nur ein Kanal innerhalb von GTM.

Auch eine skeptische Anmerkung kam auf: GTM sei für viele nur ein umbenannter Vertrieb, und RevOps erledige Arbeit, die es im Vertrieb schon immer gab. Die Antwort darauf: Ja, neu ist die Arbeit nicht, aber in Unternehmen mit RevOps machen sie nicht mehr diejenigen, die das Vertriebsteam führen. Kennzahlen und Tools gehören zu beiden Welten, so wie Botschaften und Wertversprechen sowohl zum Vertrieb als auch zum Marketing gehören.

Laut den Kommentaren wird das Wort GTM auf drei Arten verwendet: als Plan (Strategie), als das gesamte Team, das Umsatz erzeugt, und neuerdings als Berufsbezeichnung. Eine der Antworten beschrieb den GTM-Engineer als ungefähr RevOps mit besseren Tooling-Gewohnheiten und der Bereitschaft, Code zu schreiben, der direkt in den Stack eingreift, statt sich durch Workflow-Builder zu klicken. Das deckt sich mit der Aufteilung am Anfang dieses Artikels.

Eine weitere Person schilderte einen Fehler aus der eigenen Laufbahn. Das Unternehmen hatte einen guten GTM-Plan und behandelte RevOps als reine Administration. Niemand hatte im CRM definiert, was eine qualifizierte Opportunity ist, deshalb meldeten drei Teams drei verschiedene Pipelines. Die Strategie war gut, die Zahlen stimmten nicht. In einem solchen Unternehmen würde ein GTM-Engineer auf dem CRM das Durcheinander nur schneller laufen lassen. Eine andere Person ergänzte, dass die meiste Reibung bei der Übergabe entsteht, wo Berufsbezeichnungen nicht mehr weiterhelfen.

Das ist eine Sammlung von Praxismeinungen aus einem einzigen Thread und enthält keine Statistik. Sie zeigt aber, wie Fachleute aus der Branche über die Grenze denken, und stützt die oben beschriebene Aufteilung der Zuständigkeiten.

Wen Sie zuerst einstellen sollten

Die Quellen sind uneins, wovon die Entscheidung abhängen sollte. Manche nehmen den Umsatz, andere die Komplexität. Uns hat die Komplexität überzeugt. RevOps brauchen Sie, wenn Marketing, Vertrieb und Customer Success jeweils andere Verantwortliche haben und der Forecast von Hand in einer Tabelle zusammengestückelt wird. Einen GTM-Engineer brauchen Sie erst, wenn die Daten stimmen und Sie merken, dass Menschen Wochen mit Arbeit verbringen, die ein System erledigen könnte. Die Anzeichen sehen so aus:

• Sie können nicht in einem Satz sagen, an wen Sie verkaufen. Es fehlt die GTM-Strategie. Eine Einstellung hilft hier nicht, nötig ist eine Entscheidung.
• Marketing und Vertrieb haben für dieselbe Sache unterschiedliche Zahlen, der Forecast liegt daneben und niemand traut dem CRM. Es fehlt RevOps.
• Die Daten sind in Ordnung, aber Vertrieb oder SDRs bauen Listen von Hand, reichern Kontakte an und kopieren Daten zwischen Tools. Es fehlt GTM-Engineering.
• Die Tools sprechen nicht miteinander und niemand ist für die Integrationen verantwortlich. Beginnen Sie mit RevOps, denn die Verantwortung muss klar sein, und GTM-Engineering übernimmt dann das Bauen.
• Sie wollen einen KI-Agenten im Vertrieb einsetzen. Zuerst RevOps (Regeln und Daten), danach GTM-Engineering.

Die Reihenfolge, die wir Kunden immer wieder empfehlen: erst Strategie, dann Daten und CRM (RevOps), dann Infrastruktur und Automatisierung (GTM-Engineering), und KI-Agenten zuletzt. Schritte lassen sich überspringen, das wird nur meist teuer. GTM-Engineering auf schmutzigen Daten erreicht schneller die falschen Unternehmen, und RevOps ohne GTM-Engineering hält Ordnung in einem System, das nichts Neues hervorbringt. Zur Auswahl und Einführung eines CRM siehe the CRM your team will actually use, zum Thema Forecast the risk-based sales forecast.

Kleine und mittlere Unternehmen: Zwei Einstellungen sind nicht sofort nötig

Für ein kleineres Vertriebsteam ist es meist nicht sinnvoll, zwei Spezialisten einzustellen. Drei Wege funktionieren: eine hybride Vollzeitstelle, jemand aus Marketing oder Vertrieb mit geschützter Kapazität oder ein externer Partner, der beide Rollen stundenweise abdeckt und ein fertiges System samt Dokumentation übergibt. Meist entscheiden die ersten sechs Monate. Zuerst Bereinigung und Regeln (RevOps), dann ein gut gebauter Workflow (GTM-Engineering) mit messbarem Ergebnis, etwa qualifizierten Meetings pro Woche.

Unsere Regel für die zweite Person: Stellen Sie sie ein, wenn der laufende Betrieb dauerhaft mehr als die Hälfte der Kapazität bindet. Bis dahin ist es günstiger und schneller, Know-how extern zu holen und mindestens eine Person im Haus zu haben, die versteht, was im System passiert. Für kleine Unternehmen lautet die richtige Antwort oft: schlichtes HubSpot oder Pipedrive und ein Workflow. Ein Stack, der Zehntausende im Monat kostet, bringt meist nur zusätzliche Komplexität. Bei der Toolauswahl beraten wir herstellerunabhängig, von HubSpot über Salesforce und Pipedrive bis Zoho und Odoo.

Was sich durch KI ändert

KI-Agenten vergrößern die Hebelwirkung eines GTM-Engineers: Eine Person baut, was früher ein Team erledigt hat. Sie vervielfachen aber auch Fehler. Ein Agent, der unter schlecht definierten Regeln ins CRM schreibt, erzeugt schneller schlechte Daten als jeder SDR. RevOps bleibt deshalb gefragt und wird zur Aufsichtsfunktion: Die Aufgabe lautet dann, Regeln und Datenqualität zu sichern und festzulegen, was ein Agent tun darf und was nicht. Deshalb stehen in unserem Angebot RevOps und CRM direkt neben KI und Automatisierung.

Wenn Sie sich das nächste Mal fragen, welche Rolle Sie brauchen, stellen Sie sich am Montagmorgen eine Frage: Was davon haben wir diese Woche öfter getan, als wir sollten: Entscheiden, Daten bereinigen oder Handarbeit? Die Antwort weist auf die passende Rolle.

Inspiration & Quellen: Gartner, Pressemitteilung zum Revenue-Operations-Modell (17. Mai 2021) · Bloomberry, I analyzed 1000 GTM Engineering jobs (2025, aktualisiert 2026) · Apollo, GTM Engineer vs RevOps: What Is The Difference Between Build And Run? · OnFire, GTM engineering data (Analyse von 209 Stellenanzeigen) · Databar, RevOps vs GTM Engineering: Which Role Should You Choose? · RevPartners, GTM Engineering vs RevOps · Gainsight, He Created a Job Title 1,000+ People Now Have ft. Yash Tekriwal (Clay) · Reddit, r/gtmengineering, Difference between GTM and RevOps, and what does each mean (Oktober 2026)

Das passt zu dem, was wir tun: RevOps & CRM, KI-Automatisierung und Go-to-Market-Strategie. Es baut auf Go-to-market engineering und Dark funnel auf.