Incident Response
How do you roll back a campaign already sent?
Operations LeadOPopening question
Our agent queued a winback campaign off a stale segment and mailed a 40-percent discount meant for churned trials to 40,000 active paying customers — annual plans included. Support tickets spiked within the hour, finance is modeling the exposure, and someone asked if we can recall the send. We cannot. Email has no unsend.
So it's consequence management now. Contain the damage, decide whether to honor or bound the offer, rebuild the guardrail that failed. The playbook should have been written before the incident — the first hour after a bad send is the worst possible time to design process. For those who've been here: what did the first hour actually look like, and what structural fix came out of the retro?
Support owns the first hour. You need macros ready before you need them: a holding reply that acknowledges the error honestly, a decision tree for honoring versus bounding the offer, a direct escalation line to whoever can authorize appeasement. Silence is the costliest option — customers discovering the error from each other turns a mistake into a trust event. And log every commitment made in the thread. Ad-hoc promises during incidents become policy by precedent if nobody tracks them.
Contain what's technically containable. Pause in-flight automation enrollments, suppress follow-up branches referencing the bad offer, correct or pull landing pages with mismatched terms, freeze the segment definition for forensics before anyone edits it. The kill switch gets tested quarterly — discovered during the incident is too late — and send-stopping controls should be scoped so on-call staff can halt automation without full admin rights. The segment query, the approval record, the send log: that's the incident's black box. Preserve it first.
Then the correction: one email, affected recipients only, states the error plainly, presents one consistent resolution. Partial honors and vague apologies generate a second ticket wave — I've watched it happen. Then the retro asks structural questions: why did a stale segment exist, why did approval miss the mismatch, which check catches it cheapest. Usual answers: freshness timestamps on every approval screen, offer-code validation against billing before send, audience-size anomaly flags when a winback audience suddenly includes active annuals.
"Partial honors and vague apologies generate a second ticket wave" — plus the three structural checks (freshness timestamps, offer validation, audience anomaly flags). It covers both halves of the OP's question: the first-hour containment and the retro fix, with the warning about inconsistent resolution that most playbooks omit.
Why this one: it's the only comment spanning containment and prevention, and the second-wave warning comes from clearly lived experience.
Accept that email cannot be unsent, then contain: pause in-flight branches, freeze the segment for forensics, correct landing surfaces, send one honest correction to affected recipients only, and retro the guardrail with freshness timestamps, offer validation, and audience anomaly flags. Test the kill switch before you need it.
Further reading: the companion wrong-segment analysis in what changes Monday, audit-trail requirements in audit trails, and our 15-tool comparison.