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

This week I got to watch a small outbound batch do something useful before it produced a single meeting.

It broke

Not the entire motion
Not the offer
Not the copy

But a few records broke as soon as they touched the real world and that distinction matters more than it sounds.

On Thursday, twelve fresh outbound messages went out from my own inbox. These weren't random scraped contacts. They came from a cleaned-up, prioritized HubSpot population, had passed our available checks and had been prepared as a real execution queue.

By Friday morning, four of those twelve records had given us concrete exception evidence: two addresses couldn't receive the message and two people no longer worked where our CRM said they did. We also caught a duplicate send in one thread, five seconds apart.

No verified buyer reply had arrived overnight. That isn't a verdict on the messaging. Twelve contacts are nowhere near enough to declare a market pattern. But it was enough to expose a layer of the outbound system that most dashboards flatten away.

The list had been prepared
The messages had been sent
The system still had to learn whether the records survived contact with reality

Last Monday I wrote about the difference between a Tier 1 list and prospecting inventory. We found 1,008 missing mobiles in a 1,244-person priority population, plus missing email, missing LinkedIn and job-change questions. The lesson was to verify fit, truth and reachability before demanding more activity.

This week made that argument more real. We had done the preparation, narrowed the list and put real messages into the market. The first feedback wasn't buyers saying yes or no. It was delivery and identity failures.

That doesn't mean the preparation was wasted. Preparation reduces uncertainty; it doesn't eliminate it. A CRM record is a claim about the world. Sending, calling and hearing back are how we test that claim.

When a hard bounce comes back, the record tells you something

When an automated reply says the person left the company, the record tells you something else

When a message duplicates, the sending workflow itself tells you something.

Those are three different failures and they need three different fixes.

The mistake would be lumping all three into one vague explanation: outbound isn't working.

Let's separate the evidence. Two messages came back as hard or undeliverable.

One was a conventional 550 5.1.1 failure
The other was an undeliverable response through a secure-mail system

Both addresses are now held as exceptions, not recycled into the next send as though nothing happened.

Two automated replies confirmed that the contacts were no longer at the listed companies. That's an identity and employment-truth problem. It doesn't tell us whether those companies need outbound help and it doesn't tell us whether the message was persuasive. It tells us we reached the wrong version of the person.

Then there was the duplicate: two messages landed in the same thread within five seconds. That is a workflow problem. You don't fix that with better enrichment or a sharper subject line. You inspect the send path, deduplication and the human review boundary.

Four records out of twelve produced delivery or employment exceptions. I wouldn't call that a 33% market-wide bad-data rate. The sample is tiny, the cohort is selected and the exceptions don't even share the same denominator.

What I would say is simpler: four prepared records weren't usable buyer opportunities once they hit reality. The duplicate belongs in a different bucket. It was an execution error, not a fifth bad prospect.

This is what operating a system feels like. You have to preserve the messy categories or you lose the ability to repair the right thing.

Imagine the normal Monday pipeline meeting. The manager sees a dozen new emails, no positive replies and no meetings. Somebody asks whether the subject line is weak. Somebody else wants a new opener. Someone suggests more volume because twelve sends won't move the needle.

All reasonable questions eventually. None are the first question I would ask about this particular batch.

I would ask: how many messages reached a real, current buyer?
How many were rejected by the destination?
How many went to people who had changed jobs?
Did any duplicate or collide with an existing relationship?
How many were delivered but have simply not had time to produce a human response?

Only after those answers would I start interpreting the copy.

Otherwise we're trying to optimize persuasion against a denominator that contains records that were never valid conversations to begin with.

A bounce isn't an objection. A job-change auto-reply isn't a negative response. One night without a reply isn't a failed sequence. And a duplicate send isn't evidence that a buyer rejected our positioning.

If you let those categories collapse into a single reply-rate number, you'll coach the wrong problem.

I like preparation. A lot! We now have three static HubSpot buffers totaling 209 contacts and we can assemble real daily queues from them. Thursday's desk prepared fifteen Gmail drafts: twelve fresh messages, two due follow-ups and one warm acknowledgment. Those were preparation outputs, not activity.

Then I executed the Thursday batch.

