- Owner or Admin access to message-delivery settings
- Connected WhatsApp or shared-email senders
- One redacted message example and approximate timestamp for an issue
- An owner for provider, recipient, suppression, and retry recovery
Start with Message delivery
Open Settings → Message delivery. The Overview compares Email and WhatsApp using the last seven days of channel outcomes and current recovery queues. Open each channel for detailed sending health, recipient safeguards, and failures.
Delivery is a sequence of evidence
- 01LocalPrepared
Content and recipient are ready but nothing has left WRKZY.
- 02PendingSubmitted
WRKZY handed the request to the connected provider.
- 03AcceptedProvider accepted
The provider accepted processing, not necessarily delivery.
- 04ResultDelivered or failed
A terminal provider event confirms delivery or an exception.
- 05RecoverException reviewed
An owner diagnoses, recovers safely, or escalates with evidence.
Read the Overview
For Email, review Sent, Delivered, Opened, and Failed alongside connection health, scheduled failures, suppressions, bounces, and complaints. For WhatsApp, review Sent, Delivered, Read, and Failed alongside connected senders, default sender, quality rating, and unavailable templates.
“No activity” is different from “Healthy.” A percentage based on very small volume is not a stable trend.
Daily operating procedure
- Open Message delivery and select Refresh.
- Start with a channel marked Needs attention or Unavailable.
- Compare failure count with sent volume and the first incident time.
- Open the Email or WhatsApp tab.
- Check sending health before retrying recipients.
- Read recipient safeguards, suppression or restriction state, and provider reason.
- Follow the linked connection, template, campaign, or scheduled-message record.
- Recover only the affected item after the underlying cause is fixed.
- Refresh and verify a new terminal state.
| Signal | Likely scope | First check |
|---|---|---|
| One failed recipient | Record, address/number, consent, or provider response | Exact failure reason and suppression/restriction |
| Many failures on one sender | Connection or provider health | Default sender, provider reachability, OAuth/SMTP, quality rating |
| Unavailable WhatsApp templates | Provider approval or synchronization | Templates for the connected sender |
| Email complaints/unsubscribes | Compliance-protected recipient | Do not remove suppression merely to resend |
| Awaiting delivery update | Provider has not produced a terminal event | Wait and refresh; do not duplicate the send |
| Delivery data unavailable | The summary could not load or your role cannot access it | Refresh once, compare the source record, and contact WRKZY Support if the state persists |
Trend review
Weekly, compare delivery rate by channel and connection. Investigate sudden movement, but do not optimize for opens or reads as proof of customer outcome. Sampling successful records helps verify that provider metrics align with conversation timelines.
Open full sizeRecovery rules
Never reconnect a healthy sender just because one recipient failed. Never remove a complaint or unsubscribe suppression to increase delivery. Do not resend an uncertain outcome until the source record proves it did not complete. For a broad incident, pause affected campaigns and customer-facing automations before testing.
Escalate with channel, connection/sender label and ID, campaign or message ID, approximate time/timezone, current delivery state, provider reason, and a redacted screenshot. Exclude content and credentials unless specifically authorized and necessary.
- Channel and time window confirmed
- Connection health separated from recipient outcome
- Suppression and consent respected
- Provider reason recorded
- Underlying cause fixed before recovery
- Recovered message reached a verifiable state