GTM-Architektur: die fünf Schichten, die ein B2B-System braucht

Die Frage hinter der Frage

„Welche Schichten braucht eine GTM-Architektur?” wird selten aus Neugier gestellt. Sie wird gestellt, wenn ein Stack über Jahre gewachsen ist, fünf Werkzeuge dasselbe halb können, und niemand mehr sagen kann, warum letztes Quartal funktioniert hat, was dieses Quartal nicht mehr funktioniert.

Der übliche Reflex ist, ein weiteres Werkzeug zu kaufen. Der hilfreichere Schritt ist, das Vorhandene einmal in Schichten zu sortieren — und zu sehen, welche fehlt. Dieser Artikel beschreibt die fünf Schichten, was in jede gehört, und woran man im Alltag merkt, dass eine davon nicht existiert.

Stack ist nicht Architektur

Ein Stack ist eine Liste. Enrichment, Sequencer, CRM, Datenanbieter, dazwischen ein paar Automationsbrücken. Alles steht nebeneinander, jedes Werkzeug hält seine eigene Wahrheit über denselben Kunden, und die Verbindung zwischen ihnen ist ein Datenabgleich.

Eine Architektur ist eine Ordnung mit Richtung: Wissen liegt unter der Ausführung, nicht neben ihr. Was eine Kampagne lernt, verändert die nächste, ohne dass ein Mensch es überträgt. Warum ein fragmentierter Stack genau daran scheitert, ist in Fragmentierter Sales-Stack: Warum Ihr Wissen verloren geht ausgeführt.

Die fünf Schichten

01 — Control: die Oberfläche, über die bedient wird

Hier wird gesteuert: als Weboberfläche, als Kommandozeile, als Kopilot im Arbeitskontext. Control ist keine Sammlung von Funktionen, sondern die Frage, wer das System bedienen kann. Dazu weiter unten mehr, denn an dieser Schicht entscheidet sich gerade am meisten.

02 — Knowledge: was über den Markt bekannt ist

Zwei Dinge gehören hierher. Erstens der Wissensstand selbst: ideales Kundenprofil, Personas, Kaufsignale, Angebote, Positionierung, Belege — und was sich davon in der Praxis als wirksam erwiesen hat. Zweitens die wiederverwendbaren Abläufe, die dieses Wissen anwendbar machen.

Diese Schicht ist der Unterschied zwischen einem System, das jede Kampagne neu beginnt, und einem, das mit jeder besser wird. Warum ein CRM diese Rolle nicht übernimmt, steht in CRM vs. GTM-System.

03 — Data: die Objekte, mit denen gearbeitet wird

Datensätze zu Firmen und Kontakten, Tabellen als Arbeitsfläche, Nachrichten und deren Verläufe, erkannte Signale, Auswertungen, Kategorisierungen. Entscheidend ist weniger, welche Objekte es gibt, als dass es eine Data-Schicht gibt statt sieben halbe.

04 — Action: was tatsächlich passiert

Sequenzen, Agenten, Workflows — und, oft vergessen, deren Beobachtbarkeit. Eine Ausführungsschicht ohne Observability ist eine Blackbox: Sie merkt niemand, wenn eine Sequenz seit drei Wochen ins Leere läuft, weil ein Sendekonto stillschweigend blockiert wurde.

05 — External: die angebundene Aussenwelt

Outreach-Kanäle, Datenquellen und Signalanbieter, CRM und Kalender, Werbeplattformen. Diese Systeme gehören nicht zur Architektur — sie werden von ihr bedient. Der Unterschied ist wichtig: Wer sein CRM zur Mitte seiner GTM-Architektur macht, hat eine Architektur mit einer Aktenablage im Zentrum.

Warum die Control-Schicht gerade entscheidet

Jahrelang war die Frage an eine GTM-Oberfläche: Wie schnell findet sich ein Mensch zurecht? Diese Frage ist nicht falsch geworden, aber sie ist nicht mehr die einzige.

Mit dem Model Context Protocol hat Anthropic Ende 2024 einen offenen Standard dafür veröffentlicht, wie ein Modell strukturiert auf externe Werkzeuge zugreift, statt für jede Anbindung eine eigene Integration zu brauchen. Coding-Agenten wie Claude Code oder Codex arbeiten inzwischen so: Sie rufen Funktionen fremder Systeme auf, wenn diese Systeme eine maschinenlesbare Oberfläche anbieten.

