Broadcasts

One email, one segment, one datetime. Under Emails → Broadcasts.

Composing one

New broadcast asks where its email comes from before it makes anything: blank, or starting from one in your library. Either way the broadcast gets its own email, added to your library — a broadcast never shares one. That's what keeps a sent broadcast honest: what it said stays what it said, however you later edit the email you started from. You then write it in the same editor you use everywhere else — on the broadcast's own page, not in a dialog over it.

Everything that turns that email into a send sits in a panel beside it. Broadcast holds the audience and the guards that can hold somebody back, then the schedule and the pace it goes out at, and — once it's going — its progress. Email details holds the email's own title, layout, labels, and where else it's used. Sending yourself a test is on the editor's toolbar rather than in the panel, next to Edit and Preview.

Pick the segment. The recipient count answers as soon as you choose, and excludes anyone who has unsubscribed, because a count including people who can never receive it is a lie told in a number.

While a broadcast is still a draft or scheduled you can start over on its email — same question, same two answers. The email you're replacing isn't deleted; it stays in your library, and this broadcast simply stops pointing at it. Once a broadcast is sending or sent, its email is fixed.

Send yourself a test through the real provider, then send now or schedule.

The audience is decided when it sends, not when you compose it. Somebody who joins the segment overnight gets tomorrow's broadcast; somebody who unsubscribes tonight doesn't. That's the whole reason for pointing a broadcast at a question rather than at a list.

Scheduling

A scheduled broadcast is a row with a time on it, not a background job waiting to fire. It stays visible until it goes, you can reschedule or cancel it any time before then, and nothing is lost if the worker stops. It's checked every minute.

Times are in your timezone — the one on your profile, Eastern Time until you set one — and every time shown in the app carries its abbreviation, so 8:30 AM EDT means exactly that. Unschedule, next to Reschedule, takes a scheduled broadcast back to a draft with its email and audience intact — for when the send needs rethinking, not killing.

How it gets sent

One queued email per person, spread out at the broadcast's sending pace. Guards, send windows and suppression all apply on the way out. You can watch it drain in the queue and cancel it mid-send.

The sending pace

Every broadcast drains at a set number of emails per hour — the account default (5,000/hour, changeable on Settings → Sending) unless the broadcast sets its own pace in the editor. The editor always shows how long the send will take at the current pace and audience: 20,000 people at 5,000/hour is about four hours.

Spreading a big send over hours is deliberate, and it's the kinder shape for your domain reputation: bounces and complaints arrive while the send is still going, each one suppresses that address for the rest of the run, and a send that's going wrong can be canceled with most of it still in the queue.

Tracking is yours, so every broadcast gets a real report: who opened, who clicked, which links, and who unsubscribed because of it.

The lifecycle

• Draft — being composed. Deletable.
• Scheduled — has a time. Reschedulable, cancellable, or unschedulable back to draft.
• Sending — the queue is draining it. Still cancellable.
• Sent — every email has left.
• Canceled — stopped before it finished. Deletable.

"Sent" is decided by the rows, not declared when they're made. A broadcast held behind a send window is still sending, and saying otherwise would be a claim the queue screen could contradict.

Cancelling

Cancel any time before it finishes, including mid-send. Everything still queued is canceled with it. What has already gone has gone — cancelling stops the rest, it can't recall mail that has left.

Guards apply

Broadcast emails go through the same queue as everything else, so guards see them. A guard can be scoped to all broadcasts or to one specific broadcast, alongside the existing label, flow and sequence scopes. The compose page lists the guards that can affect it.

What isn't here

Resend-to-non-openers, recurring broadcasts, per-broadcast A/B tests, and editing a broadcast mid-send are all deliberately out. All the data is local, so they're buildable later.