GTM-Grundlagen - Der GTM-Tech-Stack: Sechs Schichten, Auswahlkriterien und Integrationsmuster
Die meisten GTM-Stacks werden nicht entworfen, sie wachsen an. Ein Tool wird für ein dringendes Problem gekauft, es funktioniert — und drei Jahre später kann niemand erklären, warum Lead-Routing in zwei Systemen stattfindet oder welche von vier Quellen für die Unternehmensgröße maßgeblich ist.
Die Lösung: aufhören, in Logos zu denken, und anfangen, in Schichten zu denken. Diese Seite beschreibt die sechs Schichten, die ein Revenue-Stack braucht, was in jede gehört, wie Sie Tools auswählen, ohne sich einzusperren, und wie Sie einen bereits gewucherten Stack prüfen und konsolidieren.
6 Min. Lesezeit5 AbschnitteGTM-Grundlagen
Das nehmen Sie mit
- Sechs Schichten: System of Record, Daten, Engagement, Intelligence, Orchestrierung, Reporting. Die meisten Stacks überinvestieren in Engagement und haben Orchestrierung gar nicht.
- Wählen Sie das CRM zuerst und behandeln Sie es als Architektur-, nicht als Einkaufsentscheidung. Alles Nachgelagerte erbt sein Objektmodell.
- Bauen Sie Reporting auf einem Warehouse, nicht auf dem CRM. CRMs überschreiben Historie, Warehouses bewahren sie.
- Die Integrationsschicht entscheidet über Wert oder Verlust. Verantwortet sie niemand, erledigt sie gerade jemand manuell, der sich dafür nicht gemeldet hat.
Die sechs Schichten
Jeder funktionierende Revenue-Stack hat diese sechs Schichten, ob sie jemand benannt hat oder nicht. Sie zu benennen macht Lücken sichtbar.
- 1. System of Record
- Das CRM. Definiert das Objektmodell — was ein Account ist, was eine Opportunity ist, wie sie zusammenhängen. Ein System, ein Verantwortlicher. Die eine Entscheidung, die alles einschränkt, was Sie in den nächsten fünf Jahren bauen.
- 2. Daten und Enrichment
- Firmografische und technografische Anreicherung, Identitätsauflösung über Formulare und Produkt-Signups, Deduplizierung und ein Warehouse, das die Historie hält, die das CRM überschreibt. Hier entsteht Datenqualität — oder geht dauerhaft verloren.
- 3. Engagement
- Marketing-Automation, E-Mail-Sequencing, Telefonie, Terminbuchung, Chat. Die Schicht, die den Käufer berührt. Gut durch Standardtools abgedeckt — und die Schicht, die Unternehmen zuerst und am meisten kaufen.
- 4. Intelligence
- Produktanalytik, Conversation Intelligence, Intent-Daten, KI-Qualifizierung. Wandelt Rohverhalten in Signale, auf die ein Mensch oder eine Regel reagieren kann. Nur so gut wie Schicht 2 darunter.
- 5. Orchestrierung
- Lead-Routing, Scoring, Lifecycle-Automatisierung, Alerting, SLA-Durchsetzung, Datenhygiene-Jobs. Die Schicht, die die anderen als ein System handeln lässt. Fast immer teilweise nicht vorhanden — und der Grund, warum Handarbeit bleibt.
- 6. Reporting
- BI auf dem Warehouse statt auf dem CRM, damit eine Feldumbenennung oder ein Pipeline-Umbau die Analysen des Vorjahres nicht entwertet. Enthält die automatisierten Kennzahlendefinitionen aus Ihrem KPI-Rahmen.
Machen Sie die Diagnose: Listen Sie Ihre Tools auf und ordnen Sie jedes einer Schicht zu. Sind Schicht 2 und 5 dünn oder leer, während Schicht 3 vier Einträge hat, kennen Sie den Grund, warum Ihr Team seine Vormittage mit manueller Datenarbeit verbringt.
Das System of Record auswählen
Die CRM-Entscheidung ist eine Architekturentscheidung. Sie kaufen keine Features, Sie übernehmen ein Objektmodell, das jedes nachgelagerte System erbt. Drei Kriterien zählen mehr als der Feature-Vergleich.
- Passung des Objektmodells
- Passt das native Modell dazu, wie Sie tatsächlich verkaufen? Multi-Produkt-, nutzungsbasierte, partnergenerierte und Land-and-Expand-Mechaniken strapazieren ein Standardmodell aus Account, Kontakt und Opportunity. Eine erzwungene Fehlpassung erzeugt Custom Objects, die jede später gekaufte Integration brechen.
- API-Qualität und Rate Limits
- Sie werden mehr integrieren, als Sie denken. Prüfen Sie Bulk-Lese- und Schreibdurchsatz, Event-Webhooks, Sandbox-Verfügbarkeit und wie Schemaänderungen versioniert werden. Ein CRM mit schwacher API begrenzt still alles, was Sie bauen können.
- Ausstiegskosten
- Nehmen Sie an, dass Sie in fünf bis sieben Jahren migrieren. Wie exportierbar ist die Historie, inklusive feldbezogener Änderungsprotokolle? Ein System, das seinen eigenen Audit-Trail nicht exportieren kann, hält Ihre Analyse fest.
Wie Sie jedes GTM-Tool bewerten
Dieselben fünf Fragen gelten, ob Sie einen Enrichment-Anbieter oder ein Conversation-Intelligence-Tool kaufen. Feature-Checklisten sind der am wenigsten nützliche Teil einer Anbieterbewertung.
Zu welcher Schicht gehört es, und ist diese Schicht leer?
Ist die Schicht bereits besetzt, ersetzen Sie entweder etwas oder schaffen eine Überschneidung. Überschneidungen sind die Quelle widersprüchlicher Daten.
Kann es in das System of Record zurückschreiben?
Ein Tool, das nur liest, erzeugt eine zweite Wahrheitsquelle. Bestehen Sie auf bidirektionalem Sync und prüfen Sie das Verhalten bei Konflikten — Last-Write-Wins über zwei Systeme hinweg korrumpiert Daten leise.
Wie sieht der Fehlerfall aus?
Wenn die Integration nachts um zwei bricht: Wird die Queue erneut versucht oder werden Datensätze still verworfen? Fragen Sie den Anbieter direkt. Die Antwort unterscheidet ein ernsthaftes Produkt von einer Demo.
Wer verantwortet es in sechs Monaten?
Jedes Tool braucht einen Verantwortlichen, der seine Konfiguration versteht. Ein Tool ohne Verantwortlichen driftet in einen Zustand, den niemand erklären kann — und seine Regeln laufen trotzdem weiter.
Wie sieht ein Ausbau aus?
Liegt die Logik vollständig in der Anbieter-UI, bedeutet Entfernen einen Neuaufbau. Bevorzugen Sie Tools, bei denen kritische Logik in Code oder in Ihrer eigenen Datenbank leben kann.
Integrationsmuster, die tragen
Wie Systeme verbunden sind, zählt mehr als welche Systeme es sind. Vier Muster decken nahezu jede Situation ab — sie unbedacht zu mischen macht Stacks unwartbar.
| Muster | Einsetzen wenn | Achten auf |
|---|---|---|
| Native Integration | Beide Anbieter unterstützen sie und das Feld-Mapping passt zu Ihrem Modell | Begrenzte Feldkontrolle; oft keine Konfliktbehandlung und keine Fehlersichtbarkeit |
| iPaaS / Workflow-Tool | Geringe Volumina, einfache Mappings, unkritisches Timing | Kosten skalieren mit Volumen; komplexe Logik in einem visuellen Editor wird unprüfbar |
| Warehouse-first mit Reverse ETL | Sie brauchen eine Wahrheitsdefinition über viele Systeme hinweg | Erfordert ein Warehouse und jemanden, der die Modelle verantwortet — oberhalb von rund 10 Mio. € ARR die richtige Antwort |
| Eigener Service | Geschäftskritische Logik, hohe Volumina oder Logik, die Versionskontrolle und Tests braucht | Braucht Engineering-Verantwortung; ohne sie haben Sie etwas gebaut, das niemand warten kann |
Die praktische Regel: Routing, Scoring und jede Logik, die Umsatz berührt, gehören in Code mit Tests und Versionshistorie. Wirklich einfache Feld-Syncs gehören in das jeweils günstigste Tool. Probleme beginnen, wenn geschäftskritische Logik in einem visuellen Workflow landet, den nur eine Person versteht und den nie jemand geprüft hat.
Bestehenden Stack prüfen und konsolidieren
Die meisten Leserinnen und Leser haben kein leeres Blatt, sondern zwölf Tools und den Verdacht, dass vier davon sich überschneiden. Dieses Audit dauert eine Woche und rechnet sich meist sofort.
Alle Tools mit Kosten, Verantwortlichem und Schicht inventarisieren
Auch die auf der Privatkarte. Tools ohne benannten Verantwortlichen sind die ersten Streichkandidaten — und es sind immer mehr, als erwartet.
Datenflüsse abbilden
Für jedes relevante Feld — Unternehmensgröße, Branche, Lifecycle-Phase, Verantwortlicher — nachvollziehen, welche Systeme es in welcher Reihenfolge schreiben. Widersprüchliche Schreibvorgänge sind die erste Korrektur und meist die Ursache der Reporting-Widersprüche.
Manuelle Brücken finden
Jeder CSV-Export, jedes Copy-Paste und jedes "das prüfe ich montags" ist eine fehlende Integration. Listen Sie sie mit dem Zeitaufwand auf — diese Liste ist Ihr Automatisierungs-Backlog, bereits bepreist.
Überschneidungen identifizieren
Zwei Enrichment-Anbieter, zwei Sequencer, Routing an drei Stellen. Wählen Sie eines je Schicht und schalten Sie den Rest ab — die Lizenzersparnis ist zweitrangig gegenüber der Reduktion widersprüchlicher Daten.
Die Orchestrierungslücke füllen
Was auf der Liste manueller Brücken steht, ist genau das, was Schicht 5 tun sollte. Hier liegt normalerweise der größte Einzelnutzen des gesamten Audits.
Review-Taktung festlegen
Inventar alle sechs Monate wiederholen. Stacks wuchern von selbst, und ein geplanter Review ist weit günstiger als ein Neuaufbau.
Häufige Fragen
Welche Tools gehören in einen GTM-Tech-Stack?
- Ein vollständiger Stack deckt sechs Schichten ab: ein CRM als System of Record, eine Daten- und Enrichment-Schicht mit Warehouse, Engagement-Tools für den Käuferkontakt, eine Intelligence-Schicht für Verhaltenssignale, eine Orchestrierungsschicht für Routing und Automatisierung sowie Reporting auf dem Warehouse. Konkrete Anbieter zählen weniger als die Vollständigkeit der Schichten.
Wie viele GTM-Tools sollten wir haben?
- Weniger als Sie haben. Die richtige Zahl ist eines je Schicht plus das, was Ihre Mechanik wirklich erfordert. Das Warnsignal ist nicht die Anzahl der Tools, sondern die Anzahl manueller Brücken dazwischen — jeder CSV-Export ist eine fehlende Integration.
Sollte Reporting auf dem CRM oder einem Warehouse laufen?
- Auf einem Warehouse. CRMs überschreiben Historie: Ändern Sie eine Felddefinition oder gestalten Sie eine Pipeline-Phase um, werden die Reports des Vorjahres uninterpretierbar. Ein Warehouse hält Snapshots — erst das macht Kohorten- und Trendanalysen überhaupt möglich.
Wann brauchen wir ein Data Warehouse für GTM?
- Sobald mehr als etwa drei Systeme Kundendaten halten oder sobald jemand eine Frage stellt, die dieses Quartal mit demselben Quartal des Vorjahres vergleicht. Praktisch brauchen die meisten B2B-Unternehmen eines zwischen 5 und 10 Mio. € ARR.
Reicht ein iPaaS oder brauchen wir eigene Integrationen?
- Ein iPaaS deckt einfache Feld-Syncs mit geringem Volumen gut ab. Geschäftskritische Logik — Routing, Scoring, alles, was entscheidet, wer an einem Deal arbeitet — gehört in Code mit Tests und Versionshistorie, weil diese Logik prüfbar sein muss, wenn sie ein überraschendes Ergebnis liefert.
Die Orchestrierungsschicht fehlt in den meisten Stacks
Wir bauen die Integrationen, Routing-Logik und Datenpipelines, die aus einer Tool-Sammlung ein System machen — mit der Logik in der Versionskontrolle statt in einem visuellen Editor.