Für GTM hat das eine unbequeme Folge. Ein System ohne solche Oberfläche ist für diese Arbeitsweise unsichtbar — egal wie gut seine Ausführungsschicht ist. Wer seinen Vertrieb aus derselben Umgebung steuern will, in der ohnehin schon gearbeitet wird, braucht ein GTM-System, das sich ansprechen lässt, nicht nur anklicken.

Das ist auch der Grund, warum die Control-Schicht in diesem Modell oben steht und nicht als Nebenaspekt der Ausführung geführt wird. Sie ist die Schicht, die bestimmt, wer das System überhaupt bedienen kann.

Prüfliste: welche Schicht fehlt bei Ihnen?

Vier Symptome, vier Diagnosen. Gehen Sie sie der Reihe nach durch — jedes trifft zu oder nicht, ohne Zwischenstufen.

1. Jede Kampagne beginnt bei null. Der beste Aufhänger des letzten Quartals steckt im Kopf der Person, die ihn geschrieben hat. Neue Mitarbeitende lernen ihn nicht aus dem System, sondern im Gespräch. → Knowledge fehlt.

2. Zwei Systeme widersprechen sich über denselben Kontakt. Das CRM sagt „kein Interesse”, das Outreach-Tool sequenziert weiter, und niemand weiss, welcher Stand gilt. → Eine gemeinsame Data-Schicht fehlt.

3. Ausfälle fallen erst im Reporting auf. Eine Sequenz lief drei Wochen ins Leere, ein Sendekonto war blockiert, die Zahlen sahen nur „etwas schwächer” aus. → Observability in der Action-Schicht fehlt.

4. Jede Änderung ist Klickarbeit. Eine neue Zielgruppe anzulegen heisst: Oberfläche öffnen, durchklicken, wiederholen. Nichts davon lässt sich aus der Umgebung heraus anstossen, in der Ihr Team ohnehin arbeitet. → Control fehlt.

Wer bei mehr als einem Punkt zustimmt, hat kein Werkzeugproblem, sondern ein Architekturproblem. Ein weiteres Werkzeug macht es dann schlimmer, nicht besser.

Die Reihenfolge beim Aufbau

Eine Architektur entsteht nicht dadurch, dass alle fünf Schichten gleichzeitig gebaut werden. In der Praxis trägt diese Reihenfolge:

1. Data zuerst — eine Wahrheit über Firmen und Kontakte, bevor irgendetwas ausgeführt wird.
2. Knowledge daneben — ICP und Kaufsignale explizit machen, statt sie implizit zu lassen.
3. Action darauf — Sequenzen und Agenten, die auf beidem aufsetzen, mit Beobachtbarkeit von Anfang an.
4. Control zuletzt, aber nicht als Nachgedanke — die Oberfläche für Mensch und Agent.
5. External laufend — Anbindungen kommen und gehen; sie sind austauschbar, wenn die vier Schichten darunter stimmen.

Der häufigste Fehler ist, bei 3 anzufangen, weil Ausführung sichtbar ist und Wissen nicht. Das Ergebnis ist ein System, das viel tut und wenig lernt.

Wo wir ansetzen

CegTec baut und betreibt genau diese Architektur für B2B-Unternehmen im DACH-Raum — als GTM-Infrastruktur, nicht als weiteres Tool neben den bestehenden. Der Teil, den wir am häufigsten übernehmen, ist nicht die Ausführung, sondern die Implementierung: den gewachsenen Stack in Schichten sortieren, Wissen aus Köpfen ins System holen, Ausführung darauf aufsetzen — und die Control-Schicht so bauen, dass sie sich aus der Umgebung bedienen lässt, in der Ihr Team ohnehin arbeitet, Coding-Agenten eingeschlossen.

Was das System leistet und wo seine Grenzen liegen, steht in Agentic GTM: System statt Outbound-Tool. Wer lieber selbst baut, findet die ehrliche Grenzziehung in Sales-Stack selbst orchestrieren.

Selbst ausprobieren: Jeder neue Workspace startet mit vier kostenlosen Wochen — kostenlos testen.

Quellen

• Model Context Protocol — Spezifikation und Einführung, Anthropic, veröffentlicht November 2024
• Claude Code — Dokumentation, Anthropic
• OpenAI Codex, OpenAI

Die Schichten- und Primitive-Darstellung in diesem Artikel beschreibt das Modell auf Konzeptebene. Implementierungsdetails der CegTec-Plattform sind nicht Gegenstand des Artikels.