Clay Club Berlin turned two on 26 August. Around a hundred GTM operators, founders, and RevOps people in one room, a panel of folks from Productsup, ElevenLabs, Langdock, and Moss, and a birthday cake shaped like a teddy bear somewhere in the back. I was on stage for fifteen minutes with a talk called "From 20 Tools to One Revenue OS: what GTM engineering looks like in 2026."
This post is the idea from that talk, written for teams wondering whether it applies to them. Spoiler: if you run revenue through more than a handful of tools, it does.
The problem every GTM team recognises
Here is how most GTM teams actually work today. Website intent in one tool. LinkedIn engagement in another. Webinar attendees in a spreadsheet. Lead magnet downloads, demo bookings, trial signups, PLG signups, offline events, calendar meetings. Every signal lives in its own tab, and someone handles each one individually, then moves on to the next.
At any real volume this stops being work a human can do. At Peec, where I run GTM engineering, the monthly signal count is a five figure number. Yours might be smaller, but the shape of the problem is the same: far more signals than anyone can read, and the expensive ones drowning in the cheap ones.
The deeper problem is what happens every time a team wants a new workflow. Pick a tool, which means a new login and new billing. Rebuild the ICP rules from scratch. Rebuild the routing from scratch. Wire up a new chain of automations. And then nobody maintains it after month two. You end up with the same logic duplicated ten times and drifting apart, no shared memory of any account, and zero idea which channel deserves the credit.
What a revenue OS actually is
It is not another tool in the stack. It is the spine underneath the stack. Signals come in from every channel. Decisions happen in the middle. Actions go out. And the logic that drives all of it, your ICP rules, your routing, your attribution, is defined once, in one place, instead of rebuilt inside every tool that needs it.
Your CRM stays exactly where it is. A revenue OS never competes with the CRM, it feeds it. The CRM remains the source of truth that sales lives in; the OS is the layer that decides what deserves to reach it and in what shape.
The part that surprises people: AI barely runs anything day to day. Every decision, qualification, stacking, routing, attribution, runs on predefined logic. Deterministic rules that produce the same answer every time and can be audited when someone asks why a lead went where it went. Where AI changes the game is configuration: encoding those complex decision workflows used to take a quarter of engineering time, and now it takes days. That is a one time cost. Once configured, the workflows run by themselves.
That distinction matters more than it sounds. A system that makes fresh AI judgment calls on every lead is a system nobody can audit and no rev leader will bet a quarter on. A system built with AI but run on rules is one you can explain to your board.
What it feels like to work on top of one
The best way I found to explain it on stage was to follow one signal through.
A signal lands, from any channel. It gets qualified against the ICP automatically, no human reads it. It stacks with every other signal from the same account, because the third touch from one company means something the first touch never did. When an account crosses the line, one click turns it into a properly routed lead. And when the meeting happens, the rep walks in with a brief that was ready before they poured their coffee.
Multiply that by every signal, every account, every rep, every day. That is the difference between a team that reacts to whatever surfaced in a tab this morning and a team that always works the most valuable thing in the queue.
One spine, four teams
This was the part I most wanted the room to take home: a revenue OS is not a sales tool. The same spine serves every function that touches a customer.
Think about what the four revenue teams actually do all day. Sales decides who deserves the next call. Marketing tries to prove which campaign deserved the credit. Product growth tries to catch signups while they are still warm. Customer success tries to spot trouble before the renewal conversation. Four different jobs on paper, but underneath they are the same job: watch the signals, work out what they mean, and act on the right ones in time.
Today each team does that job on its own island, with its own tools, its own copy of the rules, and its own version of every account. That is why the same company can be a hot lead for sales, an unattributed conversion for marketing, and a silent churn risk for customer success, all in the same week, with nobody seeing the whole picture.
Put those jobs on one spine and the work does not just get faster, it changes character. Attribution stops being a quarterly argument and becomes a number that is simply there every morning, computed from the same data everyone already trusts. A churn signal stops being a dashboard someone must remember to check and becomes the system tapping the right person on the shoulder, with the context attached. A trial signup stops waiting in a queue and is qualified and routed the moment it happens. Nothing depends on somebody remembering to look. The system watches everything all the time, and people only get pulled in when there is something worth their judgment.
And it is more controlled, not less. When the rules live in one place, changing your ICP definition or your routing logic is one edit that flows through everywhere at once. Today that same change is a migration project across ten tools, and half of them never get updated. One spine means one place where the truth is defined, one place to audit, and one place to improve.
That is where the "20 tools to one" in the title comes from, and it is also where the compounding starts: the first workflow is the expensive one, and every workflow after it plugs into the spine. Tools do not compound. Systems do.
What I did not expect
I came to share a point of view on the state of GTM in 2026. What I did not expect was how little of it was mine.
No consensus, no playbook, nobody decided this. And yet GTM engineers at completely unrelated companies have landed in the same place: stop waiting for the right product to exist, and build the thing your motion actually needs. Not assembling tools. Building.
The questions afterwards told the story better than my talk did. Nobody asked whether it was possible. Everyone asked how to ship it.
The part that did not get easier
The floor dropped, and anyone can get to a prototype in an afternoon now. What did not get easier is getting a revenue team to actually run on something you built. That is not an engineering problem. It is the unglamorous layer underneath: permissions, audit trails, the thing still working in month six, someone owning it and answering for it the morning it breaks. Whoever builds a revenue OS becomes a product owner, whatever their title says.
Generating the code got cheap. Earning the trust to depend on it did not. Six months into building this at Peec, that is still the hardest and best part of the job.
Thank you, Clay Club
Two years of Clay Club Berlin is a real achievement, and the room showed it. Thanks to Taimoor, Nicolas, and Munnawar for the room, and to Moritz "Molo" Lorenz (Moss), Elmar Schaaf (Langdock), Oscar Lance (ElevenLabs), and Paul Kallenberger (Productsup) for a panel worth staying for. The conversations after the talk were the best part of the night.
If you are wondering what a revenue OS would look like on your own stack, that is exactly what Ziel Lab does for B2B teams: we audit what you have, find where the signals are leaking, and build the system that catches them. A good place to start is a second opinion on your current setup.