GTM is a system.
Built like a bridge

Field notes on GTM systems

Nine notes on how I think about revenue systems, and how the frameworks in the Practice actually get built. No fixed menu. Every engagement finds whatever manual work is blocking your GTM throughput, then automates it.

No engagement starts from a whiteboard

Every engagement starts from what the client already has: customer records, call recordings, delivery history. The patterns that sell next year are usually sitting in last year's data, unread. I extract them first, then decide what to build.

FIG. 00 . STARTING POINT -> WHAT EMERGES
Customer data + transcripts + delivery data -> pattern extraction -> eight branches
01 . WHAT THE CLIENT ALREADY HAS INPUT A Existing customer data Closed-won, closed-lost, churned INPUT B Call transcripts Sales, delivery and support calls INPUT C Delivery data Tasks, tickets, project history 02 . STEP 01 PATTERN EXTRACTION Who bought. Why they bought. What was delivered. What they said on calls. Anonymized. Read before anything is built. 03 . WHAT EMERGES . ONE BRANCH PER NOTE FIG. 01 System-enabled team Manual work, then the system FIG. 02 Signal-based outbound Signals, not static lists FIG. 03 Customer intelligence Every call compounds FIG. 04 Buying committee Who actually decides FIG. 05 Outbound engine Services firm, +150% leads FIG. 06 CRM reactivation 20,000 records, WhatsApp FIG. 07 ABM engagement stages Three stages, one rule FIG. 08 The roundtable dinner One roundtable, two returns EVERY ENGAGEMENT ADDS TO THE DATA IT STARTED FROM

The notes below are what tends to grow from that starting point. Each one is a branch, not a product. Which branches a client needs depends on what their data says, not on what I sell.

A manual team. A system-enabled one

The teams that scale aren't necessarily bigger. They're the ones who built systems that multiply what each person can do.
FIG. 01 . MANUAL CHAOS -> SYSTEM-ENABLED ORDER
Recreated in native system
A . MANUAL CHAOS INSTALL SYSTEM B . SYSTEM-ENABLED ORDER

The Manual team

Every account is researched by hand. Signals are noticed late, if at all. Leads go to whoever sees them first. Call notes live in someone's head. Each new hire adds capacity, and the same manual work with it.

The System-enabled team

Their market is monitored 24/7. Website visits trigger alerts with full account context. Every call is transcribed and analyzed for buying signals. Leads route to the right rep automatically, based on capacity, segment fit, and historical performance. Meeting prep and debriefs arrive before the AE finished their morning coffee.

Signal-based outbound

FIG. 02 . SIGNAL-BASED OUTBOUND
Data sources -> Processing -> Enrichment -> Activation, with feedback loop
01 . DATA SOURCES A Signal data B Trigger data C Intent data (1st + 3rd) 02 . DATA PROCESSING STEP 01 Company matching STEP 02 ICP scoring STEP 03 Signal scoring 03 . ENRICHMENT STEP 04 Contact enrichment STEP 05 Deep company research 04 . ACTIVATION CRM Enriched record CRM Enriched contacts CRM Deep research FEEDBACK LOOP A Meeting transcripts B Email + LinkedIn rates C Cold calls D Pipeline generated feeds back

I start from first principles. What problem do you solve? What data points connect to that problem? Then monitor everything: intent data (website visits, LinkedIn engagement, open-source activity), signal data (supply-chain changes, market volatility, operational shifts that indicate the problem exists or is getting worse), and trigger data (job changes, funding, expansion that creates buying windows).

Targets appear when the problem exists or changes, when they're showing awareness, or when a window opens. Not from static demographic lists.

Customer intelligence

Mimics how humans learn. Every customer interaction generates hypotheses. Every new data point validates or rejects them. After each call, an agent classifies the conversation, reads existing hypotheses, generates new ones, updates the database. All reps' learnings compound into one continuously validated knowledge base.

FIG. 03 . CUSTOMER INTELLIGENCE LOOP
Call -> Classify -> Hypothesis loop -> Compounding DB
INPUT New meeting or call 01 . CLASSIFICATION A Meeting type B Company C Contact 02 . AGENTIC LOOP . HYPOTHESIS BUILDER / VALIDATOR STEP 01 Read previous hypotheses STEP 02 Generate new hypotheses STEP 03 Validate, reject, update STORE DB . all hypotheses GTM QUERIES THIS

