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.
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.
How it gets sent
This is a choice per broadcast, not a fact about your provider.
From Mimeo
One queued email per person, paced to whatever your provider allows. Guards, send windows and suppression all apply on the way out. You can watch it drain in the queue and cancel it mid-send.
Tracking is yours, so this broadcast gets a real report: who opened, who clicked, which links, and who unsubscribed because of it.
Handed off to your provider
Providers with their own bulk pipeline can take the whole thing at once. Bento receives it as an unapproved draft that you review and send from Bento.
The trade is real. The provider does the sending, so the provider — not Mimeo — sees who opened and clicked. A broadcast sent this way has no report here and never appears in the queue. If you want the numbers, choose "Send from Mimeo".
The lifecycle
- Draft — being composed. Deletable.
- Scheduled — has a time. Cancellable, reschedulable.
- Sending — the queue is draining it. Still cancellable.
- Sent — every email has left.
- Canceled — stopped before it finished.
"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.