Email course or drip campaign: same mechanism, different promise

Both of them run on the same four parts

Strip either one down and the same four parts are left: messages written in advance, a rule deciding when each goes out, a queue holding what is due, and a suppression list that stops anyone who left from receiving more. A drip runs on that. So does a course. The names move around depending on which tool taught somebody the vocabulary — drip campaign, autoresponder, email sequence, automation, workflow — and every one of them describes those same four parts.

Which is why “can it send a sequence on a schedule” separates almost no two tools, and why a feature grid built around it tells a buyer nothing. The questions that separate them are narrower, and not one of them appears on a pricing page: what the scheduler counts its delays from, what happens to somebody halfway through when day four is edited, whether an unsubscribe stops every sequence or only the one the link came from, and what the builder does when the same person enters the same workflow twice.

One is keyed to behaviour, the other to a date

A drip campaign is open-ended by design. It is keyed to behaviour — a file downloaded, a cart left full, thirty days of silence — and exists to move somebody toward an outcome the sender wants. There is no natural last message, only the point at which the reader converts, leaves, or is moved into another sequence. Success is conversion, and that is the right measure, because a drip exists to change what somebody does rather than to be finished.

An email course is finite and keyed to a date rather than an action: the day somebody confirmed. Day one, day two, day five, done. Success is somebody reaching the end, which is a much harder number to flatter. A course opened by everyone on day one and almost nobody on day five has failed at the thing it is for, whatever the conversion column says.

The sharper difference is who owns the ending. A drip stops by attrition, at a moment the sender neither chooses nor sees, so its length is never stated — the sender does not know it either. A course states its length before anybody joins and is then held to it, which also settles what may be added later: five days extended to eight is not an improvement but a change to a deal somebody already accepted. Neither promise is better, and the choice is rarely made on the merits. It is made by whichever tool was already being paid for, which is where the trouble starts.

What breaks when a course runs in a drip builder

A five-day course will run in almost any automation builder, and abandoning a tool that already holds the list is rarely worth it. The failures are not dramatic, which is the problem: they are small, they are silent, and the only place they surface is somebody else's inbox. Six of them account for most of the damage, and every one is a default rather than a bug.

The first is the clock. A drip builder usually schedules in relative time — wait one day, wait three days — counted from whenever the previous step actually went out rather than against a local morning. So lesson three arrives at whatever hour lesson two happened to leave, a queue that ran late once drags every later day behind it, and three steps of “wait 24 hours” after a confirmation at twenty to midnight put the rest of the week near midnight. A course wants a calendar day and a fixed send hour, so the question worth asking is what the delay is counted from and whose clock it is read in.

The second is the start. A course should begin the moment somebody confirms, because that is the one moment the reader is demonstrably paying attention, and a builder that enrols on a nightly sync spends it for nothing. Some also treat the confirmation as the trigger for a separate welcome sequence, so a welcome and a lesson one arrive within a minute of each other and the reader cannot tell which of them is the course.

The third actually duplicates mail, and it is the least expected. A drip trigger is built to fire more than once, because behaviour repeats: the same person can abandon a second cart. A course trigger fires once per person, and there is no such thing as joining twice. Where the builder permits re-entry into a workflow, a second form submission from an address already on the list starts a second copy of the course beside the first, and the reader gets two day threes a few days apart. That behaviour is usually one checkbox, usually on by default, and nothing reports that it happened.

The fourth is the goal, and it is the one nobody thinks to look for. Automation builders let a sequence end early when the reader does the thing it was built to cause — buys, books, replies, clicks the link — which on a drip is exactly right, since there is no reason to keep chasing somebody who has already converted. On a course the same setting truncates the offer. A reader who buys on day two stops receiving days three, four and five, which are the days they actually agreed to, so the person who said yes ends up with less than the stranger who did not. Goal exits are usually inherited from a template, and on a course they are worth deleting by hand.

The fifth is scope. An unsubscribe in many builders belongs to a list or a workflow rather than to a person, so leaving the course leaves everything else running — which is how somebody who unsubscribed on Tuesday gets mail on Wednesday and reaches for the spam button rather than the link, since the link visibly did not work the first time.

The sixth is what an edit does to the people already inside. Some tools push a change to everybody, including the reader who received the old day four this morning. Some hold each person to the version of the sequence they entered on, so a correction reaches nobody who is already running and only helps whoever joins next. Neither behaviour is wrong and both are surprising, and which one you have decides whether fixing a broken link on day three is a two-minute job or a decision about who gets which version.

None of that argues for buying something else. It is a list of things to do with an address you control before a stranger's: join on a Friday evening from a phone set to another timezone, submit the same form twice, buy something on day two, unsubscribe from one thing and watch what still arrives, and edit day four while somebody is sitting on day two.

What the scheduler will not do, which nobody advertises

