Enterprise vs SMB sales cadence (why one size doesn't fit)

The difference between an enterprise and an SMB cadence is not length. It is what the cadence is trying to solve. SMB outbound is a throughput problem: one person decides, the window is short, and the metric is how many accounts a rep can work per week. Enterprise outbound is a coverage problem: several people must each be reached, in an order that makes sense, and the metric is how much of the buying group you have a live contact with. Run either design against the other's problem and you get a predictable failure, described below with the arithmetic behind it.

What actually differs between the two, and what does not

Start with what does not change, because it is most of the machinery. Both cadences use the same rate limits, the same authentication requirements, the same quiet hours, the same reply detection, the same suppression list. Nobody gets a deliverability exemption for selling upmarket.

Three things genuinely differ:

• The number of people who must form a view. One in SMB. Several in enterprise. This is the root difference and everything else follows from it.
• What the prospect is deciding. In SMB the question is usually "is this worth trying?" In enterprise it is "is this worth putting my name on internally?" Those need different evidence.
• Who the cadence is competing against for attention. In SMB, the competitor is the prospect's own to-do list. In enterprise, it is an internal process that already has a queue.

What does not differ, despite being the most common thing people change: the quality bar on any individual message. A vague enterprise email is not "appropriately senior". It is vague.

The arithmetic of multi-threading a buying committee

Multi-threading is usually justified by anecdote. It has a clean probabilistic argument that is more useful.

Suppose your per-contact probability of getting a reply from a cold cadence is p. Contact one person at an account and your probability of having any live contact at that account is p. Contact n people independently and it becomes 1 minus (1 − p) to the power n.

Work it through at p equal to 0.05, which is a plausible order of magnitude for a cold B2B cadence and is used here purely as an illustration rather than as a measured benchmark:

• One contact: 5.0% chance of a live conversation at that account.
• Two contacts: 9.8%.
• Three contacts: 14.3%.
• Four contacts: 18.5%.
• Five contacts: 22.6%.

Two things jump out. The first is that the second contact is worth nearly as much as the first — it very nearly doubles account-level reach. The second is that returns fall off fast: the fifth contact adds 4.1 percentage points where the second added 4.8, and the marginal contact keeps getting worse while the cost stays flat.

That is the honest case for multi-threading and also the honest case against overdoing it. The independence assumption is doing work here and it is not perfectly true — colleagues talk, and a poor first message can lower the odds for the second — which pushes the real curve slightly below these numbers rather than above them.

Set against that, Gartner's published research on the B2B buying journey describes buying groups ranging from five to sixteen people across as many as four functions, based on a survey it ran in August and September 2024. So the coverage target is not one and not everyone. It is enough people to represent the functions that will have an opinion, which in practice is three to five.

Why five contacts at one company is not five times one contact

Here is the part the probability model hides. Five enrolments at one company are not five independent sends. They are five sends to one receiving gateway, from the same domain, inside the same window.

That gateway aggregates by sender domain. Five messages to five people at the same organisation on the same morning is a burst pattern, and burst patterns to a single recipient organisation are exactly what filtering is built to catch. Google's bulk sender requirements, in force since 1 February 2024, define the bar in terms of spam rates reported in Postmaster Tools staying below 0.3%, and complaints from one annoyed organisation with five inboxes concentrate faster than complaints spread across five organisations.

Three practical rules follow:

1. Stagger contacts within an account. Do not enrol all five on the same day. Two days apart is enough to break the burst pattern and it also lets the first reply inform the rest.
2. Vary the message per role, genuinely. The same email with a swapped job title is worse than useless when two recipients forward it to each other. This is one of the few places where personalisation is not a nicety.
3. Cap contacts per account explicitly. Pick the number, write it down, and enforce it at list-build time rather than hoping the cadence sorts it out.

The concentration problem is why building a targeted lead list matters more for enterprise than for SMB. A hundred accounts at four contacts is four hundred leads, and four hundred leads with heavy per-account concentration is a harder deliverability profile than four hundred leads across four hundred companies.

The SMB cadence: throughput is the binding constraint

For SMB, the question is how many accounts a rep can work per week without the quality falling apart, and the answer is set by capacity arithmetic rather than by ambition.

The shape that works:

• Short span, front-loaded. Two to three weeks. An SMB buyer who is interested acts inside that window; one who is not is not going to become interested in week six.
• Two channels, not five. Email as the throughput channel, one other as the differentiator. Each additional channel costs registration, monitoring and rate-limit management that a throughput motion cannot absorb.
• Automated schedule, human qualification. The sending is mechanical. The decision about whether an account is worth working is not, and automating it is how a list of bad-fit accounts quietly burns your complaint budget.
• One contact per account, expanded on signal. If the owner replies, you are done multi-threading; there is nobody else.
• A hard exit. A breakup message and out. Recycling into a nurture track is a different motion with a different consent basis.

The metric that matters here is accounts worked per rep per week, and the thing that destroys it is manual research per account. Anything you do by hand at step one gets multiplied by your list size.

Autocloz's free plan covers 5 users and 10 mailboxes with the warmup and DMARC monitoring included, which is enough capacity to run an SMB motion properly before you pay for anything — start free and measure your real throughput before designing around a guess.

The enterprise cadence: coverage and order are the binding constraints

For enterprise, throughput is not the problem. You are working fifty accounts, not five thousand. The problem is that four people at each account need to hear from you in a sequence that makes internal sense.

The shape that works:

• Longer span, wider gaps. Six to twelve weeks, with the gaps widening as it runs. The internal process you are trying to enter has its own timeline and it is not yours.
• Role-sequenced, not simultaneous. Start with the person closest to the problem, because they can tell you what the problem is actually called inside that company. Use their language with the next person. Contacting the executive first with generic framing wastes your one shot at the person who can most easily ignore you.
• Different evidence per role. The practitioner wants to know it works. The manager wants to know what it displaces. The executive wants to know what it costs and what happens if it fails. Same product, three genuinely different messages.
• A named next step at every touch. Not "let me know if you are interested". A specific twenty-minute conversation with a stated agenda.
• Account-level state, not lead-level state. You need to know that this account has one live conversation and three silent contacts, which is not a view that lead-level status fields give you for free.

Gartner's own figure for how much of the total purchase time buyers spend meeting with potential suppliers is 17%. The other 83% happens without you in the room. An enterprise cadence that assumes the buying process is a conversation with you is designed for a process that is not happening.

The two designs, side by side

• Decision unit. SMB: one person. Enterprise: a group of five to sixteen across up to four functions.
• Span. SMB: two to three weeks. Enterprise: six to twelve weeks.
• Contacts per account. SMB: one, expanded on signal. Enterprise: three to five, staggered.
• Channels. SMB: two. Enterprise: three, with the third reserved for named accounts.
• What varies between touches. SMB: the angle. Enterprise: the recipient's role.
• Primary metric. SMB: accounts worked per rep per week. Enterprise: percentage of target accounts with at least one live contact.
• Automation boundary. SMB: automate through to the reply. Enterprise: automate the schedule, hand-write the first touch to any executive.
• Exit condition. SMB: breakup message, then out. Enterprise: no exit while any contact at the account is still engaged.
• The failure it produces when misapplied. SMB cadence on an enterprise account: you burn your one shot at four people with a message written for a founder. Enterprise cadence on SMB: you spend forty minutes of research on a deal worth a fraction of that.

How to segment the list so the right cadence fires

Segmentation is where this design either works or silently does not, and it is worth being fussy about the mechanics.

Segment on the attribute that changes the buying process. Employee count is a better proxy than revenue, because the thing that lengthens a cycle is the number of people who must agree, and headcount predicts that better than turnover. A hundred-person company with a procurement function behaves like an enterprise account regardless of what it bills.

Store the segment as a field you can filter on, and then check the filter actually returns. This sounds paranoid until it happens. A worked example from Autocloz's own codebase: the leads list accepts a tag filter documented as a case-insensitive match, but the write path stores a tag exactly as typed while the read path lowercases the query before matching. A lead tagged Enterprise is therefore not returned by a filter for Enterprise, because the query is lowercased to enterprise and the stored value still has the capital. Nothing errors. The list simply comes back empty and you conclude you have no enterprise leads. Tag in lower case until that is fixed.

Watch the case sensitivity in template conditionals too. Autocloz's template renderer supports {% if title contains "VP" %} blocks, and the comparison is a plain case-sensitive substring test. contains "VP" matches "VP of Engineering" and does not match "vp of engineering". It also matches "CHRO" if you test for "HR" in upper case, which is a different way to get the wrong branch. Test your conditionals against real rows from your own list rather than against the titles you imagined.

Then route. The ICP generator is a reasonable place to draft the segment boundary if you have not written one down. Lead routing done properly covers the mechanics of getting each segment to the right owner, and segmenting your CRM and lists covers the field design underneath it. For account-level plays specifically, the ABM guide treats the coverage problem in its own right.

The failure modes each design produces

Each design fails in a characteristic way, and the symptom tells you which one is misfiring.

• SMB cadence, enterprise account. Symptom: opens, no replies, and then a polite forward to somebody in procurement who has never heard of you. Cause: the message was written for a decision-maker who does not exist at that account. Fix: re-segment, do not shorten.
• Enterprise cadence, SMB account. Symptom: healthy reply rate, terrible cost per meeting. Cause: research time per account exceeds the deal's contribution. Fix: cut research to a single verifiable fact per lead and raise volume.
• Multi-threading with no coordination. Symptom: two contacts at one company reply within a day, saying they have both received the same email. Cause: identical bodies, simultaneous send. Fix: stagger and differentiate by role.
• Multi-threading with no account view. Symptom: a sequence keeps sending to a contact whose colleague already booked a call. Cause: state is tracked per lead, not per account. Fix: an operator has to intervene; there is no automatic version of this in Autocloz.
• Enterprise cadence that never exits. Symptom: accounts sitting in the cadence for five months with no engagement on any contact. Cause: no exit rule because "enterprise takes time". Fix: an engagement floor at the account level — if nobody at the account has done anything in eight weeks, it exits and returns to a nurture list.

What Autocloz does not do at the account level

Three limits worth knowing before you design around them.

Auto-stop is per enrolment, which means per lead. When a genuine human reply arrives, Autocloz stops that lead's enrolment with the reason recorded as replied; a hard bounce stops it as bounced; an out-of-office deliberately leaves it running because the recipient is temporarily away rather than disengaged. None of that propagates to colleagues at the same company. If you multi-thread, a person has to notice and act.

There is no account-level cadence state. The product does not compute "this account has one live conversation and three silent contacts" and gate the remaining sequences on it. You can approximate it by reporting on the company object, but the sending machinery does not read that.

Account-wide suppression exists, but it is a blunt instrument. Suppression rows can be scoped to a domain, so blocking example.com blocks every address at it, on both the workspace list and the global one. That is the right tool for "this company asked us to stop" and the wrong tool for "one contact replied", because it removes the account from all future campaigns as well.

None of these are exotic gaps — most tools built around a per-lead sequence model have the same shape, and it is worth checking rather than assuming. Where an account-first data model matters more than a sequence-first one, the comparison against Attio sets out the tradeoff, and the deals and CRM surface is where account-level state lives in Autocloz today.