Email sequence vs drip campaign — what's the difference?

The honest answer is that the send engine is the same. A drip campaign and a sales sequence both take a list of people, put each one on a clock, render a message and hand it to a mailbox. Anyone telling you they are different technologies is describing marketing categories rather than software. What genuinely differs is three decisions you make before the first send: which consent basis you are relying on, what events are allowed to stop the series, and whether the next message is chosen from evidence or is simply the next one on the calendar.

The engine is the same; three decisions are not

It is worth seeing this concretely, because the shared-engine claim sounds like hand-waving until you look at a data model.

In Autocloz a newsletter broadcast is not a separate system. It is a campaign row with campaign_type set to broadcast, carrying exactly one email step whose body is the compiled newsletter HTML, enrolled against the chosen lists. The code comment on that endpoint is explicit that it "deliberately reuses the exact campaign, enroll and worker send path — so suppression, unsubscribe, List-Unsubscribe, quiet-hours, open/click tracking and per-mailbox pacing are all inherited unchanged". The alternative value for that column is sequence, described in the model as "the classic drip cadence".

So the product's own vocabulary treats the drip as the general case and the broadcast as the degenerate one-step version of it. That is the correct mental model, and it means the interesting questions are never "which engine" but "which settings, and why".

Three decisions carry all the weight. Take them in order.

Decision one: which consent basis are you relying on

This decides more than anything else in the design, and it is the question most often skipped.

A drip campaign is normally built on a list that opted in. Someone subscribed, downloaded, or bought, and the series is the fulfilment of an expectation they created. A cold sales sequence has no such event behind it. You chose the recipient.

That difference has legal weight and it is jurisdiction-specific. In the United States the FTC's CAN-SPAM Act compliance guide covers "all commercial messages", defined as any email whose primary purpose is "the commercial advertisement or promotion of a commercial product or service", and states that "the law makes no exception for business-to-business email". CAN-SPAM does not require prior consent for either shape — but it does require accurate headers, a non-deceptive subject line, identification as an advertisement, a valid physical postal address, and an opt-out honoured within 10 business days, with the mechanism able to process requests for at least 30 days after the message went out.

In the United Kingdom, the Information Commissioner's Office's business-to-business guidance says the electronic-mail consent rule in PECR "doesn't apply to corporate subscribers", while "sole traders and other types of partnerships are classed as 'individual subscribers' and PECR treats them the same as individuals". Both shapes still fall under UK GDPR, which means a lawful basis, a privacy notice, and an honoured right to object. The ICO notes that guidance is under review because of the Data (Use and Access) Act, so check it at source rather than trusting a summary.

The practical decision rule: if you cannot name the event that created the expectation, you are running a cold sequence and should design it as one — smaller volume, stricter targeting, an easier exit. If you can name it, a drip is defensible and you can be more generous with message count.

Decision two: what is allowed to stop it

A drip runs to the end by design. That is not a flaw; a five-day onboarding course that stops when someone replies "thanks" has failed at its job. A cold sequence that keeps sending after someone answered is a different matter entirely, and it is the single most damaging thing an outbound programme does to itself.

Getting stop logic right is harder than it looks, because "replied" is not one event.

Autocloz classifies each inbound message and then splits three ways. A human reply stops the enrolment with stop_reason set to replied, on the reasoning that a person should now take over. A hard bounce stops it with stop_reason set to bounced, and the bounced address is added to the suppression list. An out-of-office or auto-reply deliberately does neither — the enrolment stays active and the next step fires on schedule, because the recipient is temporarily unavailable rather than disengaged.

That third branch is the one worth arguing about, and it is the one most tools get wrong in the other direction. Stopping on an out-of-office loses a live prospect for the sake of a message they never read. Not stopping means a small number of unusual auto-replies keep a sequence running when it should have stopped. Autocloz takes the first risk deliberately; know which risk your own tool takes, because you inherit it.

A separate stop worth building deliberately: a per-recipient cap that halts the enrolment after a fixed number of consecutive dispatch failures, so a structurally broken step — an empty SMS body, an invalid number, a dead profile — cannot re-defer every ten minutes forever. Sales automation, what to automate and what not to covers where those caps belong.

Decision three: is the next message chosen or scheduled

A drip's next message is determined by the calendar. A sequence's next message can be determined by evidence. Whether that is worth the complexity depends entirely on whether the evidence is any good.

Autocloz's branch step evaluates one of nine conditions and resolves to a jump, a clean stop, or a fall-through to the next step in order:

• if_replied and if_not_replied — checks for a reply inside an optional lookback window measured in hours, defaulting to the whole enrolment lifetime when unset.
• if_connection_accepted — a LinkedIn touch with outcome accepted inside the window.
• if_viewed_message — a LinkedIn touch with outcome read.
• if_email_available — re-reads the lead's primary email, which is how a preceding email-finding step feeds the branch.
• if_open_profile — an open-profile flag stamped by the LinkedIn provider.
• if_opened, if_clicked, if_bounced — email events of the matching type.

A condition the engine does not recognise logs a diagnostic and falls through rather than crashing the campaign, which is the right default: a malformed branch should cost you one decision, not a whole cadence.

Now the caveat that decides whether you use any of this. Two of those signals are weak. Open tracking has been unreliable since Apple's Mail Privacy Protection began pre-fetching remote images, and click tracking is distorted by security scanners that fetch every link in a message before delivery. Branching on if_opened in 2026 means branching on a signal that fires for people who never read the message and misses people who did. Email open tracking, explained honestly covers exactly how much of the signal survives.

