Member Messages and Delivery Tracking

The messaging tools help the team tell the right members something at the right time. They are used for targeted announcements, operational updates, and automatic messages created by other workflows.

The system keeps SMS, push, and email separate because each channel reaches the member differently and has a different delivery process.

Choosing the right channel

The admin broadcast screen sends SMS or push. Transactional email is normally created by a booking, account, or payment workflow rather than by the same composer.

Choosing recipients

The operator can narrow members by their location or region, boat model, booking dates, booking place, and boats used in bookings. The screen then shows a result count and allows all or selected members to be chosen.

Filters exist to avoid sending irrelevant information. For example, a harbor closure should go to members affected by that harbor and period, not necessarily to the entire membership.

Before sending:

1. apply the smallest useful filter;
2. read the visible member count;
3. inspect a sample of the resulting names;
4. choose all results or specific members;
5. re-check the selection after any filter change;
6. review the final text, title, and link.

Sending SMS

The SMS action sends one text to the selected member IDs. The system records successful and failed provider results where supported so staff can follow up.

A successful browser response means the platform accepted the send request. It does not always mean that every phone received the message. Use the sent and failed SMS screens to confirm the result.

Sending push notifications

A push message contains a title, body, and optional link. It is sent through Firebase Cloud Messaging to device tokens stored for the selected members.

If a member does not receive it, check that the correct member has a current device token and that the provider accepted the message. Do not assume that an iOS or Android device is reachable merely because the member account is active.

Transactional email

Other parts of the platform create email jobs for events such as account or booking communication. When email is enabled, the job is placed on AWS SQS and a background command sends it later.

This protects the original booking or account request from waiting on a slow mail server, but it creates two separate results: the business action may succeed while the email still waits or fails.

flowchart LR
    A[Booking or account event] --> B[Create email message]
    B --> C[AWS SQS queue]
    C --> D[Background email worker]
    D --> E{Mail provider accepts it?}
    E -- Yes --> F[Delivery continues outside the app]
    E -- No --> G[Keep error for investigation or retry]

Message safety

Do not send passwords, full payment details, private access codes, or unnecessary personal information through a broadcast. A filter or recipient selection can be wrong, and notification previews may appear on a locked device.

For important operational messages, record the channel, audience, time, and reason, then check the matching delivery report.

When delivery fails

Technical reference

The admin screens are #newsletters, #listofnewsletters, #failedsms, and #push-list. Symfony notification operations are grouped under /api/v1/notifications. Push uses FCM; transactional email uses AWS SQS and the app:send-email worker. SMS uses the configured SMS service and separate success/failure records.