Seventh Sense Blog

Marketo Smart List Scheduling Meets STO

mike@theseventhsense.com (Mike Donnelly) — Mon, 03 Aug 2026 14:00:00 GMT

We've spent the last several weeks of this cluster critiquing martech vendors, untangling ownership in marketing ops, and diagnosing why platforms underperform their potential. For the last post in the series, I want to do something narrower and more concrete: walk through what changes when Marketo users layer Marketo smart list scheduling together with recipient-centric send-time optimization.

This matters for two reasons. First, in late December 2025 we shipped Seventh Sense's Marketo Smart List Scheduling integration, which bridges the smart list model in Marketo with our send-time engine. Second, the underlying conceptual shift — from list-centric scheduling to recipient-centric scheduling — is the same shift every email tool eventually needs to make, regardless of which platform you're on. Marketo just happens to be the one I want to write through today.

How Marketo smart lists schedule sends by default

If you've operated Marketo for any length of time, you know smart lists are the backbone of every campaign. A smart list is a dynamic audience built from filters — behavior, demographics, custom field values — that resolves at the moment the campaign runs. You build the list, attach it to an email program, and pick a send time. The canonical reference for smart list behavior is in Adobe's Marketo documentation, which has gotten meaningfully better since the Adobe acquisition.

The default scheduling model is list-centric. You say: "send this email at 10:00 AM on Tuesday to everyone who matches this smart list at the moment the send fires." Marketo handles the resolution, throttling, and execution. The send window is the same window for every contact in the list.

This model is fast, predictable, and easy to reason about. It's also the wrong shape for how recipients actually consume email.

What's wrong with list-centric scheduling

The list-centric model assumes everyone in your smart list is roughly the same kind of recipient — that 10:00 AM Eastern is a reasonable approximation of when they're likely to engage. For some lists this is true enough. For most B2B lists, especially ones that span geographies, industries, and seniority levels, it's a flat average that fits almost nobody well.

The cost of that flatness compounds:

Engagement is concentrated in a window few recipients are actually in. The CMO in London sees your email at 3:00 PM her time, when she's in back-to-back meetings. The marketing manager in San Francisco sees it at 7:00 AM, before she's at her desk. Both get the same send time because the smart list does.
Open rates and click rates underperform their potential by 10-30%. Not because the audience is wrong — the smart list resolved correctly — but because the timing assumption was wrong for most of the audience.
Bunching becomes worse, not better, with sophisticated segmentation. The more granular your smart lists, the more campaigns you ship per week, and the more likely several campaigns will land in the same recipient's inbox at the same hour because all of them defaulted to 10:00 AM Tuesday. This is the Marketo expression of the email collision problem.
The list-centric model can't get smarter over time. No matter how much engagement data you accumulate per recipient, the schedule itself is a list-level property. Per-recipient learning has nowhere to land.

This isn't a Marketo failure. It's a category-wide pattern. Every ESP started with list-centric scheduling because that's what the underlying execution engines were built to do. The work of moving past it is the work of building a layer that thinks in recipients rather than campaigns — an active discussion thread in the Marketo Nation community for years now.

What changes when scheduling becomes recipient-centric

Recipient-centric scheduling inverts the model. Instead of saying "send this to everyone at 10:00 AM," you say: "release this campaign to the orchestration layer over the next 24 hours, and let each recipient receive it when they're most likely to engage."

The smart list still defines the audience. Marketo still owns the resolution, the throttling, the deliverability mechanics. What changes is the scheduler. Each recipient's send time becomes a function of their engagement history, not the campaign's nominal send time.

In practice, this looks like:

The CMO in London receives the email at 7:30 AM her local time, the window she has consistently opened your last 12 emails in.
The marketing manager in San Francisco receives it at 9:15 AM her local time, when she's settled at her desk with coffee.
The sales director in Singapore receives it at 11:00 AM his local time, his consistent peak engagement window.

Same smart list. Same content. Three different send times, each chosen because the engagement data per recipient said it would land better than the default.

The Marketo Smart List Scheduling integration

This is what the Marketo Smart List Scheduling release (Dec 29, 2025) does. It connects Marketo smart lists to the Seventh Sense send-time engine so the scheduling decision moves from the list level to the recipient level. You don't change how you build smart lists. You don't change how you author content. You change one thing in the campaign setup — the scheduler — and the rest of your Marketo program runs unchanged.

The mechanics, at a high level:

You author the email in Marketo as you always have. You attach the smart list as you always have.
Instead of picking a fixed send time, you hand the campaign to the Seventh Sense scheduler, which sees each recipient in the resolved list and looks up their engagement profile.
The scheduler releases sends back to Marketo over a configurable window (default 24 hours), with each recipient queued for their individual peak engagement time.
Marketo executes the actual sends, just as it would have for a scheduled blast. The audit trail in Marketo shows every send. The reporting in Marketo works as expected.

The integration is intentionally minimal. We don't replace any part of Marketo. We sit next to it as a scheduling layer. The smart list still defines who gets the email. We only change when each person in the list actually receives it.

What it looks like in production

Across the customers who've onboarded this integration in the first quarter since the release, the pattern is consistent. Open rates lift in the 15-30% range. Click rates lift roughly in proportion — comparable to the lift documented in the post on send-time optimization proof in HubSpot. Unsubscribes decline modestly, which is the part most people don't predict — sending an email when somebody is likely to engage produces less annoyance, not just more opens.

The other thing that changes — and this is the part I care about more than the open rates — is collision rate. When your scheduler thinks per-recipient instead of per-list, two campaigns that both default to "Tuesday 10:00 AM" no longer dogpile the same inbox. The recipient-centric scheduler naturally spreads them, because each recipient's send time is different. The downstream effect on over-messaging as a silent deliverability killer is the part most teams underestimate before they see it.

That's the part that translates the integration from "small lift" to "category-changing." The open rate lift is what people notice in the first month. The reduction in over-messaging is what they notice in the second quarter, when their deliverability metrics start drifting up instead of down.

What this means for the broader Marketo stack

I want to be careful not to overclaim. This integration solves one specific seam in the Marketo stack: scheduling. It doesn't fix smart list logic, content quality, segmentation strategy, or any of the other layers that have to be working for email to perform.

What it does is unlock a class of optimization that the platform itself wasn't going to deliver. Marketo isn't going to ship recipient-centric scheduling natively — not because the engineering is hard, but because the platform is positioned around the list-centric model and rebuilding that core would orphan years of customer programs. The work has to happen in a layer that sits on top.

That's the role this integration plays. It's not a Marketo replacement. It's a Marketo extension that fixes the scheduling layer without touching anything else you've built.

Frequently asked questions about Marketo smart list scheduling

Do I need to rebuild my Marketo smart lists to use this?

No. The integration uses your existing smart lists exactly as Marketo defines them. The smart list resolves at send time the way it always has; the only change is that the scheduler that releases the resolved sends operates per-recipient instead of per-list.

Does this work for trigger campaigns or only for batch sends?

Both. Trigger campaigns benefit from recipient-centric scheduling differently — the trigger fires when it fires, and the scheduler delays release until the recipient's peak window within a configurable max-delay window. Batch sends benefit more dramatically because the lift compounds across the whole audience at once.

How does this interact with Marketo's operational frequency caps?

The integration respects Marketo's frequency caps as a hard floor. If a recipient is at cap, they don't get released by the scheduler. Beyond that, the scheduler adds a softer layer of orchestration that prevents bunching, even when the recipient is technically under cap.

Is this only for Marketo, or does it work for HubSpot users too?

Seventh Sense has been a HubSpot-native product for years — recipient-centric scheduling is the core of what we do there. The Marketo Smart List Scheduling release is the parallel capability for Marketo users. If you operate both platforms, you can run the same orchestration model across them.

Closing the cluster

This series started with the question of who owns email at most B2B companies and worked through the related questions of vendor strategy, feature bloat, and implementation failure. I want to close on a structural observation that ties all of them together.

The single biggest leverage point in B2B email is the shift from list-centric thinking to recipient-centric thinking. Ownership is recipient-centric — the channel owner cares about the inbox, not the campaign. Vendor selection is recipient-centric — you want partners who measure success in what landed for the customer, not what shipped in the release notes. Implementation diagnosis is recipient-centric — the dominant constraint is whatever is degrading the recipient experience. And scheduling, finally, is recipient-centric — the right send time is the one that matches the person, not the calendar.

The Marketo Smart List Scheduling integration is one expression of that shift. It's the smallest, most concrete one we've shipped in the past year. But the underlying principle — your recipient doesn't care about your workflows, your smart lists, or your campaigns. They care about how this email lands in their inbox today. — runs through every post in this cluster.

If you're operating Marketo and want to test what recipient-centric scheduling does to your numbers, the free trial connects in about 15 minutes and runs against your existing smart lists with no rebuild required. The full release notes for the Marketo Smart List Scheduling integration are on our product updates page.

Thanks for reading the cluster.

Why Most HubSpot Implementations Underperform

mike@theseventhsense.com (Mike Donnelly) — Wed, 29 Jul 2026 14:00:00 GMT

I've audited a lot of HubSpot portals. Probably four hundred at this point, across companies from 30 employees to 30,000. The conversation always opens the same way: "We're using HubSpot, but we feel like we're not getting the value out of it that we expected." Then somebody hands me a portal URL and I spend two hours poking through workflows, lists, properties, and reports — usually consulting HubSpot's own knowledge base alongside, because half the misconfigurations I find trace back to default behavior nobody documented internally.

What I've learned is that HubSpot implementation problems are remarkably patterned. Across hundreds of portals, the failure modes cluster into four buckets. Almost every underperforming portal I see is dominated by one of them — sometimes two. Once you know which bucket you're in, the fix becomes obvious. The hard part is the diagnosis.

This post is the framework I use to make that diagnosis fast.

The four failure modes

Every underperforming HubSpot portal I've seen falls into some combination of:

Process: the workflows and operational logic are misaligned with how the business actually runs.
People: the team using the portal doesn't have the skills or the bandwidth the platform requires.
Technology: the portal is misconfigured, integrated badly, or trying to do something the platform isn't suited for.
Data: the data inside the portal is incomplete, inconsistent, or unreliable enough that no insight built on it can be trusted.

These are simple categories. The work is figuring out which one is the dominant constraint in your specific portal — because the fix for each is different, and fixing the wrong one wastes a quarter.

Failure mode one: process

Process failures are the most common. The portal is technically working, the team is staffed, the data is reasonably clean, but the operational logic doesn't match how the business actually operates. Symptoms:

