The GTM Launchpad is where we open the hood on B2B revenue - fixing structure, sharpening outbound and building pipeline that actually holds up

I spent Wednesday at ApolloNext in San Francisco looking at where GTM technology is going. Then Thursday and Friday I was back inside a client’s outbound system watching two new SDRs try to operate the thing for real.

Those two experiences ended up colliding in my head.

Apollo spent a big part of the day laying out its vision for an AI GTM System built around a pretty clean loop: data feeding intelligence, then execution.

The data gives the system context, the intelligence helps determine what matters, and the execution layer actually does something with it.

I like that framing. A lot, actually.

Quick disclosure: I attended ApolloNext as a paid Apollo partner. The operating take here is mine.

Most GTM teams I work with don't really have a “we need another tool” problem anymore. They have some version of a how the hell is all of this supposed to work together? problem.

By Friday afternoon I had watched that question play out in about the most literal way possible.

We had accounts, personas, data, Apollo, Salesforce, sequences, a dialer, messaging, and two reps who had spent the week learning how the pieces fit together. The next step was supposed to be simple: find the right person and make the call.

Except the first person was DNC. Then another one was DNC. Then another. One rep had a calling extension that wasn't behaving the way we expected. A CRM handoff needed to be checked. A disposition looked wrong until we dug into the record and figured out what had actually updated.

Meanwhile, one of the reps understood the workflow but was still trying to get comfortable enough with the product and the core buying personas to know what to do when an actual human picked up.

None of that meant the system failed.

That was the system being built

Monday morning I started onboarding two new SDRs for a client, and this wasn’t really “here’s Apollo, here’s Salesforce, here’s where you click.”

We were teaching them an operating system.

Which accounts belong to you? Which people matter inside those accounts? What signals deserve attention? What does the CRM already know? Is somebody already working this account? What needs to be enriched? Who can actually be called? Which sequence should they enter? What happens when somebody answers? What gets dispositioned, and what becomes verified truth in the CRM?

Most importantly, what does the seller own, what can the system own, and what absolutely should not happen until somebody verifies it?

That’s a very different version of SDR onboarding than teaching somebody the feature menu of a sales tool.

Tuesday, I flew to San Francisco. Wednesday, I walked into ApolloNext and watched Apollo lay out the direction of the category: data feeding intelligence feeding execution.

I kept thinking the same thing: this is where we’re going.

But GTM leaders are going to have to get much better at thinking about what happens between those boxes.

Your data can identify a signal. Your intelligence layer can determine that the account looks interesting. Your workflow can know exactly what action it is capable of taking.

Should it?

Say someone hits your pricing page. That can be a useful signal, but it doesn’t automatically mean “put them in a sequence and start dialing.”

Are they already a customer? Is there an open opportunity? Who owns the account? Are they even inside your ICP? Is the contact data valid? Are there suppression or DNC rules involved? Is there enough evidence to justify a call, or should this route somewhere else first?

This is what I mean by decision architecture. It is the layer of rules that decides when the tools are allowed to act, when a human needs to take over, and when the system should stop.

Friday gave me the most practical example possible. The reps were finally operating the system themselves, and the inventory immediately forced decisions.

Callable prospects could enter the call motion. DNC records needed an email and LinkedIn path. Questionable data needed to be checked instead of blindly pushed into execution.

That's the handoff

This is the part teams underestimate.

You can connect two tools and still not have an operating system.

A record moving from one platform to another does not prove every field, disposition, write-back or routing rule is production-safe.

A sequence being technically available does not mean it should be turned on yet.

A rep understanding the workflow does not mean they have enough product fluency to handle a real conversation.

Capability is not permission
Integration is not readiness
Automation is not architecture

As execution gets cheaper, the cost of bad execution can get cheaper too. That sounds great until you realize it means the wrong activity can now happen faster, at more volume and with less friction.

The answer is not to slow everything down or force humans to click every button forever. The answer is to get very clear about the decision layer before you hand more of the execution to the machine.

Last week at TitanX in Dallas, I kept coming back to the economics of outbound and the importance of legitimate buyer conversations.

Activity is getting easier to manufacture and AI only widens that gap.

If your input is bad data, bad timing, duplicated ownership or the wrong person, automating the motion does not make the motion better. It just compounds the mistake faster.

The advantage is going to come from better decisions before the activity gets created.

By the end of Friday, the most interesting part wasn’t whether every piece of technology behaved perfectly. It didn’t.

The interesting part was whether the reps could explain what still needed to be done, how the workflow was supposed to operate, and where they would go when something broke.

I asked a version of the question I care about most in an onboarding week: if the client leader and I disappeared on Monday, could you operate the system?

Both felt they could start operating it, with some work still to finish.

Not mastery. Operational independence

One rep still needed more product fluency; both needed more repetitions. The next job is turning the persona language and business value into instinct so that when a real human answers the phone, the rep can actually do something useful with the opportunity the system created.

That is the whole point. The system eventually hands the work to the human. The human still has to add value.

Monday is where the system starts learning from the reps and from the market.

Which lists are actually usable?
Which personas are responding?
Which messages create conversations?
Which data is wrong?
Where do DNC rules change the available motion?
Which sequence logic is breaking?
What objections are showing up?
Where is the CRM creating friction?
Which assumptions from onboarding were wrong?

The job is not to wait until the system is perfect.

The job is to execute in a controlled way, document the exceptions, keep moving, and tighten the system the next day.

Run the motion, watch what breaks, fix what matters, go again

That is how the architecture earns more autonomy

The next step with this team is not “turn on more automation.”

It is to establish the scoreboard and work backward from the outcomes. The client leader already has several plays available across existing demand, nurture signals, account-based opportunities, and outbound inventory.

Now the operating question becomes: what outcomes do we need, which audiences can produce them, what evidence earns attention, who owns the action, and what does the feedback loop tell us next?

Start with the outcome, choose the audience, define the evidence, make the decision, then earn the conversation and use what happens next to improve the system.

Pick one GTM workflow your team uses today and inspect five handoffs

If your team cannot answer those five questions, you do not have a GTM system yet.

You have tools that can do things. That's different.

I actually think this direction is good for SDRs.

AI should remove the shitty parts of the job: bouncing between tabs, copying data, building lists manually, reconstructing account history, doing basic research, and trying to figure out where to spend attention.

The valuable part of the SDR job is what happens once the system gets you to the right human.

Can you listen? Can you diagnose? Can you catch a contradiction? Can you ask the question somebody else skipped? Can you recognize hesitation? Can you know when to push and when to back off?

That is why I keep coming back to the conversation as the KPI.

Your architecture has to get the seller to the right conversation without automating the judgment out of the process on the way there.

Wednesday showed me how much technology can increasingly do.

Friday reminded me how messy the real world still is.

As execution gets cheaper, more of the value moves upstream into deciding what deserves to happen and downstream into what the human does once it does.

The teams that figure this out are not going to be the ones with the most AI.

They are going to be the ones that know what to automate, what to keep human, and when the system has not earned the right to act yet.

Pick one workflow today and map the five handoffs.

If nobody on the team can explain who decides what happens next, that is where I would start.

Reply and tell me the workflow. I’d love to hear where yours breaks.

Have a great Monday 🤙

Thanks for reading. See you again next week at 8 am MST!

- Tom Slocum ✌️

I help B2B founders and sales leaders build the structure underneath the pipeline so the team can actually run it

Know a founder, sales leader or operator who’d get value from this field note?