Plan, test and send customer broadcasts with the right audience

A Broadcast sends one prepared email to an eligible group of customer Contacts. Use it for a planned maintenance notice, a product advisory, a useful knowledge update or a customer event invitation. Supportbench can use the Company and Contact roles and tags already maintained by your support team, so communication can follow your customer organization model. The value depends on choosing the correct audience, writing a useful message and checking what happened after publication.

Choose a broadcast for the right job  ·  Prepare ownership, access and customer data  ·  Create a draft and understand the starting defaults  ·  Understand exactly how recipient filters combine  ·  Check the estimate before committing the audience  ·  Write a message a support customer can act on  ·  Preview the message and send a controlled test  ·  Publish an immediate or scheduled broadcast  ·  Interpret states and handle a needed correction  ·  Read recipient results without overstating engagement  ·  Worked example: notify affected customers of maintenance  ·  Troubleshoot common broadcast problems

Choose a broadcast for the right job

Broadcasts are one-time messages. A saved template supplies reusable wording; it does not create a recurring campaign, automatically select recipients or schedule future follow-ups. A Community selection provides portal context, not proof that only customers who use that portal will be included.

Prepare ownership, access and customer data

1. Agree the communication owner, intended audience, purpose and approval process. Write down who should receive the notice and who should not before choosing filters.
2. Confirm your role can view Broadcasts and, for composition or publication, edit them. A visible list does not necessarily grant permission to send. Ask the authorized administrator to resolve a missing control.
3. Check the available active From addresses and the intended Community. Use an identity whose replies your operation can handle. Confirm the sending configuration with its owner when necessary.
4. Check the customer data behind the segment: active Contacts, usable email addresses, relevant Company/Contact roles and tags, and broadcast opt-outs. An inaccurate tag produces an inaccurate audience even when the filter works correctly.
5. Prepare the final message and a reviewed destination for any link. Use a controlled account for experiments that would create customer sends; use Send Test for the email-content check described below.

Broadcast audience selection is not the same as the agent’s ordinary case-list Division filter. Treat the broadcast audience controls as their own consequential scope review. Do not assume a case view, portal selection or your current queue silently restricts the mailing.

Create a draft and understand the starting defaults

1. Open Settings → Broadcasts → Broadcasts and choose New Broadcast.
2. Enter an Internal name that identifies the purpose and date, such as “Maintenance notice — customer integration service — November.” Enter a customer-facing Subject that states the relevant action or impact. Both fields allow up to 100 characters.
3. Review From and Community, even when already selected. The editor can preselect an active sender and a visible Community; a convenient default is not confirmation of your intended audience or identity.
4. Review Timezone. It starts from the available user/account timezone context, falling back to UTC. Read the actual selected value.
5. Leave Send on blank only if the final publication should begin immediate processing. For a scheduled start, choose a future date and time in the selected Timezone. A past time is invalid.
6. Write the required content or start with an appropriate broadcast template. Replace every sample date, instruction, destination and audience reference.
7. Use Save Draft while preparing the message. Reopen it to verify the saved content and settings. Saving a draft does not send the email or commit a delivery schedule.

Understand exactly how recipient filters combine

With All contacts on, Core selects eligible active, non-deleted Contacts with valid email addresses and excludes broadcast opt-outs. Role/tag filters are ignored or cleared. “All contacts” means all eligible contacts, not every stored record and not only the organization currently open in your workspace.

With All contacts off, choose from Company roles, Company tags, Contact roles and Contact tags. Selections within a field are alternatives. The matching sets from the different configured fields are then combined as a union and duplicate Contact identities are removed. Company-based matches also require an active Company.

Broadcast opt-out eligibility is checked when building the audience and again when processing a send. A later opt-out can suppress a previously snapshotted recipient. Removing an unsubscribe record merely to force delivery is not an appropriate audience correction.

Check the estimate before committing the audience

1. Finish the audience choices and choose Refresh Estimate.
2. Read the eligible-recipient count, Monthly remaining, SMTP mode and any preflight message. Compare the size with the intended segment. Investigate an unexpectedly large, zero or changing count before continuing.
3. Check whether the sending configuration has sufficient capacity. Current Core limits are 2,500 shared-SMTP recipients per month and 25,000 recipients for a custom-SMTP broadcast. Use the displayed preflight for the current account and available capacity.
4. If you change filters or customer records, refresh the estimate again. Publication recalculates eligibility and quota, so an earlier estimate is not a reserved audience or guaranteed capacity.