Lifecycle stages don't map to your actual funnel. Marketing thinks an MQL is one thing; sales thinks it's another. The portal definition is a third version that's a compromise from a meeting two years ago that nobody attended.
Lead routing has accumulated bandages. Every territory exception, named account override, and special routing for the strategic accounts team is layered on top of an original routing logic nobody documented. Adding a new territory takes a week and breaks two other things.
Workflows duplicate, contradict, or override each other. Three different workflows can change the same property to three different values depending on entry order. Nobody is sure which one "wins" in any given case. The downstream effect is the email collision problem at the recipient level.
Reports rely on properties that aren't being maintained. The dashboard says "deals at risk" based on a property that hasn't been updated by sales in eight months.

If you read that list and recognized three or more items, your dominant constraint is process. The fix is not a HubSpot fix. It's a sales-and-marketing alignment fix that gets implemented in HubSpot — and it usually surfaces the deeper question of who actually owns email marketing in your org. Trying to fix this with consultants who only know the platform produces beautiful workflows that solve the wrong problem.

Failure mode two: people

People failures are the second most common, and the hardest for leadership to see because they look like a portal problem from the outside. Symptoms:

One person knows how everything works. If that person is on PTO, nothing changes. If they leave, the portal becomes a foreign artifact in six months.
The team has the title but not the skills. A "HubSpot admin" who was promoted from coordinator role and never trained on workflow architecture is going to ship workflows that look reasonable and fail subtly.
The team has the skills but not the bandwidth. Three people are doing the work of seven. They're heroic, they're competent, and they're shipping changes faster than they can document them. The portal becomes increasingly opaque.
The team has the bandwidth but not the authority. They know what needs to change but can't change it without sign-off from a stakeholder who doesn't respond to ops requests.

People failures don't get fixed by buying more software or by re-implementing the portal. They get fixed by hiring, training, or restructuring the team that owns it. This is usually the hardest fix because it's the most political.

Failure mode three: technology

Technology failures look like the most "real" failures because they're the most observable, but they're actually rarer than the first two. Symptoms:

The HubSpot-Salesforce sync is broken or one-directional in ways you didn't intend. Properties don't match. Field types collide. Sales updates aren't making it back to marketing, or vice versa.
You're using a HubSpot tier that doesn't support what you're trying to do. You're trying to run lifecycle marketing on Marketing Hub Starter, or sales orchestration on Sales Hub Pro when you need Enterprise. The portal is performing exactly to spec, but the spec doesn't fit. Tier choice also affects whether you can use shared vs. dedicated IP, which compounds the underperformance.
Third-party tools are competing with HubSpot for the same job. You have a separate cadence tool sending alongside HubSpot sequences, a separate marketing automation product alongside HubSpot workflows, a separate analytics tool alongside HubSpot reporting. The integrations don't talk and the data fragments.
The portal hit a HubSpot platform limit and nobody noticed. Active list count, workflow count, custom property count, API call rate. HubSpot has limits, and busy portals hit them invisibly. Things start failing silently.

Technology failures are the most expensive to fix as cash outlay but the easiest to fix as effort. You're either buying a new tier, removing an overlapping tool, or doing a sync rebuild. The work is bounded. The bill is not.

Failure mode four: data

Data failures are the most insidious because they invalidate everything built on top of them. You can have perfect process, the right people, and a clean tech stack, and if the data is bad the portal still underperforms because every decision made from it is unreliable. Symptoms:

Duplicate contacts at scale. The same person exists as two, four, sometimes eight contact records, often with conflicting properties. Workflows behave nondeterministically because they're acting on different instances of the same person.
Property values are inconsistent. "Industry" is a free-text field with 200 unique values. "Company size" is "small/medium/large" in some records and an employee count in others. Reports built on these fields are decorative, not diagnostic.
Sources are unreliable. The "original source" property has drifted because forms got renamed, scripts got patched, attribution windows got changed. You can't trust where your pipeline came from, which means you can't allocate budget intelligently.
Sync conflicts overwrite good data with bad. The CRM sync runs and replaces a clean property value with a stale one from the other system. Nobody notices for a quarter. Microsoft's mail flow best practices documentation is one of the better external references for understanding how downstream systems treat data quality signals.

Data failures are the slowest to fix because the fix is rarely a tool. It's a sustained operational hygiene program: deduplication, standardization, governance, validation. Six months minimum to make a real dent. Nobody wants to budget for it, which is exactly why so many portals stay broken at the data layer.

The diagnostic, in 30 minutes

Here's the actual triage I run when somebody asks me to look at their portal. You can do it yourself.

Step 1: open the contacts database

Sort by created date descending. Look at the most recent 200 contacts. How many have nulls in the properties you'd expect to be populated (industry, company size, lifecycle stage, source)? If more than 30%, you have a data problem.

Step 2: open the active lists count

Anything over 200 active lists in a portal under 50K contacts is a process problem. Lists accumulate. Nobody deletes them. The proliferation tells you how much accumulated logic is running invisibly.

Step 3: open the workflows tab and sort by last edited

How many workflows haven't been edited in 18 months and are still active? If more than half, you have a process problem (nobody maintains them) or a people problem (nobody knows what they do).

Step 4: check the Salesforce or external CRM sync log

How many sync errors are pending? Over 100 means you have a technology problem. Over 1,000 means you have a technology problem that's been ignored for so long it's becoming a data problem too.

Step 5: ask the ops lead one question

"If you got hit by a bus tomorrow, what would happen to this portal?" If they laugh and say "it would be fine," you have functional operations. If they pause too long, you have a people problem.

Five steps. Half an hour. You'll know which bucket you're in.

What to do once you know

The hardest move after the diagnosis is the discipline to fix the dominant constraint first instead of all four at once. The instinct is to launch a tiger team that addresses everything in parallel. Don't. Tiger teams don't fix portals. Sustained focus on the dominant constraint does.

Process problems get fixed by re-mapping the funnel with sales, then rebuilding workflows around the new map. 8-12 weeks.
People problems get fixed by hiring, training, or restructuring. 3-9 months.
Technology problems get fixed by tier changes, sync rebuilds, or tool consolidations. 1-3 months.
Data problems get fixed by a hygiene program that runs for two quarters minimum and never really ends.

Pick the one that's eating you. Fix that. Then come back and triage again.

Frequently asked questions about HubSpot implementation problems

Can a HubSpot implementation partner fix all four?

A good one can fix two of them — process and technology. A great one can identify all four and tell you which one they can help with and which one needs internal investment. Be skeptical of partners who claim to fix people or data problems with a project. Those are operational programs, not implementations.

How often should I do this diagnostic?

Quarterly is overkill. Annually is reasonable. Any time you onboard a new ops lead or go through a reorg, it's mandatory — new leadership means a new chance to course-correct, and the diagnostic surfaces the problems they should focus on first.

What if I'm in all four buckets equally?

You're probably in process and data primarily, and the other two are downstream effects. Tackle process first, because clearer process makes the data hygiene work easier to scope, the people roles easier to define, and the technology choices easier to justify.

Where does send-time optimization fit in this framework?

Send-time optimization is a technology layer on top of an otherwise functional process. If your portal is in process or data failure, STO won't help — you're optimizing the timing of sends that shouldn't be going out the way they're going out. Fix the dominant constraint first, then add STO once the foundation works.

The honest framing

Most HubSpot portals that underperform aren't underperforming because HubSpot is the wrong platform. They're underperforming because the four-bucket diagnostic was never done, and the team has been throwing fixes at the most visible symptom for two years.

Run the diagnostic. Pick the dominant constraint. Fix it. Then run the diagnostic again. That's the whole playbook.

If you want a layer that helps with the send-time and orchestration problems once your portal foundation is solid, the free trial of Seventh Sense takes 15 minutes to connect and surfaces over-messaging patterns you probably can't see from inside HubSpot. It's not a fix for the four failure modes — nothing is — but it's a useful tool once you've done the structural work.

Choosing a Martech Vendor That Lasts

mike@theseventhsense.com (Mike Donnelly) — Mon, 27 Jul 2026 14:00:00 GMT

Last October I wrote a LinkedIn post about platform vendors that ran longer than I'd intended and got more reaction than I'd expected. The core argument: there are two kinds of platform companies in martech right now, and you almost never see them labeled correctly when you're choosing a martech vendor. One kind is building infrastructure you can stake a five-year strategy on. The other kind is using your portal as a free R&D lab and will sunset the feature you depended on the moment it stops being interesting to them.

This post is the longer version of that argument, with the selection criteria I wish someone had handed me when I was running marketing ops a decade ago. It's the companion piece to the post on the Red Stapler feature problem — bloat is the symptom, vendor archetype is the cause.

The two archetypes

Every platform vendor in martech is a mix of both archetypes, but the dominant orientation matters more than the mix. Scott Brinker's annual Chiefmartec martech landscape tracks the long-arc behavior of these vendors better than any analyst quadrant I've seen.

The Ecosystem Builder

An Ecosystem Builder treats their platform as infrastructure. They invest in the boring durable layer: APIs that don't break, a data model that holds across releases, partners they actually integrate with, documentation that's complete enough for a new engineer to onboard without a call. They ship fewer features per quarter, but the features they ship are load-bearing. They deprecate things slowly and with notice. They write migration guides.

The Ecosystem Builder's incentives are aligned with yours over a 5-10 year horizon. They want you to build on them, succeed, and renew at a higher tier because your business grew on top of them. They will sometimes pass on shipping the fashionable feature this quarter because it doesn't fit the long-term architecture. That restraint is, paradoxically, the strongest signal you can get.

The Free R&D Lab

A Free R&D Lab treats their platform as a distribution channel for experiments. They ship a torrent of features each quarter, most of them shallow, many of them launched in beta and never moved out of beta. They use the customer base as a forced testing ground for ideas the product team wants to validate, and they aren't accountable for whether those ideas work in production. When a feature underperforms internally, it gets quietly deprecated — sometimes with notice, often without — and the customers who built on it are on their own.

The Free R&D Lab's incentives are aligned with their roadmap and their press cycle, not with your durability. You'll know you're dealing with one when the second-to-last feature you adopted just got removed and the replacement requires you to rebuild your workflow from scratch.

Why this distinction is invisible during a sales cycle

Here's the painful part: every vendor sells the Ecosystem Builder story. The slides look identical. The customer logos overlap. The analyst quadrant doesn't distinguish between them. You will not be able to tell which archetype you're buying from the demo, the RFP response, or the reference calls (which are pre-screened).

The distinction only becomes visible 18-24 months in. By that point you've migrated. The switching cost is higher than the rebuild cost would be. You're trapped in a relationship whose actual shape didn't match the one you bought.

