Broadcasts
Send one message through your project's bot to a chosen audience segment, follow it on the Broadcasts page as it sends, retry the members it missed, and resend it.
By the end of this page you'll know exactly who each audience segment contains, why the recipient count is the number to trust, how to reach the holders of one dated access window without touching anyone else, and where every broadcast you sent is kept with who it reached and who it could not.
A broadcast is one message sent from your project's bot to a segment of your members. It is queued and delivered in the background, paced to stay inside the platform's rate limits.
Opening the composer. From All Projects, open the row menu on the project you want and choose Broadcast Message, or press New Broadcast on the project's Broadcasts page.
Only people who have used your bot can receive one
A broadcast is delivered as a message from your bot, so it reaches a member only if they have a chat with this project's currently connected bot.
That is narrower than your member list, and deliberately so. Someone who bought through your portal page and never opened the bot has no chat to deliver to. If you reconnect the project to a different bot, chats belonging to the old one no longer count.
This is not applied at send time as a silent filter — it is part of the definition of every segment below, so an unreachable member is neither counted nor attempted.
The recipient count is the same query as the send
Under the audience picker, one line reports what the broadcast will do:
37 recipients
Reachable on this bot · about 2 sec to send
That number is not an estimate of the segment. It is the result of the exact query the worker will run, so the people counted and the people messaged are the same set by construction. When it says No recipients, the Send button is disabled — there is nothing to send.
The figure recalculates whenever you change the audience or the access window, and shows a placeholder while it does. Sending is refused if the count has fallen to zero in the meantime.
Audience segments
Member segments
These filter on a member's status, which is a fact about the person rather than about anything they bought.
| Segment | Who it contains |
|---|---|
| All Users | Every member reachable on this bot, whatever their status. |
| Customers Only | Members whose status is Customer. |
| Trialing Users | Members currently on a trial. |
| Leads | Members who have interacted but never subscribed. |
| Churned Users | Members who were customers and are not any more. |
See Managing members for exactly what moves a member between those statuses.
Subscription segments
A status describes the person. These five describe the subscription, which is what a status cannot do: someone who cancelled but still has three weeks left carries the status Customer, the same as someone renewing happily, and until these existed the two could only be messaged together.
| Segment | Who it contains |
|---|---|
| Expiring Soon | Members whose access runs out inside the horizon you choose. |
| Cancelled, Still Inside Their Period | Members who turned renewal off but have not run out yet. |
| Paused Subscriptions | Members who paused their subscription rather than ending it. |
| Trialing Without a Card | Members on a trial with no card on file, who will not convert on their own. |
| Waiting on a Connection | Members whose purchase includes a place on a platform they have not connected yet. |
An auto-renewing member is never Expiring Soon
This is the one thing to understand before writing a renewal nudge, because the obvious reading is wrong.
A subscription's end date is rewritten to the new period end every time it renews. So "ends within 7 days" describes an auto-renewing member's next invoice, not the end of their access — and counting it that way would sweep every monthly subscriber into this segment once a month, every month.
A member is counted only when their access genuinely lapses, which means one of two things: they turned renewal off, or the plan does not renew at all (a one-off or a pass). Everyone else is renewing, and nothing is expiring.
Expiring Soon asks for a horizon — 7, 14 or 30 days — and the recipient count updates as you change it.
Cancelled, Still Inside Their Period deliberately has no horizon. The whole value of that audience is reaching somebody while they still have something to lose, and three weeks out is a better moment to ask why than three days out.
Narrowing any segment to one plan
Under the segment picker is an optional Narrow to a Plan control. It does not replace the segment you chose — it composes with it:
| Segment + plan | Who that reaches |
|---|---|
| Customers Only + Gold | People paying for Gold right now. |
| Churned Users + Gold | People who held Gold and left. |
| Paused Subscriptions + Gold | People whose paused subscription is the Gold one. |
| Expiring Soon + Gold | Gold members whose access lapses inside the horizon. |
The plan and the state always describe the same subscription. Someone paying for Silver who tried Gold last year is not a Gold customer, and a Gold-only announcement will not reach them. Churned Users is the deliberate exception in the other direction: the subscription that proves they held the plan is precisely the one that ended, so it is not required to be live.
Leave it on Any plan to address the whole segment.
Retired plans stay in the list on purpose
A plan you have deactivated still appears, marked Retired. The audiences most worth a plan filter are the ones who have already left, and a churned cohort very often churned from a plan you have since withdrawn — hiding it would make exactly the people the filter exists for unreachable.
The control is hidden for Leads, who by definition never subscribed, and for the pass segments, whose plan is already implied by the window you pick. Changing the segment to one of those clears any plan you had chosen, so a filter can never keep narrowing a send from a control that is no longer on screen.
Pass segments
These filter on a pass — a subscription bound to a dated access window — rather than on the member. They need Time-Limited Passes, which is on the Growth plan or available as the Passes Addon on any plan, and each is marked with a purple Passes Addon badge in the picker.
| Segment | Window | Who it contains |
|---|---|---|
| All Active Pass Holders | Every upcoming | Everyone holding a valid pass for any window that has not finished. |
| All Active Pass Holders Not in Queue | Every upcoming | The same people, narrowed to those who have not tapped their invite link. |
| Active Pass Holders | One you choose | Everyone holding a valid pass for that single window. |
| Active Pass Holders Not in Queue | One you choose | Holders of that single window who have not tapped their invite link. |
Every-window and single-window are different sends
The two are not the same message reaching a wider group. A weekly slate has a Saturday and a Sunday window; All Active Pass Holders reaches both sets at once, while Active Pass Holders reaches exactly the date you pick. Picking the wrong one sends a "doors open in an hour" message to people holding next week's ticket.
What "active" means
A holder counts as active while their pass can still deliver access — their payment is settled or trialing, they have not cancelled, and their window has not finished. When a window closes, its holders are marked Never Joined or Access Ended, so they leave every pass segment automatically. You never have to prune a past date out of the audience yourself.
An ordinary recurring subscriber is not a pass holder and is never swept into these segments, even on a project that sells both.
What "not in queue" means
Tapping the invite link before a window opens puts a holder in the channel's queue, and the window opener admits whatever is waiting there. A holder who never taps is not locked out — links are reissued when the window opens — but they have to be at their phone to use them.
Not in Queue is therefore the segment of people with something left to do, and it is the one worth a "your link is still waiting" message. It excludes anyone already queued or already admitted, because for them there is nothing to act on.
For nudging those same people about their invite link specifically — with the link attached — use Send Reminders on the window instead. See Nudging them yourself. A broadcast is for anything else you want to say to them.
Choosing an access window
Picking either single-window segment reveals an Access Window select immediately below the audience.
Windows are listed soonest first
The one starting next carries a green Next Window badge. Each option shows the window's full date range in the plan's own schedule timezone, with the zone named — a pass measured in hours is meaningless as a bare date, and a reader in another country cannot guess the offset.
Each option carries its own holder count
The purple 12 holders badge on an option is the number that option would actually reach, counted with the same query as everything else on this screen. It is specific to the segment you picked, not a generic sold count: a window with 12 holders where 10 have queued shows 12 holders under Active Pass Holders and 2 holders under Active Pass Holders Not in Queue.
Empty windows are not offered
A window with nobody in the chosen segment is left out of the list entirely, so you can never select an option the recipient line then reports as zero. Switching between the two pass segments re-evaluates the list, and moves your selection to the soonest window that still has recipients.
Finished windows are never listed
Only windows that have not ended appear. A finished window's holders are no longer active, so every such option would be empty.
If no upcoming window has anyone in the chosen segment, the picker is replaced by a note saying so, and there is nothing to send.
Why a window can be missing from the list
Manage Access Windows and this picker count different things, and the difference is worth understanding before it looks like a bug.
| Screen | Counts |
|---|---|
| Manage Access Windows | Every subscription ever bound to the window — including cancelled ones, and buyers with no chat. |
| Broadcast picker | Only people this broadcast could actually deliver to. |
So a window reading 1 sold over there can be absent here, and both numbers are correct. Its single holder may have cancelled, may already be in the queue when you picked the not-in-queue segment, or may have bought through your portal page and never opened the bot.
When that happens, a line under the picker says how many upcoming windows were left out and why, rather than letting them disappear silently.
From the bot
The same broadcast exists on the Subscriby bot, offering the same segments and queuing the same job — a menu that named its own list would let you reach a population the dashboard cannot, or miss one it can.
Open your project from the bot and choose Broadcast Message. The bot lists every segment with its own recipient count, then offers the same set as buttons — so the numbers are in front of you before you choose:
- 👥 All Users (312)
- 💳 Customers Only (188)
- ⏳ Trialing Users (14)
- 🔔 Leads (96)
- 🚪 Churned Users (14)
- ⌛ Expiring Soon (9)
- ↩️ Cancelled, Still Inside Their Period (17)
- ⏸ Paused Subscriptions (6)
- 💤 Trialing Without a Card (11)
- 🔗 Waiting on a Connection (3)
- 🎟 All Active Pass Holders (41)
- ⏰ All Active Pass Holders Not in Queue (12)
- 🎫 Active Pass Holders (0)
- 🕒 Active Pass Holders Not in Queue (0)
The bot asks the same questions, one at a time
A chat keyboard cannot show two controls at once, so what the dashboard puts on one screen the bot asks as steps. Only the steps your segment actually needs appear, and each one shows counts before you commit to it:
Access window — single-window pass segments only
Soonest first, each showing the holders it would reach, empty windows left out. The next window to open is marked ⏭.
Running Out Within — Expiring Soon only
Three buttons — ⌛ 7 days, 14 days, 30 days — each carrying the number of members that horizon reaches.
Narrow to a plan — every segment except Leads and the pass segments
👥 Any plan first, then one 🏷 button per plan with its own count. Only plans with somebody in the chosen segment are listed, so every button leads somewhere.
Any plan is a real answer, not a skipped question, so choosing it moves straight on to the message rather than asking again. Going back and re-picking the segment clears every refinement you had made, which is how you back out of a wrong turn.
If you have more plans than one keyboard can hold, the bot lists the largest audiences and says how many it left out — those are reachable from the dashboard.
The preview before you confirm names everything you chose, so a narrowed send is never ambiguous: Expiring Soon — within 30 days on Gold.
The pass segments are hidden, not greyed out
A chat keyboard has no disabled state, so a creator without Time-Limited Passes is not shown those buttons at all — tapping one would only tell them it was unavailable after they had chosen it. On the dashboard, where an option can be shown disabled, they stay visible with the Passes Addon badge.
The preview before sending names the window as well as the segment, because a pass broadcast that does not say which date it is addressed to is indistinguishable from one addressed to every date — and those reach different people.
A window can also stop qualifying while the keyboard sits in your chat: its holders all queue up, it closes, or you cancel it. Tapping it then is refused with a note and the list is re-offered, rather than sending to a window that no longer has anyone in the segment.
Writing the message
The editor supports the formatting your platform's chat accepts: bold, italic, underline, strikethrough, code, and links.
What you type is converted to the connector's message format before sending. Paragraphs become blank lines, line breaks are preserved, and anything the platform does not accept is stripped rather than sent raw — a platform can reject a whole message on unknown markup, so a stray tag would otherwise fail delivery for every recipient at once.
A message that comes out empty after that conversion is refused rather than queued, so an editor you opened and never typed into cannot mail everyone a blank message.
Links are visible and permanent
A broadcast lands in the private chat each member has with your bot. It cannot be recalled once delivered, and there is no per-member opt-out beyond blocking the bot — which also stops every other notification Subscriby sends them. Compose accordingly.
Sending
Press Send Broadcast and the job is queued immediately; the composer closes, a toast confirms how many recipients it went out to, and the broadcast appears as a row on the project's Broadcasts page, where it counts up as it sends.
Delivery is paced at roughly 28 messages a second, which is what the arrival estimate is calculated from. Individual failures do not stop the run:
- A member who has blocked the bot is skipped without retrying — that never recovers.
- A rate limit from the platform is respected, waiting the interval it asks for. On a long wait the job hands the rest of the run to a delayed follow-up that starts from the next member rather than tying up a worker, so nobody receives the message twice.
- Any other refusal is kept on the broadcast's row against that member, with the platform's own words, and the run continues.
Blocking is per member, not per broadcast. If a large share of a send fails, check that the bot is still connected and healthy on the project before assuming the audience was wrong.
Every broadcast is kept on the Broadcasts page
Every broadcast sent from a project is a row on the project's Broadcasts page, in the sidebar after Support Inbox: when it was queued, from where (the dashboard, your bot, the API or the Copilot) and by whom, the audience with its plan, access window or horizon, a status badge with one line under it that says where the send stands, and four figures: Reach (how many members the segment held when the worker started), Delivered, Not Reached and Duration. Tabs narrow the list to the ones still Sending, the Completed and the Failed.
A row moves while its job sends: the line reads Sending, 200 of 300, then Sent to 298 of 300, 2 could not be reached, in 42s. Nothing is polled; the page hears the same events the Copilot and the bell do.
History starts with the release that introduced it. A broadcast sent before it has no row, and the page's empty state says so.
The flyout
View Details on a row opens the broadcast: the message as you wrote it, the figures, who sent it, under Not Reached, By Reason the failures by the connector's reading of why, and under Members Not Reached the first fifty members it could not reach with the platform's own words for each. Nothing is kept per successful recipient.
| Reason | What it means |
|---|---|
| Blocked the bot or left | The member blocked your bot or left the platform; the message can never reach them. |
| No account to reach | The member no longer holds a connected account on this project's connector. |
| Rate limited by the platform | The platform kept refusing after three attempts; a retry usually reaches them. |
| Not permitted by the platform | The platform refused the message for that member. |
| Connector not configured for it | The connector cannot carry this message as it is configured. |
| Temporary platform error | The platform was down or answered with an error; a retry usually reaches them. |
Retry the members it missed
A finished broadcast that could not reach anyone offers Retry Failed in its flyout. The retry is a broadcast of its own, listed under the old one as Retry of an earlier broadcast: it goes to the members the first send missed and nobody else, posts no announcement where a connector keeps a place for one, and counts up like any other send. A broadcast still sending, one that missed nobody, or one whose missed members cannot be reached now is refused with the reason. The same retry is on the API and in the Copilot.
Resend
Resend opens the composer filled with the broadcast's message, audience, plan, window and horizon, for a send to the whole segment again. Nothing goes out until you press Send Broadcast.
You are told once it finishes
When a broadcast finishes, or stops, one notice reaches you in the Notifications bell and in your bot chat: how many got it, how many could not be reached and how long it took, or why it stopped. It is the Broadcasts class under Alert destinations (see Notifications), so you choose where it goes.
What happens if your plan changes after queuing
A queued broadcast carries its audience across time, so entitlement is re-checked when the worker picks it up, not only when you press send.
If the project's owner no longer holds Time-Limited Passes by then — the plan was downgraded, or the Passes Addon was cancelled — a pass broadcast is abandoned rather than sent, and the reason is logged. The gate is real at both ends rather than only in the dashboard.
Entitlement always follows the project owner, never whoever is operating the dashboard. A teammate administering someone else's project is judged on the plan that pays for that project.
Frequently asked
Related
- Time-Limited Passes — access windows, the queue, and the per-window reminder button.
- Managing members — the statuses the member segments filter on.
- Connecting a bot — the bot every broadcast is delivered through.
- Subscription — the Growth Plan and the Passes Addon.
How is this guide?
Last updated on
Pass Roster
A timeline of every member against the dates your pass plans sell: every date drawn to its real length, where each member stands on each date, who was moved from where after a cancellation, the whole trail of a pass, a dialog behind every bar, a calendar feed, a CSV, and the same roster over the API and for agents.
Support Inbox
Members who write to your project bot land in one inbox; answer from the dashboard or straight from the platform's chat.