The system can research, select, stage and draft, but it can't call the work complete because a draft exists. Someone still has to send, call, listen and decide what the response means.

The next morning, the exceptions were visible. That's the beginning of a feedback loop, not just a completed checklist.

A queue answers: what should I do next?
A feedback loop answers: what did the work reveal, what needs to change, and what should I do differently the next time?

If your outbound system only tells you what got completed, you're missing the useful part. You need somewhere for the system's assumptions to get corrected by evidence.

That can be simple.

The bounce gets held and sent for address verification.
The job-change record gets removed from active outreach until the identity is resolved.
The duplicate gets investigated as a send-path exception.
The valid delivered messages stay in the observation window long enough for an actual buyer response.

None of that requires a new AI agent, a twelve-stage orchestration diagram or a dashboard with seventeen colors. It requires categories, ownership and the discipline not to overreact.

I would stop asking only how many contacts were enrolled or how many activities the team completed. I'd ask the manager to show me one small cohort from preparation all the way through its first real feedback.

Start with the records selected.

What evidence qualified each one?
Which fields were verified and which were merely present?
What suppression checks ran?
What channels were actually available?

Then show the outbound execution itself: the send, the call attempt, the LinkedIn action, or the decision to wait.

Now inspect the outcome without turning everything into good or bad.

Delivered, bounced, changed job, duplicate, OOO, Human response or no response yet. Each status should have a next action or a deliberate hold.

Then look at the person who owns the decision. Does the rep know what to fix? Does the manager know which failures are coaching problems and which are systems problems? Can RevOps correct the underlying record without wiping out a good historical relationship?

This is where a lot of outbound programs quietly lose momentum. They do the hard work of building the list and writing the sequence, then improvise the exception handling every day. One rep fixes a title. Another sends anyway. A third creates a duplicate. The manager sees the activity report and thinks everything is moving.

The system appears busy. The truth is getting less reliable.

We are also building a separate signal-led multichannel experiment in Lemlist. It is still in preparation as I write this, with a small pilot planned for next week after a final human launch check. I am not going to tell you it produced meetings or improved conversion before it has even run.

But one of the design choices is already relevant: AI prepares research and routing, while the human handles real calls, LinkedIn conversations, voice notes and final decisions. Missing LinkedIn data shouldn't stop an email. An unaccepted connection request shouldn't freeze a phone task. A weak signal shouldn't be magically upgraded into a fact just because the template wants a personalization line.

The point is not to build a machine that never needs attention. It's to build one that makes the exceptions visible and hands them to the right owner.

The irony is that the more automated your preparation gets, the more important that handoff becomes. A system that produces twenty polished drafts in minutes can also produce twenty polished mistakes if nobody checks the truth underneath them.

I'd rather have a smaller motion where we can explain why a prospect entered, what happened after outreach and what we learned than a huge motion where the only answer is, 'the sequence is running.'

We know the Thursday batch was sent. Four unique records produced delivery or employment exceptions. One duplicate send happened. No verified buyer reply arrived overnight.

We do not yet know the eventual reply rate for the valid cohort, which message angle will win, whether calls will open conversations, or whether next week's multichannel pilot will improve anything. Those are still open questions.

That uncertainty is useful. It tells us what to measure next instead of pretending the story is finished.

If next week's valid sends get replies, we'll inspect them. If they don't, we'll inspect timing, targeting, message and channel mix. If more records fail before reaching buyers, we'll fix the data and send path before coaching the copy.

The order matters because every stage changes what the next stage can honestly tell you.

Take one outbound cohort from last week. Not the whole CRM. Not the dashboard total. Ten or twenty actual prospects your team tried to reach.

For each one, write down what was prepared, what actually executed, what the first feedback was, and who owns the next action. Separate a bounce from a buyer rejection, a job change from a targeting miss and an unsent draft from a real touch.

If your team cannot do that, you don't need another activity target yet. You need a clearer line between preparation, execution and learning.

That's the layer I'm working on right now. Last week the lesson was that a clean list is not automatically prospecting inventory. This week the lesson is that even a prepared, sent cohort is still a set of assumptions until the world answers back.

The win isn't pretending the first batch was perfect. It's making sure the second batch is smarter because the first one happened.

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 pipeline so the team can actually run it

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