Critical for finding product-market fit faster. Every other system queries this for "what's true about this company or persona?" - your GTM runs on validated intelligence, not static assumptions.

Buying committee mapping

Pull all contacts broadly - cast wide net - store in database. An agent then selects the actual buying committee using customer intelligence plus real-time LinkedIn data.

Enterprise titles don't map to roles consistently. "VP Platform" at one company is "Head of Engineering" at another. 2 to 3 hours of research per account, automated, catches personas you'd miss manually. Particularly useful in Enterprise motions.

FIG. 04 . BUYING COMMITTEE MAPPING
Trigger -> Broad pull -> Upsert -> Agent selection (with DB + LinkedIn) -> Committee
EVENT Trigger STEP 01 Pull all contacts for company broadly filtered STEP 02 Upsert to DB STEP 03 . AGENT Agentic persona selection context, not keywords OUTPUT Persona-based contact selection SOURCE A Customer intelligence DB SOURCE B Real-time LinkedIn data

The agent understands context, not just keywords. This is where Customer Intelligence pays back: every prior conversation informs which title, at which company, in which market, is actually on the committee.

The outbound engine

A services firm in a saturated outbound market. Every competitor bought the same lists and wrote the same emails. The one asset nobody else could buy was the firm's own delivery history: 6,000 tasks describing who they had helped, with what, and why it worked.

A services firm in a saturated outbound market had one asset no competitor had: 6,000 delivery tasks. I anonymized them and read them for patterns next to the customer records and call transcripts. The patterns named verticals the firm had never marketed to, and redrew the ICPs it already had. The messaging was rewritten from the words clients used on calls, not from the service catalogue.

FIG. 05 . OUTBOUND ENGINE
Input -> Analysis -> Rewrite -> Test -> Landing -> TAM -> Outcome
01 . INPUT 02 . ANALYSIS 03 . REWRITE 04 . TEST 05 . LANDING 06 . TAM 07 . OUTCOME SOURCE A Customer data SOURCE B Call transcripts SOURCE C Delivery data STEP 01 Pattern extraction 6,000 anonymized delivery tasks, read for who bought and why STEP 02 New verticals surfaced STEP 03 ICPs redefined STEP 04 Messaging rewritten STEP 05 . LOOP New-vertical tests Small sends, one vertical at a time NO SIGNAL . REWRITE AGAIN WINS STEP 06 1:1 landing page per ICP Written for one buyer and nobody else STEP 07 TAM sequences 10,000-100,000 recipients a month, only after steps 01-06 RESULT +150% outbound-sourced leads WHY IT CANNOT BE COPIED A Competitors buy the same lists Nobody else has this firm's delivery history B Generic messaging is written from the catalogue This messaging is written from clients' own words C Volume usually comes first Here volume comes last, on a tested message REPLIES AND MEETINGS FEED THE NEXT READ

Each new vertical was tested before it was scaled. The ones that answered got a landing page per ICP, written for that buyer and nobody else. Only then did volume come in: TAM sequences reaching 10,000 to 100,000 recipients a month. Outbound-sourced leads rose 150%.

The order matters more than the tooling. Volume on a generic message is noise. Volume on a message built from your own delivery data is a campaign a competitor cannot copy, because they do not have the data.

A dead CRM, read before anyone writes to it

A client had 20,000 contacts sitting dormant in a B2C CRM. The usual move is a blast, then a support queue. I built an agent that read each record first: what the contact had done, when, and what state they were left in. The record decided the message, not the campaign calendar.

FIG. 06 . DEAD-CRM REACTIVATION LOOP
State check -> Agent read -> Segment -> WhatsApp cadence -> Status update
01 . STATE INPUT 20,000 dormant records B2C CRM, untouched 02 . CHECK STEP 01 CRM state check What state was each contact left in 03 . READ STEP 02 Agent reads the record History, last action, notes, before any send 04 . SEGMENT STEP 03 Segment by what it found The record decides the message, not the calendar 05 . SEND STEP 04 WhatsApp cadence One channel the contact already uses STORE Status update written back to the CRM NEXT PASS STARTS FROM THE NEWER STATE RESULT . 20K CONTACTS REACHED ON WHATSAPP . NO SUPPORT SPIKE