Refresh Estimate is a count/preflight check, not a preview of recipient names. The native Recipients search/export becomes available after publication. If your process requires a named recipient-list review before any irreversible publication, complete that review through the authorized customer-data process first; do not mistake the estimate for that review.

Write a message a support customer can act on

Prefer a direct knowledge link whose audience you have checked. Do not insert private case details, credentials or customer-specific diagnostics into a shared broadcast. Use only variables supported by the broadcast context and verify their output in the test; a placeholder copied from a case template, such as an invented first-name token, is not automatically valid here. See the template-variable reference when personalization is required.

Preview the message and send a controlled test

1. Open Preview and inspect the complete message. Check the subject, dates, timezone wording, headings, links and any template variables.
2. Check that your own agent profile has the intended valid email address, then choose Send Test. The test is sent to the current agent’s profile email; this is not an arbitrary test-audience selector.
3. Read the received test in the relevant email clients or screen sizes. Open each destination using an appropriate customer access context. Check that the message is understandable when remote images are blocked.
4. Correct the draft, save and test again when the correction changes meaningful content or rendering.
5. Have the communication owner review the final message and audience logic before publication. The test checks message output; it does not validate the entire customer recipient list or prove production delivery.

Publish an immediate or scheduled broadcast

1. Reopen the intended draft and verify Internal name, Subject, From, Community, content and audience. Refresh the estimate and resolve preflight failures.
2. Check Send on and Timezone together. Blank Send on begins processing after publication; a future value schedules the start in that timezone.
3. Choose Publish only when the irreversible audience/content decision is ready. Read and confirm the publication warning.
4. Verify the resulting state in the Broadcasts list and reopen the record. Publication snapshots the eligible Contact identities and commits the message. Published broadcasts are read-only.
5. Open Recipients to search or export the snapshotted audience. For a scheduled broadcast, adding a tag to a Contact later does not automatically add that person to the already published snapshot.
6. Monitor state and available recipient results around the scheduled start. Keep the communication owner available to handle questions or a necessary follow-up.

Due broadcasts are checked on a roughly two-minute service cadence and processed in recipient batches through the separate email queue. The scheduled time is a processing start, not a guarantee that every inbox receives the message at that exact minute.

Interpret states and handle a needed correction

A future scheduled broadcast can be cancelled only before recipient sending has begun. Cancellation is not a recall. Deleting a record does not recall emails already queued or delivered. If the message has already started, coordinate the corrective communication with the owner instead of repeatedly retrying Publish or assuming deletion reverses it.

Read recipient results without overstating engagement

After publication, use the broadcast’s Recipients and Analytics tabs. Recipient search/export includes the available Name, Email, Opened, Clicked and Unsubscribed information. Analytics shows total Sent, Opened, Clicked and Unsubscribed counts; this screen does not supply a bounce-rate or engagement-score metric.

Open tracking uses a remote image and click tracking uses rewritten links. Image blocking, automatic image loading and security-link checks affect interpretation. The first recorded event does not establish that a human read the entire notice, understood it or completed the requested action. A missing event also does not establish that the email was unread.

For an operational outcome, verify the relevant action: a registration, acknowledged maintenance plan, completed upgrade or resolved support question. Use the email metrics to identify follow-up questions, not to invent that outcome. A weekly account review can record which notice was sent and then check the actual customer commitments in their cases.

Worked example: notify affected customers of maintenance

1. Define the affected service and the exact customer people who need the notice. Verify the maintained segment with its owner. Avoid combining Company and Contact filters when the required intersection would become an unintended union.
2. Create a draft with a specific subject, recognizable From address and correct Community. Write the maintenance window with a timezone, confirmed impact, any preparation and the support route.
3. Turn off All contacts and select the verified segment. Refresh Estimate and investigate any mismatch with the expected size.
4. Preview and Send Test to your profile address. Check the linked maintenance or knowledge page using customer access.
5. Obtain the normal internal communications review. Set the future Send on and Timezone, review the final estimate and Publish.
6. Reopen the published record, inspect its Recipients snapshot and confirm Scheduled. If a material error is found before processing begins, use the available cancellation and duplicate-as-draft correction path.
7. After processing, review Sent and engagement indicators, then verify any required customer action separately. Record questions and commitments in the appropriate customer cases.

Troubleshoot common broadcast problems

Continue learning

• Configure Broadcast settings and sending controls
• Prepare reusable Broadcast templates
• Review customer unsubscribe records
• Use variables only in their supported template context
• Maintain Company and Contact information
• Find and check the knowledge you share