What is a sales sequence? (and how it differs from a single email)

A sales sequence is a state machine that runs once per prospect. Each person enrolled gets their own row holding which step they are on, when the next one is due, whether the run is active, paused, completed or stopped, and why the last attempt did not fire. Everything people find useful about sequences comes from that per-person state: one prospect replying stops only their run, one bad phone number stalls only their branch, and the whole thing survives a week in which nobody looked at it. A mail merge has none of that.

A sequence is a state machine per lead, not a list of emails

The mental model most people start with is a schedule: five emails, days 0, 3, 7, 12 and 20. That model is wrong in a way that matters, because it puts the state in the campaign rather than in the person.

Put the state in the person and useful things become expressible. Two prospects enrolled the same morning are on different steps a week later because one replied and one did not. A prospect enrolled today and one enrolled in March are both on step two, at different absolute times. Pausing one person is a row update, not a campaign-level decision. None of that is available if the campaign owns the clock.

In Autocloz the row is called an enrolment, and it is unique on the pair of campaign and lead — a database constraint, not a convention, so the same person cannot be enrolled twice in one campaign by any code path. The row carries the campaign, the lead, an optional pinned mailbox, an optional source list, the status, a stop reason, the current step, the next due timestamp, the last skip reason and time, and two failure counters.

That is the whole object. Understanding those fields is most of understanding what a sequence can and cannot do.

The four states, and what moves between them

An enrolment is in exactly one of four states, enforced by a database check constraint.

• active — the worker will pick this row up when next_due_at has passed. This is the working state.
• paused — deliberately held. The worker skips it. Used when a campaign is paused or an operator intervenes.
• completed — the last step fired and there is nothing after it. A clean end.
• stopped — ended early, with a stop_reason recording why.

The transitions worth knowing are the ones into stopped, because that is where the interesting behaviour lives. A human reply sets stop_reason to replied. A hard bounce sets it to bounced and adds the address to the workspace suppression list. Repeated dispatch failures on the same step — an empty message body, an invalid number, a dead LinkedIn profile — increment a consecutive_failures counter, and the enrolment stops once that counter hits its cap, so a structurally broken step cannot re-defer every ten minutes indefinitely.

One transition that deliberately does not happen: an out-of-office or auto-reply leaves the enrolment active. The recipient is temporarily unavailable, not disengaged, and the next step fires on schedule. That is a judgement call with a real downside — an unusual auto-reply keeps a run going a touch too long — and it is worth knowing your own tool's choice here, because you inherit it either way.

What a step actually is, including the ones that send nothing

A step is a row with an ordinal, a kind, a wait, and kind-specific fields. Autocloz allows eighteen kinds, enforced by a database check constraint rather than by convention, and the useful way to read the list is by what each one does to the timeline.

Channel-bearing steps dispatch one outbound touch: email, call, linkedin_invite, linkedin_dm, linkedin_inmail, sms, whatsapp_template, and call_ivr, which places a carrier call and hands the answer to an IVR tree.

Warming steps produce a notification without a message: linkedin_view and linkedin_like. A profile view or a like earns a notification before a cold invite arrives, and both are subject to the same anti-bot pacing as messaging.

Utility steps change the record rather than the conversation: linkedin_find_email, linkedin_withdraw, linkedin_endorse_skills and linkedin_follow.

Flow-control steps carry no outbound action at all: wait holds for a duration, branch evaluates a condition and jumps or stops, task creates work for a human, and webhook posts to a URL you name.

The flow-control kinds are the ones that turn a schedule into a machine. A task step in particular is underrated: it lets you put a genuinely manual action — write a personal note, check the account's recent news — into the middle of an automated run, with the rest of the sequence waiting on it. Automation that knows where to stop is worth more than automation that does not.

Every channel-bearing step is gated at dispatch rather than at build time. The SMS, WhatsApp and call dispatchers all route sender selection through one shared helper that checks quiet hours and per-account rate limits before returning a sender, and each of those dispatchers checks the do-not-contact list through the same shared function. LinkedIn adds two gates the other channels do not have, covered below. What this is not is a single compliance function every channel calls — the checks are shared helpers invoked per channel, and it is worth verifying which gates your own channel actually runs rather than assuming symmetry.

How the clock is computed, and whose timezone it is not

This is the part most often assumed wrong, and getting it wrong produces sends at three in the morning.

Each step carries wait_seconds. When a step completes, the enrolment's next_due_at moves forward by that duration. So far, so simple. What decides whether a due step actually fires is a stack of gates, evaluated in order.

The campaign sending window. A JSONB object on the campaign holding a timezone, a set of weekdays and a start and end time. The shipped default is UTC, Monday to Friday, 09:00 to 17:00. Outside that window the enrolment defers and records the reason.

Email quiet hours. Resolved in a specific order: the per-campaign channel override first, then the workspace-level channel default, then UTC. The timezone comes from the override, then the workspace timezone, then UTC.

Read both of those again and notice what is absent. Neither consults the recipient's timezone. The window belongs to the campaign, and the quiet hours belong to the campaign or the workspace. There is one opt-in exception: a per-campaign send-time optimisation setting that shifts the send toward the local hour a particular recipient has historically opened email, derived from their own open events. It defaults off, it only defers when the recipient actually has open history, and the window and quiet-hours gates still bound the eventual send.

The practical consequence: if you are sequencing across continents and want local-hour delivery, that is a configuration decision you have to make deliberately, not a default you inherit. And since open events are a weakening signal, treat the optimisation as a nudge rather than a plan — what a send time can and cannot change works through how much of the effect is real.

