Key takeaway
A drip campaign is a set of emails on a clock: one entry event starts it, and the schedule decides everything after. The clock is the liability, because it keeps running while the person on the other end changes. What separates a useful sequence from a nuisance isn't the copy, it's the exits: converted, replied, unsubscribed, bounced. I've never rescued one for weak writing, only for a step still firing after somebody asked it to stop.
A drip campaign is a pre-written sequence on a fixed schedule.
A drip campaign is a set of emails written in advance and sent to one person on a preset interval, started by a single entry event. Somebody subscribes, buys, signs up, or reaches a date, and the sequence begins: email one now, email two in three days, email three the week after. Everyone who enters gets the same messages, with the same gaps between them.
The schedule is what makes it a drip, and the schedule is also the whole liability. A broadcast is a decision you make on the day, with the current situation in front of you. A drip is a decision you made once, months ago, that keeps being made for you at three in the morning, about a person whose situation has changed since. Nothing in the sequence knows that.
I've opened accounts where a sequence built for a launch was still running two years later, still introducing the company to people who had been paying customers for a year. Nobody was hiding it. It needed no one to press send, so nobody thought about it.
That definition covers the shape and nothing else. It says what a drip is, not when a person should stop receiving one, and the stopping is where most of the damage lives.
Drip, triggered flow, and broadcast are three different sends.
What separates the three is what decides the next send, and that decides what happens when the person on the other end changes. The distinction is operational rather than semantic.
- Drip: an entry event starts it, and a clock decides everything after.
- Triggered flow: each step waits on a condition, so behaviour decides what comes next.
- Broadcast: one message, one audience, one moment, chosen by a person who can see today.
The practical difference shows up on the day somebody does something unexpected. A triggered flow can hold a person at a step until they act, and a broadcast never had a next step to get wrong. A drip has already decided what happens on day nine, and it decided it before the person entered.
Most real programmes are a drip with two or three conditions bolted onto it, and calling that a workflow doesn't make it one. The question worth asking about your own is which part a clock is driving. If a step fires on day nine whether or not anything happened on day eight, that step is a drip, and it inherits everything below.
Five sequences worth building before any others.
A sequence is worth automating when one unambiguous entry event starts it. If you can't name the exact thing a person does to enter, it isn't a sequence, it's a set of emails somebody sends when they remember. Five clear that bar for almost every sender.
- Welcome: entry is a confirmed subscribe, and it runs while attention is at its highest.
- Onboarding: entry is account creation, and each email carries one action rather than a tour.
- Abandoned cart: entry is a cart with no order behind it, fired by your store or app, and the size of the problem is documented at 70.22% across 50 studies.
- Education: entry is a download or a demo request, and the interval matches the decision cycle rather than the calendar.
- Renewal or re-engagement: entry is a date or an absence, and this one is the likeliest to be mailing an address that stopped opening a year ago.
What the five have in common is worth more than the list itself. Each has one entry event a system can detect without a human deciding, each has an ending you could describe to somebody who doesn't work here, and each is doing a job that would otherwise be done badly or not at all. A sequence that fails any of those three is usually a broadcast that somebody wanted to feel automated.
Nurture, win-back, and follow-up sequences are programmes in their own right rather than variants of these five, and each needs more room than a line in a list.
Cadence is a decision about the reader, not a template.
Cadence is two things: the interval between steps, and the total length of the sequence. The templates answer both with numbers: five to seven emails over four to six weeks, three days apart, spaced out over a month. None of those numbers has met your buyer.
The interval belongs to the reader's decision cycle. Two days between steps on a cheap impulse purchase and two weeks between steps on a six-month enterprise evaluation are the same decision made correctly twice. A five-email, four-week template is that decision made by somebody who has never met your buyer, and copying it paces your sequence for somebody else's market.
Cadence isn't free either, and the number that decides whether any of it arrives is measured on the receiving side, not by you. For senders of 5,000 or more messages a day to personal Gmail accounts, Google's sender guidelines put the practice at a spam rate below 0.10% and name 0.30% as the rate never to reach. Complaint rate follows frequency as much as content: the same email at half the interval collects more of them.
Those thresholds belong to one provider, and they're a floor for staying deliverable rather than a target to optimise toward. Sitting comfortably under them doesn't mean the cadence is right. It means it isn't yet wrong enough to cost you the inbox.
Every sequence needs an exit, and most are built without one.
An exit is a condition that ends a sequence already in flight, checked between steps rather than at send. Most senders have one, the unsubscribe link in the footer, and a footer link is a preference form rather than something that stops what's already queued.
A drip is the shape where that fails hardest, because steps three through six were queued before anything changed. Four conditions should end one early, and they're worth writing down before the copy. I've never rescued a sequence for weak writing, only for a step that kept firing after somebody asked it to stop.
- Converted: the goal the sequence exists for happened, so every remaining step is addressed to somebody who isn't there.
- Replied: a human is in the conversation, raised by your own mailbox or helpdesk, and the next automated step talks over them.
- Unsubscribed: a hard stop rather than a preference.
- Bounced or complained: a deliverability stop, and it applies to the address rather than to the person.
The unsubscribe stop is a header contract, not a preference: List-Unsubscribe-Post: List-Unsubscribe=One-Click, specified in RFC 8058, which has to work with no confirmation page and no manual step behind it. The deadline that matters is Yahoo's two days, and a sequence is the shape most likely to miss it, because the next three sends were queued before the click arrived.
Honouring the stop is the floor, not the finish. A sequence that checks its exits only as each email goes out has already queued the next three, and the reader gets an answer to a question they stopped asking on Tuesday.
A sequence you can read as text is a sequence you can review.
A drip built in a visual builder exists as boxes on a canvas inside one account. That's easy to draw and easy to show somebody. It's also a shape that nothing else can read.
You can't diff it against the version that ran last quarter. You can't copy it to a second brand without rebuilding it by hand. You can't review nine live sequences without clicking into them one at a time, and you can't ask anything to check whether all nine honour the same exit conditions. Every existing email platform was designed around a human clicking buttons, so a sequence ends up as a picture rather than a definition. An AI feature added to a builder doesn't change that, because the object underneath is still a canvas.
Nitrosend is MCP-first: every capability is an API endpoint and an MCP tool before it's a screen. A sequence is an object an agent can create, read back, change, and check, so "put the same conversion and unsubscribe exits on every live sequence" is one instruction rather than an afternoon. We built it in that order because the review is the part that never gets done.
Readable configuration doesn't write good email. A sequence generated in ten seconds that nobody reads is worse than one drawn slowly by somebody who thought about the person receiving it.
How to build your first sequence.
Five steps, and the order matters. Starting with the audience and finishing with measurement leaves the exits to be discovered in production, usually by the customer who replies to say they already bought. Audience matters, but it's a segment question you'll revisit every quarter, and it isn't what decides whether the sequence is safe to switch on.
- Pick one entry event you can name exactly. If two different events could start it, that's two sequences.
- Write the exit conditions before the emails. Converted, replied, unsubscribed, and bounced or complained.
- Write email one and the last email first. The middle exists to get from one to the other.
- Set the interval from the decision cycle. A two-day gap and a two-week gap are both correct, for different buyers.
- Turn it on for one segment first. Read the spam rate and the unsubscribe rate before you widen it.
Then put a review date on it, in a calendar somebody actually opens. A sequence needs nobody to press send, so without one it outlives the reason it was built, and the first person to notice is a customer. Reviewing it means reading the emails as they stand today, checking the entry event still exists in the product, and confirming the exits still fire.
Write the exits for the sequence you're already running.
Open the sequence that's live today and write down what should end it early: converted, replied, unsubscribed, and bounced or complained. Nitrosend makes a sequence an object you can create, read back, and change from a single agent command, so one instruction carries the same exit rules across every sequence you run, whoever raises the events. Contacts are unlimited on every plan, and the free tier is enough to run one real sequence through it first.
Sources
- Baymard Institute, cart abandonment rate: the 70.22% average documented cart abandonment rate, across 50 studies.
- Google, Email sender guidelines: the spam rate thresholds of 0.10% and 0.30% for senders of 5,000 or more messages a day to personal Gmail accounts, and the one-click unsubscribe requirement.
- RFC 8058, IETF: the one-click unsubscribe header pair, and the requirement that it work without manual intervention.
Common questions
A drip runs on a clock: one entry event starts it, and the interval decides every send after that. A workflow runs on conditions, so a step waits until the contact does something, and somebody who does nothing sits still. The practical test is what happens tomorrow if a contact does nothing at all: a drip sends anyway, and a workflow waits.
There's no correct count, and the published ones are templates rather than findings. Write the first email and the last one, then add a middle step only where the reader needs one to get between them. A sequence ends when its goal is either met or clearly not going to be, so the length follows how long that decision takes.
Space the steps to match the reader's decision cycle rather than a template. A cheap impulse purchase can take a couple of days between steps, and a long enterprise evaluation wants weeks. Frequency drives complaints as much as content does, so widen the interval if the spam rate or the unsubscribe rate moves once the sequence is live.
Yes, when the entry event is real and the exits work. What stopped working is the generic sequence sent on a template schedule to everyone who ever signed up, because mailbox providers now score complaint rates and readers have more mail than they can read. A drip paced to a decision, that stops when it should, still earns its place.
Immediately, and the deadline is a distraction. Yahoo asks bulk senders for two days, but a drip has the next three steps queued before the click arrives, so a queued step that sends afterwards is a complaint waiting to happen. Check suppression immediately before each send, not at enrolment.
Not in the sequence whose goal was the purchase. Every remaining step is addressed to somebody who's no longer there, and it reads as a company that doesn't know its own customers. Move them to whatever comes next, onboarding or a receipt-led sequence, and make conversion an exit condition rather than a step somebody remembers to skip.
Yes. Nitrosend is MCP-first, so the API endpoint and the MCP tool exist before the screen does, and a sequence is addressable from a script or an agent without opening a builder at all. Anything you'd do to it in the interface, you can do to it in a call.
Measure it against the goal the sequence exists for: completed onboarding, recovered carts, or booked calls. Then watch the two numbers that decide whether it keeps arriving at all, the spam complaint rate and the unsubscribe rate, read per step rather than across the sequence. A single step collecting complaints is telling you the interval or the audience is wrong.