The strong signals are the ones tied to a deliberate act: a reply, a connection accepted, an email address discovered. Build branches on those and skip the rest. A three-branch sequence built on reliable evidence beats a nine-branch one built on noise, and it is easier to debug when it misbehaves.

The unsubscribe mechanics differ, and the difference is legal before it is technical

Both shapes need an exit. They need different exits, and the requirement has a version number.

RFC 8058 defines one-click unsubscribe: an HTTPS List-Unsubscribe URL paired with a List-Unsubscribe-Post: List-Unsubscribe=One-Click header, which lets a mail client fire a single HTTP POST to remove the recipient without a browser or a confirmation page. Google's sender guidelines require senders of more than 5,000 messages a day to personal Gmail accounts to support one-click unsubscribe on marketing and subscribed messages, and to include a clearly visible unsubscribe link in the body as well. Google also asks those senders to keep the spam rate reported in Postmaster Tools below 0.30%, and recommends staying under 0.10%.

A high-volume drip to an opted-in list is exactly the shape those requirements were written for. A low-volume cold sequence may sit below the bulk-sender threshold, which changes what is required but not what is wise — a visible one-line exit costs you nothing and prevents the complaint that costs you a domain.

One honest implementation note, because it affects which provider you choose. In Autocloz the SMTP send path sets both List-Unsubscribe and List-Unsubscribe-Post headers. Three API-based providers do not: the Zoho, ZeptoMail and SendCoreX integrations each carry an explicit code note that the RFC 8058 header is absent on their path. The visible in-body unsubscribe footer is rendered independently of the header and still appears. If you are sending bulk volume to Gmail through one of those three, that gap is yours to weigh — the Amazon SES integration and the standard SMTP and IMAP path both emit the headers.

Autocloz's free plan covers 5 users and 10 mailboxes, with warmup and SPF, DKIM and DMARC monitoring built in — start free and check the headers on a real send to yourself before you scale either shape.

A worked comparison on the same thousand contacts

Illustrative arithmetic, chosen to show the shape rather than measured from any customer.

As a drip. One thousand opted-in contacts, five messages over three weeks, no stop logic beyond unsubscribes. Roughly 4,900 messages get delivered after unsubscribes and bounces attrit the list. At a complaint rate of 0.05% — plausible for a genuinely opted-in list — that is about two and a half complaints. Everyone receives the curriculum, which was the point.

As a sequence. The same thousand contacts, cold, five touches, stopping on human reply. Say 2% reply on touch one, 1% on touch two, then 0.5%, 0.3%, 0.2%. Replies remove people from the remaining sends, so total delivered volume lands nearer 4,600 than 5,000. At a cold-list complaint rate of 0.1% that is about four and a half complaints for 40 replies.

The instructive number is neither total. It is complaints per reply. The drip produced roughly two and a half complaints for a curriculum delivered; the sequence produced about one complaint per nine replies. Those are not comparable outcomes, which is the point — comparing a drip and a sequence on the same metric is a category error, and the right question is whether each shape is spending its own complaint budget well.

The failure modes unique to each shape

A drip fails by outliving its relevance. Someone subscribed fourteen months ago and is still receiving message four of a series about a product that has since changed. Diagnosis: sort your active enrolments by enrolment date and look at the tail. Anything older than the content's shelf life is doing damage quietly.

A drip also fails by colliding with itself. Two overlapping lists, one person on both, two messages the same morning. Diagnosis: count distinct recipients receiving more than one message in a 24-hour window. If nothing in your stack computes that, it is happening and you cannot see it.

A sequence fails by stalling silently. It is running, the dashboard says active, and nothing sends. The cause is nearly always a gate — outside the sending window, no active mailbox, an hourly cap. Autocloz stamps a last_skip_reason and last_skip_at on every deferred enrolment for this reason, so the step reads "Waiting: outside sending window" rather than a mute "in progress".

A sequence also fails by branching on noise. A branch on if_opened sends the wrong follow-up to a large share of recipients, and because both paths look plausible nobody notices. Diagnosis: compare reply rate by branch taken. If the branches perform identically, the branch is not carrying information and should be removed.

What Autocloz does not do here

There is no visual drip canvas of the kind a marketing automation platform ships. Sequences are built as an ordered list of steps with branch nodes, and the branch palette is the nine conditions listed above — not an open expression language.

There is no cross-campaign frequency cap. Enrolments are unique per campaign and lead, so the same person cannot be enrolled twice in one campaign, but nothing prevents one contact sitting in two campaigns at once and receiving both. If you run overlapping programmes, that constraint is yours to enforce through list hygiene.

Step timing is not evaluated in the recipient's timezone by default. A campaign carries a sending window with its own timezone — the default being UTC, Monday to Friday, 09:00 to 17:00 — and quiet hours resolve campaign override first, then the workspace default, then UTC. There is an opt-in send-time optimisation that consults a recipient's own open history, and it is off unless you turn it on. Assuming per-recipient local timing without enabling it is a common and quiet mistake, and what a send time can and cannot change is worth reading before you spend effort on it.

And the product will not tell you which shape your programme should be. It renders both faithfully. The judgement about whether you have earned a curriculum or are still asking for attention is yours, and it is worth revisiting whenever the list source changes. If you want to see the step shape before committing, the free cold email sequence builder drafts one, and the multichannel sequence surface is where the same steps gain calls, LinkedIn actions and messaging channels alongside email.