Pre-send checklist and journey operating rules

Most send incidents come from the audience, not the copy. After saving a segment, read the conditions back out loud and check that the audience count has the number of digits you expected. When the digits are off, one condition is usually inverted. Look at the exclusions in the same pass: unsubscribes, customers who just completed a payment, internal accounts, and test devices. Only once audience and exclusions are settled do you attach the creative. Reverse that order and you end up widening the audience to fit the creative, and the people who came in that way leave later as unsubscribes. This is also the point to filter out anyone who already received the same message in the previous send.

A preview pane does not surface failures in merge variables or deep links. Receive one test send on a real device for each channel. On push, look at where the title truncates on the lock screen; on email, at the body with images blocked; on in-app, at the screen where the display condition fires. Check here what appears when a merge variable is empty. Open the links and follow them all the way to the destination. Deep links land differently on a device that has the app installed and one that does not, so receive both. If the creative depends on an app review or a store release, confirm that the release lands ahead of the send.

A scheduled send goes out in the middle of the night when the account time zone differs from the customer's. After saving the schedule, confirm which time zone it was saved in, and if you have overseas subscribers, work out arrival time separately. Check the calendar for another journey already set at the same hour. When a promotion and a transactional alert land at the same moment, the alert that actually needed reading gets buried. If you enforce a quiet-hours rule, check whether the schedule straddles it. A bulk send spreads out over time rather than leaving all at once, so anchor on when the last message arrives, not when the send starts.

For each Journey, define exit and exclusion conditions alongside entry conditions, then set priorities between Journeys. Include a limit on total messages per customer in the operating rules. OneSignal's Push frequency capping applies only to push; it does not combine email, SMS, or in-app messages. A cross-channel cap needs a separate design that connects channel send history and exclusion conditions. Define exceptions such as transactional alerts. Push messages that override the cap still count toward later caps, while messages blocked by the cap are dropped rather than queued. Record the editor, date, applicable channels, and exceptions when a rule changes. Compare the operating rules with the behavior documented in OneSignal Push frequency capping.

A send cannot be undone, but it can be stopped. A push already delivered cannot be recalled, while scheduled sends and journeys in flight can be halted. So for the first thirty minutes, watch delivery counts, error rate, and the rise in unsubscribes. If a figure looks unlike the usual, stop the remaining schedule first and diagnose afterwards. Record the figures and the judgement in the same document for the next send. Decide before the send who stops it and who holds that authority. Start an approval chain the moment something looks wrong and the remaining schedule goes out in the meantime. Write the rule so the owner stops first and reports second. Once you reach this point, that record becomes the checklist for the next campaign: add items when an incident happens, and leave alone anything that has not caught twice in a row.