The clock cuts the other way too. A calendar day with a fixed hour is right for a five-day course and wrong for a good deal of what sits next to one. A weekday sequence that skips the weekend, a deliberate three-day gap before the last lesson so it lands after the reader has done the work, a pause over a public holiday, a thirty-day challenge: all ordinary requests, and none of them is one lesson a day for five days.

A tool that treats one-a-day as the correct answer rather than as one answer is grading every sequence against a single design, and the ceilings are written into the software rather than onto the pricing page. They surface on the afternoon somebody sits down to build the second course, which is late to discover them.

What to ask a scheduler before the second course exists:

• Whether a step can wait longer than a day, and how much longer. A gap before a final lesson is a common shape and not every builder will hold one.
• Whether weekends can be skipped as a setting, rather than by hand-editing the delay on every step that happens to follow one.
• Whether a single step can be pinned to a fixed date for everybody — a live session, a cohort deadline — while the rest stay relative to each reader.
• Whether there is a maximum number of steps or days at all, which is the limit that ends a thirty-day challenge before it is written.
• Whether the whole sequence can be paused and resumed for everyone mid-flight, and what that does to a reader who was sitting on day two when it stopped.

Where branching earns its complexity, and where it does not

Some jobs are genuinely behavioural, and for those, behaviour is the right key. When the next message depends on what a person did inside a product — started a trial and never invited a colleague, configured half a thing and stopped — the sequence has to read that state, and a date-keyed course cannot. Treating every branching feature as machinery nobody needs is as expensive a mistake as buying all of it.

What it costs is that nobody can read the sequence end to end. Branches multiply faster than anyone checks them, so the failure is rarely a bad email; it is a combination — two branches firing in the same week and contradicting each other, or a condition that quietly stopped being true after a change somewhere else. A course fails in public on day three, where it is obvious within a morning. A branching sequence fails for one person in one state, which is how it runs wrong for a year. The second cost lands on whoever inherits it: a workflow with fifteen conditions is documentation nobody wrote, and the person who built it is the only one who knows why a given branch is there.

The course side pays for that legibility in the obvious currency. Everyone gets the same day three, so a reader who has already done what day three asks still receives it, and there is no condition to check that would spare them. What the money buys instead is a sequence one person can read end to end in a sitting, on a phone, before it goes to anybody — which stops being possible the moment it branches, and is most of the reason a plain course goes wrong less often than a clever one.

Where the branching is doing real work rather than being sold:

• Product onboarding that stops once the account is set up, instead of nagging somebody about a step they finished on the first afternoon.
• Sales cycles measured in months, where the next message depends on what the last one did and no fixed length would be honest.
• Anything keyed to a date the reader owns rather than the day they joined — a trial expiry, a renewal, a booking — where the schedule is per person and unknowable when the sequence is written.
• Re-engagement, which is behavioural by definition, because its trigger is an absence.

Name the trigger, then write the last message

Name the trigger, and ask whether it can happen twice. A course has exactly one: somebody confirmed. It fires once per person and the calendar does the rest. A drip is keyed to something that may happen, may happen repeatedly, or may never happen at all — a cart filled and left, a trial that stalled, thirty days of silence — and a sequence keyed to a maybe has to be able to read state, which is the argument for branching in one sentence.

The second test is the last message rather than the first. If it comes out and reads as a conclusion, it is a course, and the tooling mostly needs to be good at scheduling, consent and delivery rather than at logic. If it will not come, either the subject has no end — in which case it is a newsletter, and the companion guide on courses against newsletters settles that one — or the ending depends on something the reader does, in which case it is a drip and branching will be needed after all.

One signal beats both tests when they are close. If the wish arrives for a rule about people who did not open day two, stop and ask what that rule would send them. Usually the answer is the same email again, which is resending rather than automation, and it is the moment somebody buys a branching tool to fix a copywriting problem.

What a demo cannot settle, and what an afternoon can

Whether a queue can send the same lesson twice is not observable from a demo: every vendor answers no, and the failure surfaces once a year in one person's inbox. Ask what happens when a provider accepts a message and then times out before replying, and listen for two things in the answer — a key identical on every retry, and what that retry does when it arrives after the provider has forgotten the key, because the window is about a day and an outage is sometimes longer. The companion guide on choosing sending software follows that question to the end of it.

The duplicate a reader is far likelier to meet is the one a trial account settles in a minute, and it belongs to this shape of tool rather than to anybody's schema. Submit the form twice from an address already on the list, and see whether a second copy of day one turns up a few days later. That is the re-entry setting doing exactly what it was designed to do.

Two more questions belong to other pages in this set and are worth asking in the same conversation. Ask whether the bill counts contacts that are stored or only contacts that were mailed in the month, because a course keeps accumulating people who finished it in March — a companion guide on what a course costs does that arithmetic. And ask which routes onto the list can skip confirmation, since a builder that enforces it on its own form will often take an unconfirmed address through an import, an API call or an integration with a shop.