Every reply writes back to the record, so the next pass starts from a newer state than the last one. 20k contacts reached on WhatsApp. No spike in customer support.

Hundreds. Dozens. A handful

Account-based work fails when every account gets the same attention. I split every target list into three stages and let evidence, not the calendar, move an account between them. Enterprise deals here can take twelve months or more, so the system is built to stay visible for a year, not to close in a week.

FIG. 07 . ABM . CLUSTER ICP -> FUTURE PIPELINE -> ACTIVE FOCUS
Three stages + engagement stage + the no-reply rule
STAGE 01 Cluster ICP HUNDREDS OF ACCOUNTS Unaware of us, or engaged long ago with someone who has since left. ENTERS WHEN Firmographic and technographic fit + one use-case signal GOAL Awareness. Tie our people to their strategic challenges. STAGE 02 Future Pipeline DOZENS Aware and engaged. No insight into the need yet. MOVES WHEN Any awareness signal: 2+ visits to key pages, event sign-up, a two-way conversation, a mutual connection GOAL Nurture. Build trust. Validate the need. STAGE 03 Active Focus A HANDFUL A proven need, awareness of us, and a relationship. MOVES WHEN A buying signal + a relationship criterion GOAL A known challenge, then a meeting with sales. ENGAGEMENT STAGE . THE ONE FIELD THAT MOVES EVERY WEEK 01 Not touched 02 Cold 03 Cold . engaged 04 Future Pipeline 05 Active Focus EXIT Not interested NO REPLY . DEAL REMOVED . BACK TO COLD OR FUTURE TIER DECIDES DEPTH . TIER 1 . DINNERS OR A 1:1 PAGE . TIER 3 . LIGHT, AUTOMATED TOUCHES

One rule does most of the work: an account enters Active Focus only once a challenge is known. If the prospect goes quiet, the deal is removed and the account goes back a stage. It keeps the pipeline honest, and it keeps the hours on the accounts that have earned them.

Tier decides depth. A Tier 1 account may get a dinner or a page of its own. A Tier 3 account gets light, automated touches. Same system, different spend.

One roundtable. Two returns

A roundtable over a Michelin-star dinner costs €1,500 to €4,500 to run. Nine attendees. The evening is the smallest part of the work: challenges collected in advance, a research profile on every guest, seats planned around shared problems.

FIG. 08 . THE EXECUTIVE DINNER . RETURN CURVE
T0 dinner -> follow-up cadence -> returns at +2 and +8 months
BEFORE . T-4 WEEKS INVITE 10-14 senior buyers COLLECT challenges in advance RESEARCH a profile per guest SEAT by shared problems T0 +1MO +2MO +3MO +4MO +5MO +6MO +7MO +8MO +9MO T0 . THE DINNER Michelin-star room 9 attendees €1,500-€4,500 to run Thank-you, takeaways, every guest's LinkedIn Content hub teaser their challenges, back Challenge insights one, then two RETURN 01 . +2 MONTHS 1 attendee signs a €50k proposal RETURN 02 . +8 MONTHS Inbound from a €500M account Never attended the dinner THE ACCOUNT THAT DECLINED Invited, declined, kept in every follow-up for eight months.

The first return came at two months: one attendee signed a €50k proposal. The second came at eight months: a €500M account that never came to the dinner signed a €150k deal. They had been invited, declined, and stayed in every follow-up since.

The dinner was the reason to write. The follow-ups were the reason they remembered.

Closing note

Nine notes. One throughline

Every note starts in the same place: the data a client already has. GTM throughput is a system property, not a heroics property. Manual chaos becomes system-enabled order when the right constraint is identified and the right loop is installed. The Practice is where this work is done for one client at a time. The Playbooks are where the same frameworks are made self-serve for everyone else.

Initiate a dialogue if the fit is there. Or read the practice first.