Routing Alerts to the Right People: A Notification Playbook

An alert that wakes the wrong person at 3 A.M., storms an inbox during a campaign, or burns your sending domain is almost never a "send more carefully" problem. It is a routing-config problem: the wrong recipient, no quiet hours, test mode still on in production, or bulk mail fired too fast. This playbook triages those causes in order, least to most invasive. The fix lives in editable config, not code, so a change never requires a rebuild [2343].

Use this playbook when operational notifications reach the wrong recipient, wake on-call staff overnight, storm during a send, or risk the deliverability of the sending domain.

Typical triggers:

• An alert lands with the wrong person or on the wrong channel for that outcome.
• On-call staff are paged overnight for events that could wait until morning.
• A bulk send floods contacts and starts drawing spam complaints or unsubscribes.
• A trial client's live notifications are going somewhere they should not.

Classify before you touch anything. Blast radius differs sharply by cause.

The dividing line is whether real recipients were affected. A mis-route caught in config is recoverable. A burned sending domain, or a live client routing every alert to the builder, is an operational failure that reaches people directly.

Keep roles generic and named up front so escalation is not improvised.

• Notification / on-call owner: runs this triage, owns the decision to pause sends or flip a channel toggle.
• Config owner: owns the per-client notification config — the recipient list, routing table, quiet hours, and test mode [2343].
• Comms lead: owns recipient-facing messaging and the fallback while routing is corrected.

Work read-only first. Read the config before you change any routing.

[ ] 1. Read the ROUTING TABLE for the affected outcome. Confirm which
       recipient, channel, and timing each call outcome maps to —
       booking confirmed, medical-review lead, out-of-area lead,
       callback request, abandoned booking, dispatch. [2343]
[ ] 2. Confirm the RECIPIENT is the right labelled contact. Check the
       labelled list (operator, nurse, medical contact, callback
       team) — a mis-set label sends the alert to the wrong person. [2343]
[ ] 3. Check whether QUIET HOURS are configured. If overnight alerts
       are firing live instead of holding for the ~7 A.M. digest,
       quiet hours are off or misconfigured. [2343]
[ ] 4. Check whether TEST MODE is on in production. Test mode routes
       ALL notifications to the builder only; left on past a trial,
       real recipients receive nothing. [2343]
[ ] 5. Check the CHANNEL TOGGLE. Confirm SMS is only on where A2P
       approval allows; a channel switched on prematurely mis-sends. [2343]
[ ] 6. For bulk email, check the SEND RATE and SEGMENTATION. Confirm
       one message every 40–70 seconds with a randomized delay, in
       business hours, segmented by topic — not an un-throttled blast. [2434]

Match the symptom to the cause. Each branch points to one mitigation.

Apply the least invasive fix that resolves the diagnosed branch. Do not stack fixes you have not diagnosed.

1. Turn off test mode, or fix a mis-set recipient. Both are single config edits. Flip test mode off so live alerts leave the builder and reach the labelled recipient; or correct the routing table so the outcome maps to the right operator, nurse, medical contact, or callback team. No rebuild required [2343].
2. Enable quiet-hours hold plus the morning digest. Turn on quiet hours so overnight bookings, callbacks, and leads are held and released together in one ~7 A.M. digest instead of paging staff through the night [2343].
3. Throttle and segment the bulk send. Send one message every 40–70 seconds with a randomized delay, only during business hours, so volume looks human; segment contacts by subscription topic (newsletter, off-plan, area spotlight, lifestyle) so each list gets only what it opted into, and let unsubscribe remove the contact automatically [2434].
4. Move the whole client onto config. If routing changes keep requiring code, migrate the client to the config-driven engine — labelled recipients, routing table, quiet hours, test mode, channel toggles — so any change edits config, not code [2343].

For time-based reminders, derive the task and its reminders from one date field so they cannot drift apart: a renewal task due 120 days before a contract end date, a WhatsApp-plus-email reminder at 120 days, and a WhatsApp-only reminder at 100 days all come from that single field [2384].

Escalate to the config owner when:

• The correct routing is ambiguous — the outcome has no clear labelled recipient.
• A channel toggle needs flipping but A2P approval status is unconfirmed [2343].
• A bulk send has already drawn complaints and domain reputation is at risk [2434].

Rollback while you escalate: pause the affected send and hold non-urgent alerts. Holding into the next digest is slower but cannot storm recipients or burn the domain [2343][2434].

Verify against the config and the actual delivery, not the assumption.

• Fire one test event per outcome and confirm each lands on the mapped recipient, channel, and timing [2343].
• Confirm an overnight event is held and appears in the ~7 A.M. digest rather than paging live [2343].
• Confirm a throttled send paces at 40–70 seconds, stays in business hours, and that an unsubscribe drops the contact from the right list [2434].

Recovery is complete only when live routing matches the config for every outcome, not when one alert looks right.

Capture, in the incident record:

• The routing-table entry for the affected outcome and the recipient it resolved to [2343].
• Whether test mode and quiet hours were on, and the channel-toggle state [2343].
• The send rate, segmentation, and any complaint or unsubscribe spike, when a bulk send was the cause [2434].

Recipient comms template:

We corrected a notification-routing issue that affected some alerts. Delivery to the correct recipients has been restored, and overnight items now arrive in a single morning summary. No action is needed on your side.

Run a retro and link it from the incident record. Lock in prevention:

• One config-driven engine per client — recipients, routing, timing, quiet hours, and test mode all in editable config, never bespoke code [2343].
• Test mode never left on in production past a trial [2343].
• Quiet hours configured so overnight alerts release in one morning digest [2343].
• Throttled, segmented, business-hours bulk sends to protect the sending domain [2434].
• Reminders derived from a single date field so they never fall through the cracks [2384].