WordPress Mass Messaging: Broadcast to All Users from Admin

December 5, 2023 · 7 min read

Creator of Better Messages

Site admins regularly need to reach every member at once — an outage update, a policy change, a new feature announcement, an event reminder, a payment-method update. Email works but lives in a different inbox. WordPress's built-in tooling stops at the "post on the activity feed" model that not everyone reads. Better Messages adds mass messaging: a one-time broadcast from the admin panel that delivers the same message to every selected user as an individual private conversation, so replies route back to the admin rather than to all recipients.

Why "individual conversations" and not a giant group chat#

The mass messaging feature does not create one big thread with everyone in it. Instead, the message is delivered as an individual 1:1 conversation to each recipient. Three reasons this is the right model:

Replies route to the sender, not to all recipients. If you broadcast "We are extending the deadline by a week" to 5,000 users, you do not want every "Thanks!" to be visible to all 5,000. Each user reply lands as a private DM to the admin.
Recipients see the message as a personal touch, not as a group blast. The conversation appears in their inbox like any other DM.
Admins can follow up individually if a specific reply needs a response — the existing 1:1 thread is the natural place to continue.

Behind the scenes, the mass-messaging job creates N independent conversations (one per recipient), each with the admin as the sender. Database-wise this is the same as the admin manually DMing each user, just automated.

What you can target#

Send to offers four targets:

All Users — every registered WordPress user on the site.
Users with Role — one or more WordPress roles (Administrator, Editor, Subscriber, custom roles).
Group — a community-plugin group, grouped by source in the dropdown: BuddyPress / BuddyBoss groups, PeepSo groups, Ultimate Member groups, and FluentCommunity Spaces and Courses.
Specific Users — a curated list you build with a user search. No custom code needed.

On top of the target, an activity filter narrows it further: Any activity, Active in last N days, or Inactive for N days. That is what turns a broadcast into a re-engagement campaign.

Common patterns:

Use case	Recipients
Site-wide announcement	All Users
Paid-member-only update	Users with Role → "Pro Member"
Course-cohort announcement	Group → the FluentCommunity course or BuddyPress group
Staff-only message	Users with Role → Editor + Administrator + Shop Manager
Re-engagement to dormant members	All Users + Inactive for 60 days

How to use#

WP Admin → Better Messages → Administration → Bulk Messaging, then Create New.
Pick a Send As sender — yourself by default, or any other user.
Choose Send to and, if you want it, the activity filter.
Write the Subject and Message (Markdown is supported) and drop in any Attachments.
Set the Options you need — Hide this conversation from your conversation list keeps 5,000 threads out of your own inbox, and Disable replies to this message makes it one-way.
Under Schedule, pick Send immediately or Schedule for later with a date and time.
Set the Send rate if the default does not suit — it is messages per batch, one batch a minute, defaulting to 20.
Preview to see the message as a recipient will, then Start Bulk Messaging.

The job runs on cron in the background. At the default rate that is 20 conversations a minute, so plan the elapsed time from your recipient count — 5,000 people is a little over four hours. Raise the send rate if your host can take it. A running job can be paused, resumed or cancelled from the reports list, and you can send a follow-up to everyone the job already reached.

Combining mass messaging with email + push#

Mass messaging interacts naturally with the rest of Better Messages' notification surfaces:

Each recipient gets a standard in-messenger notification (unread badge, conversations-list update).
Each recipient gets a batched email notification, on the same two settings every message obeys: Notification Interval (how often the digest cron runs, 15 minutes by default) and Offline Delay (how long someone must have been away before an email is worth sending, also 15 minutes by default). Someone who is on the site when the broadcast lands simply reads it and never gets the email.
WebSocket-version recipients get real-time delivery and, if Browser Push Notifications is on, web push when the site tab is closed.

Because the emails ride the interval cron rather than the send action, a large broadcast does not produce a single outbound spike.

When NOT to use mass messaging#

A few cases where another tool fits better:

Frequent recurring updates — a newsletter / email-marketing plugin (FluentCRM, Mailchimp) is the right tool for ongoing weekly updates.
One thread members should discuss together — use a chat room with the relevant role allowed in. Everyone sees everyone else's replies.
Onboarding messages triggered per-user-event — use the AutomatorWP or Uncanny Automator integration to send a DM on user signup / course completion / payment.

Free vs WebSocket version#

Mass messaging works on both versions:

Feature	Free version	WebSocket version
Send to all users or specific roles	yes	yes
Each recipient gets an individual conversation	yes	yes
Replies route to sender only	yes	yes
Background processing for large recipient lists	yes	yes
Real-time delivery of broadcast messages	polling	instant
Web push notifications for new broadcast messages	—	yes
Email notifications via standard batched delivery	yes	yes

Frequently asked questions#

What is the upper limit on recipients?#

There is no hard cap. The background job handles large recipient lists by processing in batches. Tens of thousands of recipients on a healthy site is fine. For sites in the hundreds of thousands, contact support for a tuning conversation.

Will recipients see who else received the broadcast?#

No — each recipient sees an individual 1:1 conversation with the admin. There is no visible "this was sent to N other users" indicator.

Can I personalize the message per recipient?#

Per-recipient personalization (e.g. Hi {first_name}) is not in the default UI but is filterable. For richer personalization, use the AutomatorWP integration with the AutomatorWP token system.

What happens if a recipient already has a thread with me?#

That depends on a site setting, not on the broadcast. Bulk messaging sends through the same path a normal message takes, so Settings → Messaging → Single Conversation Per Recipient decides it: with that on, the broadcast lands in the thread you already share. With it off (the default), it starts a fresh one. Either way nothing is overwritten — existing history is untouched.

Can I schedule a broadcast for a future date?#

Yes. The create form has a Schedule row — Send immediately or Schedule for later with a date and time picker. The job sits in Scheduled status until then.

Will it work with the WebSocket version's real-time delivery?#

Yes — broadcast messages are dispatched through the same event pipeline as regular messages. WebSocket-version recipients see the broadcast land instantly.