A worked five-step sequence, with the reason for each step

A cadence is only defensible if every step has a job. Here is a five-step shape with the job named, as an illustrative design rather than a benchmark.

Day 0, email. One specific observation about their business, one sentence on what you do, one low-friction ask. The job is to earn a reply from the small share of people for whom the timing happens to be right.

Day 1, LinkedIn profile view. No message. The job is a notification that makes your name familiar before anything asks for anything.

Day 3, branch on if_replied with a 72-hour window. If they replied, stop. The job is to make sure nothing after this point reaches someone who already answered.

Day 4, call. The job is a channel change. The people who ignore email are not the same people who ignore the phone, and the overlap is smaller than most teams assume — cold email versus cold calling has the argument in full.

Day 8, email with a different angle. Not a nudge. A different reason to care: a customer story from their segment, a specific number, a piece of evidence the first email did not carry.

Day 15, breakup email. The job is to make the exit easy and to collect the "not now, try me in Q3" replies that a silent stop never produces. How to write a breakup email covers why this is often the highest-replying touch in the whole run.

Six steps, six distinct jobs. If you cannot name the job of a step, delete it — that is the single most reliable edit anyone makes to a cadence.

What the worker does on every tick

Knowing the loop makes the failure modes obvious, which is why it is worth two paragraphs.

Autocloz's sender worker runs in-process on a five-second supervisor interval in the shipped single-process deployment. Each tick it selects enrolments that are active and whose next_due_at has passed or is null, using a window function to rank each campaign's most-due enrolment first, then its second, and so on — so a large campaign whose rows are all due-earlier cannot monopolise the tick while another campaign starves behind it. It takes at most twenty rows per tick, then re-selects those ids with FOR UPDATE SKIP LOCKED to claim them, so two worker processes never dispatch the same enrolment.

For each claimed row it resolves the step, runs the compliance gate, picks a mailbox or channel account, renders the message, dispatches, and advances the enrolment. Any gate that says no calls a defer helper which sets next_due_at forward and stamps last_skip_reason and last_skip_at — because a parked step that says nothing is the failure mode this design exists to prevent.

That fair-share ranking is worth internalising. Twenty enrolments per tick is ample throughput at five-second intervals, but it means a single campaign's burst rate is bounded by how many campaigns are competing for the batch, not only by your mailbox caps.

The six ways a sequence stalls, and the field that names which

A campaign showing "running" while nothing sends is the most common support question in outbound, and it has six usual causes. In every case the answer is on the enrolment's skip reason, not the campaign status.

Outside the sending window. The most common by far, and the default window is narrower than people expect — five weekdays, eight hours, UTC.

Email quiet hours. A separate gate from the window, resolved from a different place, so a campaign can be inside its window and still held.

No active mailbox. Every mailbox in the pool is disconnected, over its cap, or failing authentication.

Hourly or daily throttle. The mailbox has spent its allowance. New mailboxes in Autocloz start at 40 sends a day, 10 an hour, with a 90-second minimum gap.

Pre-send verification hold. The address verification probe could not reach a verdict — a timeout, a blocked MX, greylisting — so the enrolment is held and retried, with its own bounded retry counter separate from the dispatch-failure one.

Consecutive dispatch failures. The step is structurally broken and the counter is climbing toward the cap that will stop the run.

The diagnostic order matters. Check the skip reason first, the mailbox health second, and the step configuration third. Working the other way round wastes an afternoon on a template that was fine.

Autocloz's free plan covers 5 users and 10 mailboxes and runs multichannel sequences with the do-not-contact and quiet-hours checks on every dispatch — start free and watch the skip reasons on a small first campaign before you scale it.

What changes when one sequence becomes twenty

At one sequence the design problem is copy. At twenty it is inventory, and three things go wrong in order.

Overlap. The same person sits in two campaigns and receives both. Enrolment uniqueness is per campaign, so nothing stops it. The fix is discipline at the list level, and it needs a real owner — segmenting your CRM and lists covers the shape that survives.

Mailbox contention. Twenty campaigns share one pool of mailboxes, and the daily caps are per mailbox rather than per campaign. Adding a campaign does not add capacity; it divides existing capacity. Domain and mailbox pools on each campaign are how you carve that up deliberately instead of by accident.

Nobody knows what is live. Sequences accumulate. A quarterly audit that stops anything nobody can justify is worth more than any optimisation, because a stale sequence is still spending your complaint budget. Tools priced per seat make that audit harder by making every extra pair of eyes cost money, which is the substance of the Autocloz and Outreach comparison.

What a sales sequence cannot do for you

It cannot decide who to enrol. A sequence executes against a list, and a well-built sequence on a badly-built list performs worse than a mediocre sequence on a good one — building a targeted B2B lead list is the prerequisite, not the follow-up.

It cannot write a message worth answering. Automation multiplies whatever you put into it, including the parts that do not work.

It cannot resolve a deliverability problem. Steps that dispatch successfully to a mailbox that cannot reach an inbox are a full pipeline of nothing.

And in Autocloz specifically: there is no cross-campaign frequency cap, no per-recipient timezone by default, and no automatic reply sending — AI can draft a reply, and a human has to click send. That last one is deliberate, and the reasoning is set out in AI replies that sound like you. If you want to see the step palette before building anything, the multichannel sequence surface shows the kinds, and the analytics module is where per-step stats and skip reasons surface once a campaign is live.