Pause marketing emails to escalated customers, then restore them

Twice every weekday, at 7am and 1pm in my workspace timezone, keep my MailForge marketing sends away from customers who are in the middle of a bad support experience, and put them back on the list once support has fixed things. Every run does both directions, a pause pass and a restore pass, and then reports what changed in Slack.

For the pause pass, use Zendesk Search Tickets to pull tickets that are currently open or pending at high or urgent priority. Zendesk query syntax handles this well, so search for something like `type:ticket status:open priority>normal` and `type:ticket status:pending priority>normal`, then merge the two result sets and page through everything rather than stopping at the first page. For each ticket, take the requester id and call Zendesk Show User to resolve that person's email address, since there is no direct requester-email field on the ticket. If a requester has no email address on their Zendesk profile, skip them rather than guessing at one. Collapse the results down to one entry per unique email address, keeping the most severe and most recent ticket as the reason for that person.

Before adding anything, read the current suppression list with MailForge List Suppressions, paging through all of it. Call MailForge Add Suppression only for addresses that are not already suppressed, and write the reason so it is unmistakably ours: begin it with the exact marker `support-escalation` and then include the Zendesk ticket id and subject, for example `support-escalation | #4821 | Billing charged twice after upgrade`. That marker is the only thing making the restore pass safe, so never add an escalation suppression without it.

On the same run, do the reverse pass. Use Zendesk Search Tickets again for high and urgent tickets that were solved or closed in the last few days, using a query along the lines of `type:ticket status:solved priority>normal solved>3days` plus the closed equivalent. Resolve each requester's email with Zendesk Show User, read the MailForge suppression list again, and call MailForge Remove Suppression only when that address is on the list AND its stored reason starts with the `support-escalation` marker. Never remove a suppression whose reason is an unsubscribe, a hard bounce, a spam complaint, a manual entry someone on the team added, or anything at all without the marker. When in doubt, leave the address suppressed. This workflow only ever lifts what it put there itself.

One more guard before restoring anyone: if that same email address still shows up in the pause pass with another open or pending high or urgent ticket, leave them suppressed and do not restore them on this run. Someone with one problem solved and another still burning should stay off the campaign list.

Finish by posting to my marketing channel using Slack Bot Send a Message. Keep it to two short lists, "Paused this run" and "Restored this run". Each line should carry the customer's email or name, the ticket subject, and a link to the ticket at https://<my subdomain>.zendesk.com/agent/tickets/<ticket id>. Slack uses mrkdwn, so use *bold* for the two headings and <url|text> for the links. If a run paused nobody and restored nobody, skip the Slack post entirely instead of sending an empty one. The whole point of this message is that marketing can see why a segment shrank before they blame the numbers.

Make the priority threshold, the list of statuses that count as active, and the recently-solved lookback window configurable near the top of the workflow, defaulting to high and urgent, open and pending, and three days. Two things to keep in mind throughout. This suppression is temporary and reversible by design, so the copy and the logic should both reflect that the workflow is parking people, not opting them out. And it affects marketing campaigns only, never transactional mail like receipts, invoices and password resets, which is the standard suppression distinction. Running the workflow twice in a row should change nothing the second time, so always check the live suppression list before every add and every remove.