This is the structural reason choosing a martech vendor is so hard. The information you need to decide isn't available at the moment you have to decide.

How to tell the two apart before you buy

Since you can't trust the sales cycle, you have to work backward from the public record. The following signals are imperfect but they're a lot better than the marketing pitch.

Read three years of release notes, not three months

The most useful single artifact a vendor publishes is the historical release notes — far more useful than the curated reports you'll find in Gartner's marketing leadership research, which tend to capture the snapshot rather than the trajectory. Pull three years of them. Look for two patterns:

What got deprecated? Healthy products deprecate. If three years of release notes show nothing but additions, the vendor is accumulating surface area indefinitely — which means at some point they'll quietly drop something, and that something might be the feature you built on.
How long did the last big feature persist? If the "flagship new capability" of Q2 two years ago is gone, replaced, or buried, that tells you how seriously to take the flagship capability they're pitching you today.

Look at the API and the partner program

Ecosystem Builders invest in their APIs because they know you're going to build on top. The APIs are versioned, documented, and stable. The partner directory has hundreds of working integrations and a non-trivial certification process. The community has third-party tools that have been around for years.

Free R&D Labs publish APIs that are technically functional but loosely versioned, sparsely documented, and frequently broken by underlying changes. The partner directory is a marketing page. Third-party tools come and go in 12-month cycles. The signal you want is durability of the surrounding economy, not the slickness of the vendor's own product.

Check who's running product, and for how long

Look up the head of product on LinkedIn. If they've been in the role for three-plus years and have shipped through at least one full strategy cycle, that's a stability signal. If the role has turned over three times in five years, the product strategy is whiplashing. Whiplashing strategy is the single most reliable predictor of Free R&D Lab behavior — each new product leader needs to put their mark on the roadmap, which means new flagship features get launched and old ones get orphaned every 18 months.

Listen for the deprecation language

On vendor calls, ask: "When was the last time you deprecated a customer-facing feature, and how did you communicate it?" Ecosystem Builders answer this fluently — they have a process, a timeline, a migration path. Free R&D Labs get awkward, claim they "almost never deprecate," and then change the subject. The awkwardness is the answer.

Ask the customers who left

Reference calls are pre-screened. Talk to companies that left the platform — you can find them on Reddit, in community forums, in old case studies that have since been pulled. The reasons people leave are far more diagnostic than the reasons people stay.

Selection criteria for the long horizon

If you're picking a martech vendor for a function you expect to depend on for 5+ years — a CRM, an ESP, a marketing automation platform, your CDP — weight the following criteria heavily. They're the ones that pay off over the long arc and that almost nobody scores during a typical RFP.

Stability of the data model

Has the vendor changed how they model the core objects (contact, account, deal, event) in the last three years? If yes, ask what migration looked like. If the migration was painful, your next migration will be painful too. Stable data models compound. Mutable ones bleed you.

Quality of the audit trail

Can you reconstruct, for any contact, the full history of what was sent, when, by which workflow, and what changed? This is the same question a real HubSpot email collision audit answers — and if your vendor's data model can't support it, audits become forensic exercises instead of routine ones. If you can't, you don't have an auditable system — you have a black box that happens to also send email. Ecosystem Builders make audit trails first-class. Free R&D Labs treat them as a compliance afterthought.

Depth of the developer experience

Even if you don't think you're a developer org, you will need to extend the platform at some point. The quality of the developer experience — sandbox accounts, real test data, a CLI, version control, the ability to run a diff between two configs — predicts how much pain you'll feel during every future change. This is a deeply boring criterion that pays the loudest dividends.

The "I depend on this" test

Walk through your current operational dependencies on the vendor's platform. For each one, ask: "If they sunsetted this feature tomorrow with 90 days notice, could I rebuild it on top of what remains?" If the answer is no for more than a handful of features, you're already too deep with a vendor whose archetype hasn't been tested.

What this means for the platforms most of you are on

I'll be careful here, because I have working relationships with several of the platforms in this space and the archetypes shift over time. A vendor that was an Ecosystem Builder five years ago can drift into Free R&D Lab behavior under new leadership. A vendor that started as an R&D lab can mature into infrastructure.

The exercise to do is not "which bucket is HubSpot in" or "which bucket is Salesforce in." It's "which direction has my vendor been drifting in the last two years?" The trajectory matters more than the snapshot. A vendor drifting toward ecosystem behavior is a safer long-term bet than one drifting toward R&D lab behavior, regardless of where they sit today. The same lens applies to the question of why most HubSpot implementations underperform — trajectory of the platform is half the answer.

Frequently asked questions about choosing a martech vendor

Can a vendor be an Ecosystem Builder in one product and a Free R&D Lab in another?

Yes, and this is actually common at large platforms. The core product (CRM, marketing automation) tends to behave like infrastructure because the customer dependency is too deep to risk. The newer adjacent products (AI agents, conversation intelligence, CDPs) often behave like R&D labs because the vendor is still figuring out the category. Buy the core. Be skeptical of the adjacencies.

Should I pick a smaller vendor over a large platform?

Smaller doesn't automatically mean Ecosystem Builder. Plenty of small vendors are R&D shops chasing the next round. The size question is orthogonal to the archetype question. What matters is the vendor's behavior around stability, deprecation, and developer experience — not their headcount.

What's the single best question to ask a vendor in evaluation?

