GTM Foundations - The GTM Tech Stack: Six Layers, Selection Criteria and Integration Patterns
Most GTM stacks are not designed. They accumulate. A tool is bought to solve an urgent problem, it works, and three years later nobody can explain why lead routing happens in two systems or which of four sources is authoritative for company size.
The fix is to stop thinking in logos and start thinking in layers. This page sets out the six layers a revenue stack needs, what belongs in each, how to select tools without locking yourself in, and how to audit and consolidate a stack that has already sprawled.
7 min read5 sectionsGTM Foundations
What you'll take away
- Six layers: system of record, data, engagement, intelligence, orchestration, reporting. Most stacks over-invest in engagement and are missing orchestration entirely.
- Choose the CRM first and treat it as an architectural decision, not a procurement one. Everything downstream inherits its object model.
- Build reporting on a warehouse, not on the CRM. CRMs overwrite history; warehouses keep it.
- The integration layer is where value is created or lost. If nobody owns it, it is being done manually by someone who did not sign up for it.
The six layers
Every functioning revenue stack has these six layers, whether or not anyone named them. Naming them makes gaps visible.
- 1. System of record
- The CRM. Defines the object model — what an account is, what an opportunity is, how they relate. One system, one owner. The single decision that constrains everything else you will build for the next five years.
- 2. Data and enrichment
- Firmographic and technographic enrichment, identity resolution across form fills and product signups, deduplication, and a warehouse holding the history the CRM overwrites. This layer is where data quality is either created or permanently lost.
- 3. Engagement
- Marketing automation, email sequencing, calling, meeting scheduling, chat. The layer that touches the buyer. Well served by off-the-shelf tools, and the layer companies buy first and most.
- 4. Intelligence
- Product analytics, conversation intelligence, intent data, AI qualification. Converts raw behaviour into signals a human or a rule can act on. Only as good as layer 2 underneath it.
- 5. Orchestration
- Lead routing, scoring, lifecycle automation, alerting, SLA enforcement, data hygiene jobs. The layer that makes the others act as one system. Almost always partially missing, and the reason manual work persists.
- 6. Reporting
- BI built on the warehouse rather than on the CRM, so a field rename or a pipeline redesign does not invalidate last year's analysis. Includes the automated metric definitions from your KPI framework.
Run the diagnostic: list your tools and assign each to a layer. If layers 2 and 5 are thin or empty while layer 3 has four entries, you have found the reason your team spends its mornings on manual data work.
Choosing the system of record
The CRM decision is architectural. You are not buying features; you are adopting an object model that every downstream system will inherit. Three criteria matter more than the feature comparison.
- Object model fit
- Does the native model match how you actually sell? Multi-product, usage-based, partner-sourced and land-and-expand motions all strain a standard account-contact-opportunity model. Forcing a mismatch produces custom objects that break every integration you buy later.
- API quality and rate limits
- You will integrate more than you expect. Check bulk read and write throughput, event webhooks, sandbox availability and how schema changes are versioned. A CRM with a weak API silently caps everything you can build.
- Cost of exit
- Assume you will migrate in five to seven years. How exportable is the history, including field-level change logs? A system that cannot export its own audit trail is holding your analysis hostage.
How to evaluate any GTM tool
The same five questions apply whether you are buying an enrichment provider or a conversation intelligence tool. Feature checklists are the least useful part of a vendor evaluation.
Which layer does it belong to, and is that layer empty?
If the layer is already occupied, you are either replacing something or creating an overlap. Overlaps are where contradictory data comes from.
Can it write back to the system of record?
A tool that only reads creates a second source of truth. Insist on bidirectional sync, and check what happens on conflict — last-write-wins across two systems quietly corrupts data.
What is the failure mode?
When the integration breaks at 2am, does the queue retry, or are records silently dropped? Ask the vendor directly. The answer distinguishes a serious product from a demo.
Who will own it in six months?
Every tool needs an owner who understands its configuration. A tool with no owner drifts into a state nobody can explain, and its rules keep running anyway.
What does removing it look like?
If the logic lives entirely in the vendor's UI, removal means rebuilding from scratch. Prefer tools that let critical logic live in code or in your own database.
Integration patterns that hold up
How systems are connected matters more than which systems they are. Four patterns cover almost every situation, and mixing them carelessly is how stacks become unmaintainable.
| Pattern | Use when | Watch out for |
|---|---|---|
| Native integration | Both vendors support it and the field mapping matches your model | Limited field control; often no conflict handling and no error visibility |
| iPaaS / workflow tool | Low-volume, simple mappings, non-critical timing | Cost scales with volume; complex logic in a visual editor becomes unauditable |
| Warehouse-first with reverse ETL | You need one definition of truth across many systems | Requires a warehouse and someone who owns the models — the correct answer above roughly €10M ARR |
| Custom service | Business-critical logic, high volume, or logic that needs version control and tests | Needs engineering ownership; without it, you have built something nobody can maintain |
The practical rule: keep routing, scoring and any logic that touches revenue in code with tests and version history. Keep genuinely simple field syncs in whichever tool is cheapest. Problems start when business-critical logic ends up in a visual workflow that only one person understands and nobody has ever reviewed.
Auditing and consolidating an existing stack
Most teams reading this do not have a blank slate — they have twelve tools and a suspicion that four of them overlap. This audit takes a week and usually pays for itself immediately.
Inventory every tool with cost, owner and layer
Include the ones on someone's personal card. Tools with no named owner are the first candidates for removal, and there are always more of them than expected.
Map the data flows
For each field that matters — company size, industry, lifecycle stage, owner — trace which systems write it and in what order. Contradictory writes are your first fix, and they are usually the cause of the reporting disagreements.
Find the manual bridges
Every CSV export, copy-paste and "I check that every Monday" is a missing integration. List them with the hours they consume; this list is your automation backlog, priced.
Identify the overlaps
Two enrichment providers, two sequencers, routing in three places. Pick one per layer and decommission the rest — the licence saving is secondary to the reduction in contradictory data.
Fill the orchestration gap
Whatever the manual bridges list contains is what layer 5 should be doing. This is normally where the largest single return in the whole audit sits.
Set a review cadence
Re-run the inventory every six months. Stacks sprawl by default, and a scheduled review is far cheaper than a rebuild.
Frequently asked questions
What tools belong in a GTM tech stack?
- A complete stack covers six layers: a CRM as system of record, a data and enrichment layer with a warehouse, engagement tools for buyer contact, an intelligence layer for behavioural signals, an orchestration layer for routing and automation, and reporting built on the warehouse. Specific vendors matter less than making sure no layer is missing.
How many GTM tools should we have?
- Fewer than you have. The right count is one per layer plus whatever your motion genuinely requires. The warning sign is not the number of tools but the number of manual bridges between them — every CSV export is a missing integration.
Should reporting run on the CRM or a data warehouse?
- A warehouse. CRMs overwrite history: change a field definition or redesign a pipeline stage and last year's reports become uninterpretable. A warehouse keeps snapshots, which is what makes cohort and trend analysis possible at all.
When do we need a data warehouse for GTM?
- Once you have more than roughly three systems holding customer data, or as soon as anyone asks a question that requires comparing this quarter to the same quarter last year. In practice most B2B companies need one somewhere between €5M and €10M ARR.
Is an iPaaS enough, or do we need custom integrations?
- An iPaaS handles simple, low-volume field syncs well. Business-critical logic — routing, scoring, anything that decides who works a deal — belongs in code with tests and version history, because that logic needs to be auditable and reviewable when it produces a surprising result.
The orchestration layer is missing from most stacks
We build the integrations, routing logic and data pipelines that make a collection of tools behave like one system — with the logic in version control instead of a visual editor.