"Walk me through the last feature you deprecated, the timeline you gave customers, and what migration looked like." The answer is more diagnostic than any other question I've ever asked in a vendor evaluation. If they can't answer cleanly, they either never deprecate (bloat is coming) or they deprecate badly (you're next).

How does Seventh Sense think about this for itself?

We're a small focused product. Our archetype check is whether we're treating customers as partners in the long arc of email orchestration or as a free testbed for whatever AI feature is trending. We publish a product updates page with the actual ship history, including deprecations. You can read it back three years and judge whether we're walking the talk.

The bet you're actually making

When you sign a martech contract, you're not buying features. You're betting that the vendor's archetype will hold for the life of your dependency on them. The features in the demo are real today. They're not necessarily real in three years. The archetype is what determines whether the bet pays off.

This is why I push back on vendor evaluations that score on feature matrices. The feature matrix is the snapshot. The archetype is the trajectory. The trajectory is what you're buying.

If you want to test whether Seventh Sense fits the Ecosystem Builder pattern you're looking for, the free trial is the fastest way to see how we operate — how the product is built, how the documentation is structured, how the integration with HubSpot actually behaves under load. That's the only signal that ever really matters.

The Red Stapler Feature Problem

mike@theseventhsense.com (Mike Donnelly) — Fri, 24 Jul 2026 14:00:00 GMT

If you've watched a major martech platform release notes feed for more than a year, you've seen the pattern. Every quarter, a torrent of new features ships. Every quarter, you adopt maybe two of them. The rest sit in the product like unopened boxes in a basement — technically owned, never used, occasionally tripped over.

This is martech platform feature bloat, and it isn't an accident of execution. It's a structural outcome of how product teams at large platform vendors get rewarded — a dynamic that Scott Brinker's annual Chiefmartec landscape has been documenting for over a decade. I've called it the Red Stapler problem for years, and once you see it, you can't unsee it.

What I mean by a Red Stapler feature

In Office Space, Milton is obsessed with his red Swingline stapler (the cultural reference needs no introduction to anyone who's worked a corporate job). Nobody else cares about it. The stapler isn't load-bearing. Nobody's workflow depends on it. But Milton mutters about it for the entire film because it's his, and he has built his identity around defending it.

A Red Stapler feature in a martech platform is the same shape. It exists because a specific PM — let's call him the Red Stapler PM — lobbied for it, fought for headcount to build it, defended it in roadmap reviews, and shipped it under the headline "ABC Platform now supports XYZ workflow." It got a launch blog post. It got a webinar. It got two screenshots in the next analyst briefing.

And nobody outside the company asked for it.

The feature isn't bad. It's not actively broken. It's just orthogonal to the actual problem the customer base is trying to solve, and it consumes a small but real slice of every customer's mental real estate forever after, because the docs reference it, the onboarding mentions it, and the menu has a tab for it. Multiply that by ten quarters and you get a product that's vast, surfaced, and unlearnable.

Why platform PMs ship features no one asked for

I want to be fair here. Most platform PMs are smart people working hard. The Red Stapler feature problem isn't a failure of individual judgment. It's a failure of the system they operate inside.

Promotions reward shipped features, not adopted features

The most common incentive structure inside large martech vendors rewards a PM for the number of features they shipped, the press they generated, and the analyst quadrant they helped move. None of those incentives reward adoption. A feature that ships with a press release and gets used by 3% of the base is, to the promotion committee, indistinguishable from a feature that gets used by 80%.

The Red Stapler PM is making a rational career bet. They're shipping the feature that's most visible, not the one that's most needed.

Customer research at scale is genuinely hard

The vendor has 50,000 customers. The PM talks to 25 of them. Twenty of those 25 were chosen because they're the loudest, the largest, or the ones the CS team flagged as "strategic." That sample tells you nothing about what the middle 40,000 actually need. So the PM defaults to what's easy to articulate: a feature parity claim against the competitor, an integration with the AI vendor du jour, a dashboard refresh.

The features that would actually move the needle for the middle 40,000 customers — better defaults, fewer footguns, less broken behavior in the existing flows — never make the roadmap, because they don't make a good slide.

The competitor matrix tyranny

Half the features in any large platform exist because a competitor shipped them first. The PM didn't think these features were important. The analyst report did. So the PM ships a checkbox version of the feature, declares parity, and moves on. The checkbox version often works just well enough to look real in a demo and just poorly enough to be unusable in production. Customers learn this the hard way when they try to actually use it.

The marketing org needs a story every quarter

Every public company needs a quarterly product story for earnings, for sales, for the channel. The product marketing team needs three to five "announcements" per quarter even when the underlying engineering hasn't produced three to five things worth announcing. The Red Stapler feature is the answer to that pressure. It exists to fill a press release slot.

The signs you're looking at a Red Stapler feature

Once you know the pattern, you can spot them in release notes within ten seconds. The tells:

The feature solves a problem you didn't know you had. Genuinely useful features describe a pain you recognize. Red Stapler features describe a capability and trust you to invent a use case.
The launch material is heavy on visuals, light on the "before" state. If the announcement can't crisply describe what was broken before the feature shipped, the feature wasn't solving a real problem.
Adoption requires changing your workflow. Real features fit into how you already work. Red Stapler features require you to restructure something to make them useful, and the vendor never publishes the migration guide because nobody migrated.
The feature has its own tab in the menu but no integration with the rest of the product. If the new thing lives in a separate area and doesn't show up in the workflows you already use, it was built by a team operating in isolation. That team is almost always shipping a Red Stapler.
The marketing copy uses the word "now." "Platform now supports..." is the rhetorical fingerprint of a feature shipped to keep up with a competitor or an analyst, not one shipped because customers were asking.

How to filter platform announcements

I read release notes from the major platforms every week. Most of what's in them is noise. Here's the heuristic I've settled on, which has saved my team months of wasted evaluation time:

Wait two quarters before evaluating a new feature

If the feature is real, it'll still be there in six months and there will be third-party content about it — customer case studies, community posts, agency write-ups. If the feature is a Red Stapler, the launch noise will fade and the docs page will quietly stop being updated. The two-quarter wait is the cheapest signal you can buy, and it applies to the most-hyped category right now: the HubSpot AI workflow builder review I wrote at the six-month mark is a worked example.

Ignore the feature, ask about the changed defaults

The features that actually change customer outcomes are usually defaults — the new starting state for new accounts, the new behavior of an existing flow. These don't get press releases because they're not flashy. They show up in the release notes as one-line bullets at the bottom. Those bullets are where the actual product strategy lives.

Look for what got deprecated

Healthy products deprecate features. Bloated products only add. If a vendor's release notes never mention deprecations, they're accumulating Red Staplers indefinitely. Eventually the surface area becomes unmaintainable, and you'll find out the hard way — in a bug that takes six weeks to fix because the responsible PM left two years ago.

Check the integration graph, not the feature list

What matters more than any individual feature is whether the platform's pieces talk to each other. A new AI agent that doesn't read from your existing contact records is a demo, not a product. A new workflow type that doesn't show up in your existing reporting is a checkbox. The integration graph — how the pieces compose — is the only thing that compounds over time.

What this means for your stack

If you're a marketing ops leader trying to decide whether to adopt the new feature your vendor just announced, the answer is almost always: wait. The cost of adopting late is small. The cost of adopting early and discovering it's a Red Stapler is large — you spent training time, you re-architected a workflow, you bought into a feature that the vendor's own roadmap quietly walked away from two quarters later. The pattern shows up clearly when you run a real HubSpot implementation diagnostic: half the dormant configuration in any portal traces back to a Red Stapler somebody adopted in 2022.

The strongest filter you can apply is: does this feature address a problem I was already trying to solve? If the answer is no, the feature is for somebody else — possibly nobody. Skip it.

I covered the related but distinct question of whether your vendor is building you an ecosystem or using you as a free R&D lab in the post on choosing a martech vendor that lasts. The Red Stapler problem is the symptom. The vendor strategy that produces it is the root cause.

Frequently asked questions about martech platform feature bloat

How do I know if my company is being sold Red Stapler features?

Look at the features you adopted in the last 18 months and ask which ones are still in production use. If the ratio is under 30%, you're being sold features faster than you can absorb them, and most of what you adopted was Red Stapler material. The other 70% became sunk-cost reasons to renew.

Is feature bloat unique to martech?

No. It's a property of any large enterprise software category where the vendor competes on the analyst quadrant. CRM, ERP, HR tech, security tools — same pattern. Martech just has it worse because the buyer is often a marketing ops manager, not a CIO, and the buyer rarely has the leverage to push back on roadmap.

Should I tell my vendor when I think a feature is a Red Stapler?

Yes, but not in those words. Tell them which features you adopted and which you didn't, and why. Good PMs read this signal. Bad PMs ignore it. Either way, you've documented your position for the renewal conversation.

How does Seventh Sense avoid this problem?

Honestly, by being small and by talking to customers more often than we talk to analysts. Every feature in our roadmap traces to a specific customer problem we've seen across multiple portals. We deprecate features that aren't getting used. That's the discipline. It doesn't scale forever — every vendor eventually faces the same pressures — but we're aware of the gravity and we fight it.

The deeper point

Your martech stack isn't bloated because individual platforms are badly run. It's bloated because the incentive structure of platform vendors rewards shipping over adopting, breadth over depth, and competitor parity over customer outcomes. Knowing the pattern is the first step to filtering it.

The next time a vendor demo includes a feature you didn't know you needed, ask yourself who at the vendor was promoted for shipping it. The answer is rarely "the customer."

You can see Seventh Sense's actual ship list, including what we deprecated, on our product updates page. If you want to test whether our send-time work fits a real problem in your portal, the free trial takes about 15 minutes to surface the answer.

Who Actually Owns Email Marketing?

mike@theseventhsense.com (Mike Donnelly) — Wed, 22 Jul 2026 14:00:00 GMT

I've asked a version of this question in maybe two hundred discovery calls over the years: who owns email marketing at your company? The answers I get back are some of the most revealing diagnostics in B2B marketing. About one in five people answer cleanly. The rest start a sentence, qualify it twice, and end somewhere near "well, it depends on the email."

That hesitation is the whole problem. Email marketing ownership is the single most under-defined function in modern marketing ops, and the absence of a clean answer creates downstream chaos that the smartest tools in the world can't fully unwind.

The accountability crisis nobody named

Most B2B companies built their marketing org chart back when email was one thing. There was a person, or a team, called "Email." They wrote it, scheduled it, and reported on it. Twelve years later, that team probably still exists on paper, but the actual sends now come from four directions:

Demand gen runs nurture sequences for inbound leads.
Marketing ops runs the lifecycle and behavioral workflows.
The CRM admin runs operational emails (renewals, billing, account changes).
Sales enablement runs the sequenced one-to-many emails out of the sales tool.

Each of those four groups thinks they own a slice. None of them think they own the channel. When something breaks at the channel level — deliverability drops, unsubscribes spike, a customer gets seven emails in a week — there is no one person you can walk to whose job it is to have already noticed.

This is what I mean by the accountability crisis. It's not that people are shirking the work. It's that the work itself has no home.

The symptoms of fuzzy email marketing ownership

I can usually tell a portal has an ownership problem before I look at a single workflow. The symptoms show up in conversation:

Collisions nobody catches

Multiple emails land in the same inbox on the same day because four different people scheduled four different campaigns and no one was running the calendar. Everyone assumes someone else checked. Nobody did. This is the textbook symptom of the email collision problem.

Handoffs that drop the ball

The MQL handoff to sales triggers a sales sequence. The sales sequence runs in parallel with the marketing nurture that's still running. The contact gets two sets of "next-step" emails that contradict each other. Sales says marketing didn't suppress. Marketing says sales never told them. Both are right and both are wrong.

No audit trail when something goes sideways

A customer complains about over-messaging. You go to find out why. The marketing email tool shows three sends. The sales tool shows two. A third-party tool shows one. Nobody has a unified view, and nobody is responsible for assembling one. The investigation takes a day and answers nothing.

Strategy decisions made in isolation

Demand gen decides to send a webinar promo. Lifecycle decides to send a feature announcement. Neither one knows the other is sending, because the calendar lives in someone's head. The "calendar review" happens, sort of, in a Slack channel that the new person didn't get added to.

If two or more of those symptoms sound familiar, you don't have a tooling problem. You have an ownership problem dressed up as a tooling problem.

Why the obvious fixes don't stick

I've watched companies try to solve this in two directions, and both fail in predictable ways.

The "let's appoint a czar" fix

Somebody senior reads a Gartner marketing leadership report and announces a Director of Email. The Director of Email starts strong, runs a calendar review, builds a deliverability dashboard, and gets four months of clean execution. Then a reorg happens, or the Director leaves, or three teams quietly start routing around the calendar because "it's faster to just ship it." By month nine, you're back where you started, plus you've added a layer of process theater that nobody respects.

Czars work in dictatorships, not matrix orgs. If the Director of Email doesn't control the workflows, the templates, the sending tools, and the budget for at least three of the four teams above, they're a coordinator with a title.

The "let's centralize the tool" fix

Somebody else reads a Forrester report and announces that all email will now route through a single platform with a single approval queue. This works for two quarters. Then sales argues their cadence tool is faster. The CRM admin argues operational emails are different. The product team argues their lifecycle emails need to live in the product. The single queue fractures back into four queues, and you've added a procurement cycle for nothing.

Tools don't create ownership. They reflect it.

The org chart fix vs. the process fix

The companies I've seen actually solve this do one of two things, and the choice depends on company size.

The org chart fix (works for 200+ person companies)

You designate one role as the accountable owner of the channel — not the sender, but the owner. This person doesn't write or schedule most emails. They own three things: the rules of the road (frequency, suppression, naming, taxonomy), the channel-level metrics (deliverability, sender reputation, complaint rate), and the right to say no.

The "right to say no" is the part most companies skip and the part that makes the role work. If demand gen wants to ship a campaign that violates frequency, the channel owner can block it. If sales wants to add a new cadence that overlaps with a nurture, the channel owner can require a suppression. Without that authority, the role is decorative.

I call this person the channel owner. The title varies — sometimes it's "Director of Marketing Operations," sometimes it's "Email Center of Excellence Lead," sometimes it's the marketing ops manager wearing a second hat. The title matters less than the authority.

The process fix (works for smaller teams)

If you can't afford a dedicated owner, you can substitute a rigorous process — but only if the process is enforced by a system, not a meeting. Every send goes through a single queue. Every queue entry requires a template name, a target audience, a window, and a suppression check. The system, not a human, prevents collisions and overlapping sends.

This works at scale only if the queue is the only path. If there's a back door, people will use it.

What the channel owner actually does

Once you've appointed one (or built the equivalent process), the daily work looks like this:

Owns the rules of the road. Frequency caps in HubSpot, suppression logic, taxonomy, the naming convention for templates and lists. Reviews new workflows before they go live. Has the authority to require changes.
Owns the channel metrics. Reports on deliverability, complaint rate, list health, and over-messaging at the channel level — not per campaign. Pulls signals from external sources like Microsoft's Smart Network Data Services, not just the ESP dashboard. The campaign owners get their own metrics. The channel owner gets the inbox view, including delivery vs. inbox placement reality.
Owns the calendar. Not in the sense of scheduling every send, but in the sense of seeing every scheduled send across every tool. If they can't see it, they can't own it. This is the hardest part to operationalize and the part where tooling actually matters.
Owns the vendor relationships. ESP, deliverability monitoring, send-time optimization, third-party email tools. One throat to choke means the vendor stack stays coherent instead of accumulating tools that overlap and conflict.

Frequently asked questions about email marketing ownership

Should email be owned by marketing or marketing ops?

Both. The content of individual campaigns should be owned by whoever owns the audience — demand gen, lifecycle, sales. The channel itself should be owned by marketing ops, because they're the only team that can see across all four senders. The split is content ownership vs. channel ownership, and most companies conflate them.

What if my company is too small to have a dedicated email owner?

Then somebody on the marketing ops or demand gen team needs the channel-owner hat as a named second role. The risk for small teams isn't that the role is missing — it's that nobody has explicitly been told they have it. Name it, give the person authority, and revisit it when you grow past 50 people.

How do I prove there's an ownership problem to leadership?

Pull a list of contacts who received more than five emails from your company in the last 30 days, across all sending tools. The number will be larger than anyone on the leadership team expects, and the source of those sends will be impossible to attribute to a single owner. That's the case for the role.

Does fixing ownership fix deliverability?

It fixes the conditions under which deliverability can be managed. You still need the tools, the monitoring, and the discipline. But without a clear owner, deliverability is nobody's problem until it's everybody's emergency.

The deeper point

Email is the oldest digital channel and somehow it's the one with the worst-defined ownership. Paid media has a paid media manager. Social has a social manager. SEO has somebody. Email has — in too many companies — a committee.

The fix isn't a new tool or a new framework. It's a name on an org chart and the authority to enforce a few rules. Everything else is downstream.

If you want to see what your channel actually looks like before you have the org-chart conversation, the free trial of Seventh Sense will surface the over-messaging patterns and collisions across your portal. It won't appoint your channel owner. But it'll make the case for why you need one.

HubSpot's AI Workflow Builder: An Honest Review After 6 Months

mike@theseventhsense.com (Mike Donnelly) — Mon, 20 Jul 2026 14:00:00 GMT

HubSpot shipped the AI workflow builder in late 2025 with the kind of keynote treatment that makes you suspicious. I waited four months before I ran a real campaign through it, then another two before I trusted it with anything I cared about. Six months in, I have actual opinions, and the short version is: it's neither the revolution the launch deck implied nor the gimmick the contrarians on LinkedIn called it.

This HubSpot AI workflow builder review is what I'd tell a peer who asked me whether to use it on a real campaign tomorrow. We've now deployed it across enough customer portals to have a defensible point of view, including the cases where it earned its place and the cases where we turned it back off. Here's the unvarnished version.

What HubSpot's AI workflow builder actually does

Quick context for anyone who hasn't logged into HubSpot since the release. The AI workflow builder is HubSpot's attempt to let a marketer describe a workflow in natural language and have the system scaffold the branching logic, enrollment criteria, and action steps. You type "send a three-email nurture to new leads from the demo-request form, branching on industry," and the builder produces a draft workflow you can then edit. The official feature documentation lives in the HubSpot knowledge base if you want the canonical version.

It also pairs with HubSpot's broader Breeze AI suite to fill in content blocks, suggest send-time defaults, and surface optimization recommendations on existing workflows — part of the broader vendor trend documented across the Chiefmartec martech landscape. That second piece is the part most marketers underuse and is, frankly, where the actual value sits.

What it does well

Crediting fairly, here's what I'd give the AI workflow builder a checkmark on after six months:

Scaffolding speed. Going from idea to a draft workflow has gone from 30-45 minutes to roughly five. That's a real productivity gain for teams that build a lot of small workflows.
Standard pattern recognition. For the dozen-ish workflow patterns every B2B team uses (welcome series, lead-source nurtures, re-engagement, win-back), the builder produces a sane first draft that's usually 80% of the way to shippable.
Property mapping. The AI does a surprisingly good job of inferring which contact properties to use for branching, including custom properties it's seen elsewhere in your portal. This is the unsung feature.
Reduced syntax friction for non-technical marketers. The "I know what I want but can't navigate the workflow UI" problem largely disappears. Junior marketers who previously needed handholding can now ship competent workflows on their own.

Net of these, the builder pays for itself for teams building more than 5-10 workflows a quarter. For lower-volume teams, the time savings are smaller and the case is less clear.

What's still missing

Here's where I'd put X marks — the gaps that have surprised me, six months in, given how much the launch deck implied was solved:

No native orchestration awareness. The builder will happily create a workflow that overlaps with three other active workflows targeting the same contacts. It has no view of your existing automation graph and no way to suggest "this would collide with what you already have." This is the single biggest miss.
Weak handling of complex branching. Anything past 2-3 levels of nested branches degrades fast. The AI tends to produce branches that look right but route contacts strangely under edge conditions. Always re-test.
No real understanding of deliverability impact. The builder will suggest send-time defaults that look reasonable but ignore HubSpot email frequency caps, time-zone considerations, and over-messaging risk. It treats each workflow as if it's the only one running.
Generative content quality is brand-flat. The content blocks it produces are competent and voiceless. Fine for transactional copy. Wrong for anything that needs to sound like your brand. Plan to rewrite.
Limited visibility into AI decisions. When the builder makes a choice (which property to branch on, which content variant to default to), you don't see the confidence level or the alternatives it considered. The black-box problem applies here too.

The orchestration gap is the one that matters

If I had to call out one limitation that's costing customers real money, it's the orchestration blindness. The builder treats every workflow as a standalone artifact. In a real B2B portal with 15-30 active workflows, that's an architectural mistake.

The pattern we've seen repeatedly: a marketer uses the builder to ship a clean new workflow, the workflow performs well in isolation, and engagement on three other workflows drops by 6-12% over the next month because the new workflow is colliding with them. This is exactly the dynamic I covered in the email collision problem — orthogonal workflows that step on each other at the recipient level. Nobody connects the dots because the new workflow looks fine in its own dashboard.

This is the gap we built our Campaign Orchestration release to address back in February. The AI workflow builder produces individual workflows. Orchestration is the layer that ensures those workflows don't step on each other at the recipient level. They're complementary, not competing — but HubSpot's builder alone doesn't solve the orchestration problem.

The scorecard

For the readers who skim, here's the rating card I'd hand to a peer asking what they should expect:

Speed of drafting workflows: Checkmark. Real time savings.
Quality of generated branching logic (simple): Checkmark. Sane defaults, easy to edit.
Quality of generated branching logic (complex): X mark. Re-validate everything past three branches deep.
Cross-workflow orchestration awareness: X mark. Doesn't know other workflows exist.
Send-time defaults: X mark. Generic, ignores recipient context.
Generative content quality: Partial credit. Usable for transactional, weak for brand voice.
Property mapping intelligence: Checkmark. Better than expected.
Explainability of AI decisions: X mark. Limited visibility into why the AI chose what it chose.
Integration with Breeze AI optimization: Checkmark. Underrated piece, worth turning on.
Suitability for high-stakes campaigns: Partial credit. Use with human-in-the-loop email workflows review.

When to use it (and when to skip it)

Six months of usage gives me clear opinions on the use cases:

Use the AI workflow builder when:

You're building a standard workflow pattern (welcome, nurture, re-engagement) and want to skip the scaffolding time.
The workflow is going to run in isolation and isn't going to compete with other workflows for the same inbox.
You have a junior marketer who needs to ship workflows without deep HubSpot expertise.
You're prototyping ideas quickly and want to see what a workflow could look like before committing to building it manually.

Skip it (or use it with heavy human review) when:

The workflow touches your highest-value contacts or biggest accounts.
You already have 10+ active workflows and adding another raises orchestration risk.
The campaign requires brand-voice copy that can't be generic.
The branching logic is complex enough that "looks right" isn't good enough — you need to validate every path.

How it compares to alternatives

The realistic comparison set isn't "AI workflow builder vs. manual HubSpot workflow building." Most teams will do both. The more useful comparison is what to pair it with.

vs. manual building: Faster for standard patterns, equivalent for complex logic, worse for cross-workflow coordination. Net positive for most teams.
vs. third-party workflow tools: The AI workflow builder is strictly worse than purpose-built orchestration tools for managing cross-workflow conflicts — that's not what it's designed for — but it's strictly better than nothing for accelerating workflow creation.
vs. doing nothing: If your team is bottlenecked on workflow creation, turn it on tomorrow.

The right mental model: HubSpot's AI workflow builder is a workflow-creation tool, not a workflow-management tool. Pair it with whatever you use for orchestration, deliverability monitoring, and recipient-level send-time logic — ideally something that complements rather than overlaps.

Frequently asked questions about the HubSpot AI workflow builder

Is HubSpot's AI workflow builder included in all subscription tiers?

The core builder is available in Professional and Enterprise Marketing Hub tiers, with feature depth varying by tier. Some of the more advanced Breeze AI integrations require Enterprise. Check the current pricing page — HubSpot has been adjusting the tier mapping every couple of quarters.

Can I trust the AI workflow builder with my biggest campaigns?

With human-in-the-loop review, yes — for standard patterns. Without review, no — for any campaign that matters. The builder produces sane first drafts, but the orchestration and brand-voice gaps mean you should treat the output as a starting point, not a finished workflow.

Does the AI workflow builder integrate with third-party tools like Seventh Sense?

The workflows generated by the builder are standard HubSpot workflows that integrate with the same third-party tools as any manually built workflow. Our scheduler operates on the send-time layer regardless of whether the workflow was AI-generated or hand-built, so the integration is seamless.

Will HubSpot fix the orchestration blind spot?

I'd expect them to in time — the gap is well-known and the demand is clear — but I wouldn't plan around it. The orchestration problem is hard, and "AI builder that's aware of every other AI builder's output" is a much bigger architectural lift than the keynote demos suggest. Solve it with a complementary layer in the meantime.

Where to go from here

The honest summary: turn the AI workflow builder on, use it for standard patterns, validate it for complex ones, and don't expect it to solve problems it wasn't designed to solve. The biggest mistake I see is teams treating it as a complete workflow management system instead of an accelerated workflow creation tool. Those are different jobs.

If you want to see what's missing from HubSpot's AI builder — specifically, recipient-level orchestration and send-time intelligence — the free trial of Seventh Sense connects in about 15 minutes and adds the layer the builder leaves out. Use both. They're complementary by design.

Why 'Human-in-the-Loop' Email Workflows Outperform Pure Automation

mike@theseventhsense.com (Mike Donnelly) — Fri, 17 Jul 2026 14:00:00 GMT

A VP of demand gen I work with told me a story I keep coming back to. Her team had built what she called "the dream workflow" — thirty-two branches, full AI scoring, dynamic content, autonomous send-time. It ran flawlessly for six weeks. In week seven, a product naming change shipped, and the workflow autonomously sent 18,000 emails referencing the old product name to her largest enterprise list. Nobody caught it because nobody was in the loop.

This is the era we're in. "Set it and forget it" is the marketing automation philosophy of 2015, and it's been promoted from best practice to load-bearing assumption without anyone stopping to ask whether it still holds. It doesn't — not for high-stakes email, not when AI is making more of the decisions, and not when failure modes have gotten harder to detect. The pattern echoes recent AI safety research on how oversight should scale with model capability. Human in the loop email isn't a step backward. It's the design pattern that wins in the era of more capable, more autonomous tooling.

Why pure automation fails in subtle ways

Automation failures used to be loud. A broken merge tag would produce "Hi ," and you'd hear about it within ten minutes from a Slack message that started with "uh." Modern failures are quieter and more expensive.

Here are the four patterns I see most often in HubSpot portals running fully autonomous workflows:

Drift failures. The workflow keeps working perfectly while the world around it changes. New product name, new pricing tier, new ICP. The workflow ships outdated content to thousands of recipients before anyone notices — the kind of breakdown that surfaces in a HubSpot email collision audit after the damage is done.
Compounding failures. One step misclassifies a contact. The next ten steps treat the misclassification as ground truth. By the time it surfaces, you've nurtured a customer down the wrong path for six weeks.
Edge-case failures. The workflow handles the 95% case beautifully and quietly mangles the 5% — usually your biggest, most strategic accounts that don't fit the standard pattern.
AI-confidence failures. The AI feature ships the wrong send with full conviction because there's no uncertainty signal. Generative copy with a hallucinated stat, dynamic offers with a pricing error, "smart" segmentation that excludes the wrong cohort.

None of these get caught by your QA at workflow launch. All of them get caught by a human who has the right view at the right moment. The design question is where to put that human.

The "stakes vs. volume" matrix for review checkpoints

Not every workflow needs human review at every step — that's the strawman opponents of human-in-the-loop reach for. The right framework is a two-by-two: stakes on one axis, volume on the other.

High stakes, low volume: Human approval required before every send. (Executive newsletters, enterprise account communications, anything legally sensitive.)
High stakes, high volume: Human approval at the campaign template level, sampling review of individual sends. (Launches, major nurture campaigns, content with brand voice risk.)
Low stakes, low volume: No review needed. Let the automation run. (Internal notifications, transactional confirmations, simple drip sequences.)
Low stakes, high volume: Automated review with human escalation. Set anomaly thresholds and route exceptions to a human. (Standard nurture, welcome series, re-engagement campaigns.)

The mistake most teams make is treating all four quadrants the same way — usually applying the "low stakes, low volume" rule to everything. The result is high-stakes campaigns running without oversight and low-stakes campaigns generating review fatigue that nobody actually performs.

Where to put the human checkpoint

For each workflow, there are roughly four places a human review can live. Each catches different failure modes.

1. At the input

Before the workflow runs at all. Review of segment definition, content templates, branching logic. Catches drift and compounding failures at the source. Cheap to do, easy to skip, highest leverage of any checkpoint.

2. At the AI decision point

When an AI component makes a non-trivial decision — subject-line selection, send-time, content variant. Surface the decision and the confidence level to a human reviewer, default to send-after-X-hours if no review, escalate uncertain decisions to immediate review. This is what we built into our orchestration logic and what most "AI-native" workflows lack entirely.

3. At the threshold

Anomaly detection on aggregate metrics — bounce rate spike, engagement drop, list movement out of pattern. Pause the workflow and ping a human before the next batch ships. This is the single most effective single point of intervention for catching production failures early, especially when paired with the HubSpot email metrics that lie filter — some dashboards will quietly mask the spike you need to see. HubSpot's workflow anomaly tooling has improved meaningfully; see HubSpot's knowledge base for the current setup.

4. At the sample

For high-volume sends, route 1-2% to a "preview" cohort that ships an hour ahead of the main population. Human reviews the preview engagement. Catches drift and AI-confidence failures before they compound across the full list.

Most B2B workflows benefit from checkpoints at positions 1 and 3 at minimum. Anything touching AI-generated content or autonomous decisioning needs position 2 as well. Position 4 is for the largest, most consequential sends only — product launches, major announcements, sender-reputation-sensitive campaigns.

The principle: AI does the work, humans set the constraints

This is the design pattern I keep coming back to: AI is good at executing within constraints. Humans are good at setting and adjusting the constraints. Confusing these jobs is what breaks workflows.

An AI scheduler is great at picking the right send time for each recipient. It's bad at deciding whether the campaign should run this week at all given a competing product announcement. A human is great at the second decision and slow at the first. The workflow that wins assigns each task to the right operator.

This is also how we think about our scheduler. The AI handles per-recipient send-time optimization — thousands of micro-decisions per campaign that no human could make reliably. The human handles the campaign-level decisions about what runs, what doesn't, and what gets flagged for sensitive treatment, including which blackout periods apply when. We shipped Campaign Orchestration in February 2026 specifically to make those human-set constraints expressible at the recipient level instead of the campaign level — which is where the actual leverage is.

The objection: human review doesn't scale

The most common pushback I hear: "We can't add humans into every workflow — we don't have the headcount." This conflates two different things.

The wrong version of human-in-the-loop has a human approving every send. That doesn't scale, and shouldn't. The right version has a human reviewing definitions, templates, and anomaly alerts. A single marketer can effectively oversee dozens of workflows on the second model. The work is review-and-approve, not draft-and-send.

The other version of the objection is that humans are slow. True, but the slowness is concentrated in the wrong places. Adding a 24-hour review window to a template change is not what's slowing your campaigns down. Endless internal review of finished copy is. Move the review earlier in the workflow design and the calendar gets faster, not slower.

How to retrofit an existing workflow with the right checkpoints

You don't need to rebuild your workflows from scratch. Here's the order I'd add checkpoints to an existing automation:

Add anomaly alerting first. If a campaign starts bouncing or unsubscribing above threshold, pause it. This is the cheapest, highest-ROI checkpoint.
Add template review next. Any content template change requires a second pair of eyes before it ships. Catches drift failures.
Add AI confidence review third. Any AI-generated content with low model confidence routes to human review. Catches AI-confidence failures.
Add sampling last. For your largest sends only, route a preview cohort an hour ahead. Catches edge-case failures.

Most teams skip directly to step four — preview cohorts — which catches the fewest failures. Start with anomaly alerts. They catch the most production damage with the least operational overhead.

Frequently asked questions about human in the loop email

Does human-in-the-loop mean abandoning automation?

No. It means assigning human review to the parts of the workflow where judgment matters — constraint-setting, template approval, anomaly response — and leaving automation in charge of the execution-level decisions where it outperforms humans. The two are complementary, not competing.

How do I convince a leadership team that's bought into "AI agents" to add human checkpoints?

Walk them through one specific failure scenario from your portal — or borrow one from a peer — and ask which checkpoint would have caught it. The conversation moves from abstract ("AI vs. humans") to concrete ("at what point in this workflow would we have seen the misclassified segment?") and almost always lands in the same place: human-in-the-loop, just at the right altitude.

What's the right cadence for reviewing workflow performance?

Weekly for anomaly review. Monthly for template freshness. Quarterly for workflow architecture. Annual for a full audit of which workflows still serve their original purpose. Most teams over-index on the first and under-invest in the rest.

Where does Seventh Sense fit in a human-in-the-loop workflow?

The scheduler is the autonomous layer — per-recipient send-time decisions that humans shouldn't be making. The orchestration and analytics layers are designed to surface the data humans need to set good constraints. The split mirrors the broader principle: AI executes, humans set the rules.

Where to go from here

The marketing automation philosophy of the next five years is going to look more like "co-piloted" than "set and forget." Teams that adopt the co-pilot model early will outperform teams that double down on autonomy — not because autonomy is bad, but because the failure modes are getting more expensive and the catch rate on pure automation isn't keeping up.

If you want to see how a HubSpot portal looks with recipient-level AI execution and human-set constraints, the free trial of Seventh Sense takes about 15 minutes to install and surfaces the data your team needs to make smarter constraint decisions. The AI handles the per-recipient scheduling. You handle the parts that benefit from judgment. That's the division of labor that wins in 2026.

The $130B AI Capex Boom and What It Means for Email Marketers

mike@theseventhsense.com (Mike Donnelly) — Wed, 15 Jul 2026 14:00:00 GMT

In the first quarter of 2026, the four largest hyperscalers — Google, Microsoft, Amazon, and Meta — spent more than $130 billion combined on data centers and AI infrastructure. In ninety days. The numbers are auditable in their SEC filings and grounded in the Bloomberg coverage of every earnings cycle. The headlines treat this as a tech-industry story. It is mostly a marketing-industry story, and the second-order effects on email are going to be larger and stranger than anything we've planned for.

Here's the macro-to-micro version: the AI infrastructure email impact isn't some abstract future thing. The compute being poured into the ground right now is going to land in your HubSpot portal over the next 18 months in concrete ways. Some of it will be great for marketers. Some of it will be quietly destructive. Most of it will be invisible until it isn't.

What $130B in AI capex actually buys

To make this concrete: the Q1 2026 capex from the four largest cloud providers is funding roughly three categories of buildout, all of which matter for email:

Inference capacity. The compute required to run trained models in production, at scale, cheaply. This is the part that affects per-send economics on AI features. As inference gets cheaper, things that were too expensive to ship in 2024 become standard in 2026.
Specialized model training. Models trained on narrow domains, including marketing-specific data sets that didn't exist commercially three years ago. Expect the next generation of email AI to be trained on email-shaped data, not general internet text.
Mailbox-provider AI. Don't forget the receiving side. Gmail, Outlook, and Apple Mail are all reinvesting heavily in inbox AI — filtering, summarization, prioritization. Their AI capex is going to reshape your delivery environment whether your vendor ships AI features or not.

That third bucket is the one most marketers haven't priced into their planning yet. Let's start there.

The mailbox is getting smarter faster than your sending stack

Here's an asymmetry worth sitting with: the AI infrastructure being built right now is being deployed on the receiving end before it's being deployed on the sending end. Mailbox providers have larger budgets, tighter user-facing feedback loops, and a clear business reason to invest. They're shipping inbox AI that does three things that materially change your job:

Summarization. Gmail's AI will summarize your three-paragraph nurture email into two sentences before the recipient ever reads it, as Google has documented across its Gmail AI announcements. Your subject line and pre-header now compete with an AI-generated synopsis of your own copy.
Prioritization. Inbox AI ranks senders by predicted relevance. If your sends look generic to the model, they get triaged into the "low priority" stack before a human sees them, regardless of whether they cleared the spam filter.
Reply suggestions. One-tap replies pull copy from your email. Whether that text reflects the action you wanted is now a function of how the model parsed your message.

The implication: email is no longer a direct conversation with a human. It's a conversation mediated by an AI that's deciding what to surface, summarize, and suggest. Writing for that mediated environment is a different craft than writing for an inbox in 2019 — and it's part of why open rates post-MPP have stopped meaning what marketers think they mean.

Second-order effects email marketers should plan for in 2026-2027

Working forward from the capex, here are the specific changes I'd expect to see hit B2B email marketing over the next eighteen months. Some of these are happening now. The rest are the trajectory.

1. Personalization gets dramatically cheaper

The dominant cost of personalization today is engineering and data, not compute. As inference gets cheaper, the math changes. Generating subject-line variants per recipient, scoring content blocks per persona, and dynamic body insertion all become economically defensible for mid-market senders, not just enterprise. Expect HubSpot, Marketo, and the rest to ship features that assume this cost curve.

2. Deliverability AI moves from add-on to baseline

The AI that watches your sender reputation, predicts engagement drops, and flags anomalies is currently sold as a premium add-on. With cheaper inference, this becomes table stakes — the way SPF/DKIM/DMARC checks for HubSpot sender reputation moved from "specialist feature" to "checkbox in setup" over five years. The vendors who don't ship it natively in 2027 will lose deals.

3. Generative content moves into the editor, not the autopilot

The autonomous-agent vision keeps getting deferred. What's actually shipping is generative AI inside the composer — better suggestions, smarter rewrites, faster localization. The capex makes these features fast and cheap enough to integrate into every editor by default. Expect this everywhere within twelve months.

4. The send-time category consolidates around recipient-level models

"Best time to send" tools that pick one window per audience are going to look as quaint as desktop-only email previews. Cheap inference makes per-recipient modeling the default, which is the architecture our scheduler has used since 2019 and is now being adopted across the category — with the measurable proof points for send-time optimization now widely documented. The Campaign Orchestration release we shipped in February 2026 is a preview of where the rest of the market is headed.

5. Mailbox-AI optimization becomes its own discipline

Just as SEO emerged when search engines started ranking pages, "mailbox AI optimization" is the discipline emerging now. Writing copy that summarizes well, structuring CTAs that survive prioritization, formatting emails that reply-suggestions render correctly — this is the next layer of craft. The marketers who get good at it early will have a window of asymmetric advantage.

What this means for your 2026-2027 budget

Three concrete budget moves worth making now, in priority order:

Reallocate from generative tools toward infrastructure AI. The dollars spent on AI copywriters in 2025 should mostly go to deliverability, orchestration, and send-time AI in 2026. The ROI gap is widening fast.
Train your team on writing for mediated inboxes. The bigger gain is not buying new AI. It's getting your existing copywriters to write for an environment where AI sits between you and the reader. This is a workshop, not a software purchase.
Audit your stack for vendors who can't show their AI roadmap. Any martech vendor without a credible AI infrastructure investment is going to be priced out of competing on personalization, deliverability, and send-time by 2027. Their renewals are the line items most worth pressure-testing this year.

The contrarian take: most of the capex is wasted, and that's fine for you

Worth saying clearly: a meaningful fraction of the $130B in AI capex is going to be revealed, in retrospect, as overbuilt. That's how every infrastructure boom works — railroads, fiber, cloud, AI. Overbuilding is the mechanism by which the cost curve drops far enough for normal businesses to use the technology.

For email marketers, this is unambiguously good news. You don't have to fund the buildout. You get to use the depreciated infrastructure once the cycle prints capacity into the ground. The job is positioning your stack and your team to take advantage of it as the cost curve drops, not predicting which hyperscaler wins.

Frequently asked questions about the AI infrastructure email impact

Will AI capex make email cheaper to send?

The sending economics won't change much — SMTP delivery is already commoditized. What changes is the per-send economics of AI features layered on top of sending: personalization, send-time optimization, deliverability monitoring. Those drop in cost meaningfully as inference gets cheaper, which is how features that were enterprise-only move down-market.

How worried should I be about Gmail's AI summarizing my emails?

Concerned, but not panicked. Gmail's summarization is real and affecting engagement now, but the fix is craft, not technology: write tighter copy, lead with the action, and design CTAs that survive summarization. Marketers who adapt will outperform those who don't, and the adaptation isn't expensive.

Does the capex boom mean I should delay buying AI tools?

For generative tools, possibly — prices are dropping and features are improving fast enough that buying now means buying obsolescence. For infrastructure AI (deliverability, send-time, orchestration), buy now — the production track record matters more than the price curve, and the compounding benefit starts the day you turn it on.

Will hyperscaler AI features compete with marketing-specific AI vendors?

In some categories, yes. In email specifically, no — the domain expertise required to build deliverability-grade AI is not in the AWS or Azure playbook, and the data depth required is unique to vendors who've been in the space. Expect consolidation among marketing-AI vendors, not displacement by hyperscalers.

Where to go from here

The AI capex story is the kind of macro trend that's easy to ignore because it doesn't show up in your weekly metrics — until it does, all at once, when a mailbox provider ships a feature that reshapes your engagement curve overnight. The marketers who plan for the trajectory get to surf it. The ones who don't get washed.

If you want to see how recipient-level AI orchestration changes the math in your HubSpot portal, the free trial of Seventh Sense takes about 15 minutes to set up and starts modeling individual recipient behavior on day one. You'll see the kind of AI that's already crossed the gap from capex to results, in your own data.

The AI Hype Cycle in Marketing: What's Real and What's a Demo

mike@theseventhsense.com (Mike Donnelly) — Mon, 13 Jul 2026 14:00:00 GMT

A marketing director I respect demoed me a tool last week that claimed to use AI to write entire email sequences from a one-sentence brief. The demo was beautiful. The output, when we ran it against a real ICP brief from one of his customers, was a brochure-grade pile of generic claims that would have been embarrassing to send.

This is the state of AI in email marketing right now. I'm convinced that 90% of what's pitched as AI is just clickbait wrapped in a product UI. The other 10% is the most interesting thing to happen to email since deliverability filters got smart — and the broader picture, well-documented in the annual State of AI report, is that the gap between demo capability and production reliability is wider than anyone selling pitches will admit. The job, for everyone buying or building marketing software in 2026, is telling those two apart before you put one in front of your list.

Why the AI hype cycle hits email marketing harder than other categories

Email is the most demoable category in martech. The output is text, the inputs are short, and the bar for "looks impressive" in a five-minute pitch is comically low. Anyone can wire a large language model to a subject-line generator, plug it into a sandbox account, and produce a screenshot deck.

That's why your inbox — both the one you send to and the one you receive from — is full of features that work in the booth and break in production. The features that survive contact with real lists are a much smaller set. Here's how I sort them.

The Gartner-style hype curve for AI email features in 2026

The framing isn't novel — Gartner's research methodology has been the standard lens for new tech categories for years — but it maps unusually cleanly to where AI email features sit right now. Plot any AI email feature on this curve and you'll know what to do with it:

Peak of inflated expectations. Autonomous campaign agents. AI-generated personalized video. Real-time generative subject lines per recipient. These get the keynotes. None of them is shipping measurable lift at scale yet.
Trough of disillusionment. Generic AI subject-line writers, "smart" send-time tools that just pick 10 a.m. on Tuesday, AI copywriting tools that produce passable middle-school book reports. Marketers tried these in 2023-2024 and quietly turned them off.
Slope of enlightenment. Recipient-level send-time models, deliverability anomaly detection, content-fatigue prediction, over-messaging tracking. These are doing real work in real portals.
Plateau of productivity. Spam-filter learning models, mailbox provider scoring, subject-line A/B significance testing. Boring, invisible, foundational. Most marketers don't even think of these as AI anymore.

The pattern: the AI that actually moves numbers tends to be invisible. The AI that gets pitched tends to be visible. Inverse correlation between demo quality and production value is the single most useful rule of thumb I've found for evaluating this category.

Demo-only versus production-ready: the four tests

When a vendor shows me an AI feature, I run it through four questions before I take it seriously. None of these is original. All four together are surprisingly effective.

1. Does it have a meaningful integration with the data?

An AI feature that doesn't read your historical send data, engagement history, or recipient behavior is, at best, a fancy autocomplete. Real AI in email marketing requires data depth. If the demo works with a fresh sandbox account and no historical context, it will work the same way in production — which is to say, not at all.

2. Can the vendor show me the variance reduction, not the average?

Every AI vendor will tell you their feature improved open rates "by 23%." Almost none can tell you what happened to the bottom quartile of recipients. The bottom quartile is where deliverability damage actually happens. If the vendor can't show variance, they're showing you a cherry.

3. What happens when the model is wrong?

Production-ready AI fails gracefully. It defaults to a sensible baseline, surfaces uncertainty, and lets a human override. Demo-ware fails confidently — it ships the wrong subject line to your largest customer with full conviction. Ask any AI vendor what their fallback behavior is. The good ones have a thoughtful answer. The bad ones change the subject.

4. How long has the feature been in production?

AI features that ship in week one and get keynote slots in month two are demos. AI features that have been live for 18 months, gotten boring, and quietly print value are production. There's no shortcut around time-in-market for this category.

What's actually working in AI in email marketing right now

Setting aside the hype, here's what I see working in real B2B HubSpot portals in 2026:

Recipient-level send-time models. Not "best time to send for your audience" — that's a 2017 idea. The current generation models each recipient's behavior independently and schedules accordingly. This is what our scheduler has done since 2019, and the proof on send-time optimization in HubSpot is now well-documented across portals.
Deliverability anomaly detection. AI watching your sender reputation signals and alerting before the mailbox providers do. Lower-glamour than generative anything, but the highest-ROI AI investment most B2B teams can make.
Over-messaging and content-fatigue prediction. Models that recognize when a recipient is about to disengage based on send cadence and content overlap — the same dynamic I covered in the post on over-messaging as the silent deliverability killer. We shipped a version of this in April 2026 as part of our Analytics UI enhancements, and it's quickly become the feature audits start with.
Subject-line significance testing. Not subject-line generation. Significance testing that uses Bayesian methods to call A/B winners faster and more reliably. Unsexy, very valuable.

What's still mostly demo-only

And here's what I'd hold off on, even though every vendor pitch deck has one:

Fully generative email body copy. The output is generic enough that it actively damages your brand voice. Useful as a first-draft tool for a human; dangerous as an autopilot.
"Autonomous agent" campaign builders. Marketed as set-and-forget. In practice, they require more babysitting than a manual workflow because their failure modes are non-obvious.
Real-time per-recipient subject-line generation. Sounds amazing. Produces subject lines that get flagged as spam at higher rates than your control because they look algorithmically generated to mailbox providers — which is exactly what they are.
AI-personalized images and video at scale. The compute cost-per-send wipes out the lift. The compliance review wipes out what's left.

How to evaluate any new AI email feature in five minutes

Here's the cheat sheet I use when I'm in a vendor demo and trying to figure out which side of the curve a feature is on. Ask, in order:

"Show me a customer who's been using this for over a year."
"What's the variance in lift across the customer base, not the average?"
"What does the model do when the data is sparse?"
"Walk me through a failure case you've seen in production."

If the vendor has good answers to all four, you're looking at a production-ready feature. If three of the four answers are some version of "great question, let me follow up," you're looking at a demo that hasn't lived long enough to be honest with itself yet.

Frequently asked questions about AI in email marketing

Is AI in email marketing worth investing in right now?

Yes — but specifically in the categories that have moved past the demo phase: recipient-level send-time optimization, deliverability anomaly detection, over-messaging tracking, and A/B significance testing. Hold off on autonomous agents and fully generative bodies until they've spent more time in production.

How do I know if an AI feature is just a wrapper around ChatGPT?

Ask the vendor what proprietary data the model trains on. If the answer is "we use a large language model and your account data as context," it's a wrapper. Wrappers can be useful, but they're rarely defensible and rarely worth premium pricing.

Will AI replace email marketers?

No. AI is shifting the work, not eliminating it. The marketers who get the most leverage from AI are the ones who use it for the unglamorous backend — orchestration, deliverability, fatigue prediction — and keep humans on the creative and strategic decisions where judgment still beats statistics.

What's the single AI feature that pays back fastest in a HubSpot portal?

Recipient-centric send-time optimization, by a wide margin — and specifically the first-hour engagement window work that compounds across deliverability and pipeline. It's the AI category with the longest production track record, the clearest measurement story, and the most direct line to revenue. Everything else is a second-tier investment until that one is in place.

Where to go from here

The temptation in AI right now is to keep trialing new things in the hope of stumbling onto a breakthrough. The more reliable move is to deploy the boring, proven AI in the parts of your stack where it's already paying off — and let the hype cycle run its course on the rest.

If you want to see what production-grade AI looks like inside a HubSpot portal, the free trial of Seventh Sense connects in about 15 minutes and starts modeling your recipients individually from day one. No autonomous agents. No generative anything. Just the AI that ships results.

Cold Contact Email Strategy for HubSpot Teams

mike@theseventhsense.com (Mike Donnelly) — Fri, 10 Jul 2026 14:00:00 GMT

A few years ago, I was on a quarterly review call with a CRO who'd just been handed the marketing function. He pulled up the dashboard, looked at the database size, and said: "Cut it in half. I want this list pruned by end of quarter." His marketing director, sitting next to me, looked like she'd been asked to set fire to the building. Six months later, the list was half the size, the open rate had doubled, the pipeline was down 30%, and the CRO was now blaming the macro environment in his board update.

That's the pattern. Pruning produces a visible win on a dashboard and an invisible loss in the pipeline, and by the time the loss becomes visible, three other things have changed and no one can attribute the damage. A real cold contact email strategy doesn't start with scissors — especially when the mailbox-provider data via Google Postmaster Tools shows that engagement, not list size, is what drives placement. It starts with the question: which of these contacts are genuinely dead, and which are just quiet right now?

Why pruning is the most overrated email tactic

The Hygiene Hawks — the camp I described in an earlier post on the list management framework that suppresses aggressively to protect deliverability — treat pruning as the responsible adult choice. It has a moral weight to it. "We don't want to spam people who aren't interested." That framing makes pruning feel virtuous, which is why it's so hard to argue against.

Here's the problem: pruning conflates three different populations into one decision.

The genuinely dead. They left the company, changed careers, or were never a good fit in the first place. Pruning them is correct.
The merely quiet. They're still in your ICP, still at the company, still receiving your sends — they just aren't opening this quarter because their priorities shifted. Pruning them is a mistake.
The selectively engaged. They open your product update but not your nurture, or they read your CEO's posts but ignore your webinar invites. They're showing you which content matters; pruning them is a misread.

A pruning rule that triggers on "no opens in N days" treats all three populations identically and suppresses all of them — and post-MPP, "no opens" is an increasingly bad proxy for "no engagement," as I covered in the post on the 90-day inactivity rule. The first group should be suppressed. The second should be re-engaged at lower frequency. The third should be re-segmented into the content they actually want. Lumping them together is what makes pruning a blunt instrument.

The Start-Up Seller's version of the same mistake

I've written about the Big Brand Blaster — the enterprise marketer who blasts everyone forever. Pruning is the opposite archetype's mistake. I call them the Start-Up Seller: a small marketing team at a Series A or B SaaS company, told to "stay lean," running on a HubSpot Professional seat with one person managing the entire list. The Start-Up Seller prunes aggressively because she doesn't have the bandwidth for a re-engagement campaign and because every contact above her HubSpot tier's marketing-contact limit is costing real money.

Her math is reasonable in the short term. She saves $400 a month by staying under the next tier. The contacts she pruned would have produced maybe one or two opportunities this quarter, none of which she can prove ex post. The savings show up in the next finance review; the lost pipeline doesn't show up anywhere.

The principle the Start-Up Seller misses is this: cold contacts have option value, and option value compounds. A contact who downloaded a comparison guide eighteen months ago and went quiet is not worth zero today, even if your open rate report shows them as inactive. They're worth whatever the probability is that they re-enter the buying cycle in the next year, multiplied by your average deal size. For most B2B SaaS products, that number is well above the marketing-contact cost of keeping them.

What top HubSpot teams do instead

The teams I see managing cold contacts well don't use one technique — they use a sequence of three, applied in order, with the cheapest interventions first.

Segmented re-engagement

Cold contacts go into a re-engagement flow segmented by what they originally engaged with. The contact who downloaded a security whitepaper two years ago gets a security-themed re-engagement — new research, a customer story, a "what's changed since 2024" framing. The contact who attended a webinar on integrations gets a re-engagement about the new integrations you've shipped. Templated "we miss you" emails get ignored; content that matches the original interest gets opened.

This is more work than a generic re-engagement campaign. It's also where the recovery rate is two to three times higher in the portals I audit. The investment is in the segmentation, not the send.

Low-frequency win-back

After the initial re-engagement campaign, contacts who didn't respond don't go straight to suppression. They go into a low-frequency win-back pool — one carefully chosen send per month, focused on original research, product launches, or industry milestones. The cadence is low enough that you're not hurting your engagement ratio. The content quality is high enough that the contacts who eventually come back recognize the brand instead of treating it as spam.

This stage usually lasts six to twelve months. The recovery rate per month is low, maybe 1-2%, but it compounds. Over a year, you'll re-engage another 10-20% of the contacts who didn't respond to the initial campaign. The mechanics here overlap with the graymail suppression vs. re-engagement decision — suppression is final, recycling preserves option value. That's pipeline you would have lost entirely under a pruning model.

Genuine death identification

The last step — and the one that finally justifies suppression — is identifying contacts who are genuinely dead versus the merely quiet. The signals that matter here are not the ones most teams use:

Hard bounces. If a contact's email has bounced repeatedly with a "user does not exist" response, they've left the company. Suppress. (Gmail's sender guidelines are clear that repeated hard bounces actively damage sender reputation.)
Domain abandonment. If the contact's company domain stops responding entirely across multiple contacts, the company is likely defunct or has migrated. Suppress.
Verification failure. Periodic email verification via a third-party tool will catch dead addresses that haven't bounced yet. Suppress the failures.
Absolute silence for 18+ months. No opens, no clicks, no site visits, no form fills, nothing from the re-engagement campaigns. At this point, you've genuinely earned the suppression decision.

Notice what isn't on this list: "didn't open for 90 days." That's not a death signal. It's a quiet signal. The pruning frameworks treat them as the same; the better teams don't.

The pipeline math that makes a real cold contact email strategy worth building

I'll keep this short because the numbers from real audits do most of the work.

A B2B SaaS company with a 50,000-contact HubSpot database, an average deal size of $40,000, and a 1% annual conversion rate from cold contacts to closed-won has roughly $20M of latent pipeline sitting in their list. A pruning rule that suppresses 30% of cold contacts retires $6M of that latent pipeline. A recycling model that re-engages even 15% of the same population recovers $900K of that latent pipeline per year, indefinitely. The recycling model wins by an order of magnitude as long as you can sustain it operationally.

The reason most teams don't build the recycling model isn't that the math doesn't work. It's that the operational cost — building the segmented re-engagement flows, maintaining the win-back cadence, running the verification — is too high to justify against the next-quarter dashboard.

Frequently asked questions about cold contact email strategy in HubSpot

How do I segment cold contacts for re-engagement when I don't have rich original-source data?

Start with what HubSpot does have: original source, lifecycle stage at the time they went cold, and any topic clusters from content downloads. Even rough segmentation — "downloaded any security content" vs. "downloaded any integration content" — outperforms a single generic re-engagement campaign by a wide margin.

What's the right send frequency for a low-frequency win-back pool?

One send per month is the floor for staying recent in the inbox; two sends per month is the ceiling before you start hurting your engagement ratio. The exact number matters less than picking one and protecting it — the win-back pool should never get pulled into an ad-hoc campaign because someone wanted "one more send to the whole list."

How do I prove the win-back program is worth the operational cost?

Tag every contact who enters the win-back pool, then measure conversion to opportunity over the following 12 months versus a control cohort that was suppressed at the same point. In my experience, the win-back cohort produces 3-5x the opportunity rate of the suppressed cohort, even though the absolute numbers are small. That ratio is the case for the program.

Does this strategy work for transactional or product-led growth motions?

The strategy is more important for sales-led B2B than for PLG, because PLG buyers tend to come back through self-serve sign-up rather than email. For PLG companies, the cold contact list is still worth maintaining for product announcements and pricing changes, but the win-back ROI is lower and pruning has a stronger case.

Where to go from here

If your team is currently pruning by inactivity, the highest-leverage change you can make this quarter isn't a new tool — it's pausing the suppression rule for a month while you classify the contacts it would have caught into genuinely dead, merely quiet, and selectively engaged. The classification work itself will change your team's understanding of the list in ways that no dashboard can.

Seventh Sense's engagement scoring is the operational layer that makes a recycling-first cold contact email strategy sustainable. It scores every contact on the active-to-dormant spectrum, automates send-time and frequency adjustments by score, and surfaces the contacts whose silence is more likely "quiet" than "dead." The free trial connects to your portal in about 15 minutes and runs the classification on your real list, so you can see — before you suppress anyone — how many of your "cold" contacts are actually the merely quiet ones you don't want to lose.

Pruning is the move that feels responsible. The recycling-first cold contact strategy is the one that pays.