---
name: "outbound_campaign_ops"
description: "Run outbound campaigns week to week: launch gates, test design with real sample sizes, send-volume discipline, the weekly review, and knowing when to pause, fix, or kill a campaign. Triggers on launching a cold email or outbound campaign, planning an outbound test, reviewing campaign results, rising spam or bounce rates, scaling send volume, or deciding whether to keep or stop a campaign."
metadata: { "version": "1.0.0" }
---

# Outbound Campaign Ops

## Purpose

Run outbound as an operating cadence, not as a series of launches and panics. This skill covers the full week to week loop for email-led outbound campaigns: the gates a campaign must clear before it sends, how to design a test that can actually be read, how volume ramps without burning a domain, and the weekly review that ends in one decision and one change.

Reply handling after prospects answer is a separate job. Use the outbound reply handling skill for triage, templates, and meeting handoff. This skill owns everything before the reply and everything about the campaign as a whole.

## Workflow

1. Clear the launch gates. Work through references/launch-and-review.md in order: audience and consent, authentication and domain, message and sequence, volume and ramp. Every gate gets an owner and a date. A campaign that fails a gate does not launch on a promise to fix it mid-flight.
   - Check the consent basis per jurisdiction. CAN-SPAM in the United States is an opt-out model with duties on headers, subject lines, ad identification, postal address, and honoring opt-outs within 10 business days. Canada's CASL requires consent first, plus identification and a working unsubscribe. Mixed lists get split when the basis is unclear.
   - Verify SPF and DKIM pass on a real test send, DMARC is published at least at p=none with alignment, and one-click unsubscribe headers are present on marketing mail per RFC 8058.
   - Keep outbound on its own domain, away from customer, billing, support, and employee mail.

2. Design the test before the first send. Follow references/test-design.md.
   - One variable, one hypothesis written as a number, one primary metric. Positive reply rate is the default primary metric.
   - Size it with `python3 scripts/campaign_review.py sample-size --baseline 0.03 --mde 0.01`. If the planned send cannot reach that size, test a bigger swing, pool weeks, accept a larger minimum detectable effect in writing, or drop the test and make a plain operating choice.
   - Split inside each segment, hold the assignment across the whole sequence, and send both variants interleaved in the same window.

3. Send with volume discipline.
   - Follow the written ramp: per-mailbox cap, per-domain cap, step dates. Raise volume only after a full clean week at the current step.
   - Watch guardrails daily during a send: spam rate, hard bounces, unsubscribes, authentication failures. Stop early for harm. Never stop early for an early test lead.
   - Know where the bulk lines sit: close to 5,000 messages in 24 hours to personal Gmail from one primary domain triggers permanent bulk sender duties at Google, and Microsoft applies the same scale to its consumer domains from May 2025. A campaign does not drift across that line by accident.

4. Run the weekly review, in the fixed order in references/launch-and-review.md: health first, then funnel, then segment read, then test read, then ten raw replies read out loud.
   - Run the week through the script: `python3 scripts/campaign_review.py verdict --sends 5000 --hard-bounces 40 --spam 8 --unsubs 22 --replies 150 --positive 31 --meetings 6`.
   - Count unique people, not touches. Report human replies and auto-replies apart.
   - Read segments separately. The campaign average hides the segment that earns the meetings and the segment that earns the complaints, and they are rarely the same one.

5. Decide, log, and change one thing.
   - End every review with one decision: continue, fix, pause, or kill, using the decision rules in references/launch-and-review.md. Name the owner and the reason in the log.
   - Make one change for next week. A week where three things changed teaches nothing.
   - Log the test result, the decision, and the lesson in the campaign log the same day.

## Output Contract

Every launch produces:
- A gate sheet: each gate from references/launch-and-review.md marked pass or blocked, with an owner and a date, and the blocked items named plainly.
- A test plan: variable, hypothesis as a number, primary metric, guardrails, planned size per variant from the sample-size command, split rule, and read date.
- A ramp plan: per-mailbox cap, per-domain cap, step dates, and the clean-week rule for moving up a step.

Every weekly review produces:
- A one-page review: health rates, funnel counts, segment read, test read if the test reached its planned size, the script verdict, and the ten-reply quality note.
- One decision (continue, fix, pause, or kill) with the reason, the owner, and the single change for next week.
- A campaign log entry: date, decision, test outcome, and the lesson in one line.

## Operating Rules

1. No gate, no launch. Authentication failing, suppression not applied, consent basis unclear for a segment, or no named reply owner each block a launch on their own.
2. Deliverability before copy. A campaign landing in spam has no copy problem worth debating. Health rates come first in every review.
3. The spam ceiling is hard. Google tells senders to keep the Postmaster Tools spam rate below 0.3 percent. At or above it, pause the domain. The script warning line is 0.1 percent: investigate there, do not wait for the ceiling.
4. Other thresholds are policy, not physics. The bounce and unsubscribe lines in scripts/campaign_review.py are team defaults set in one place at the top of the file. Change them there, with a dated note, never by arguing with a single week's output.
5. Never present a benchmark as a fact. No universal reply rate, open rate, or meeting rate is quoted in this skill, because none holds across lists and offers. Judge a campaign against its own history and its own test plan.
6. Never stop a test on a peek. Fix the size in advance and read it once at that size. Guardrail checks are for harm only.
7. Raw replies beat raw replies rate. A variant can win replies by provoking complaints and refusals. Declare winners on positive replies, with compare run on positive counts.
8. Pause first, argue later, on consent or authentication defects. A legal or plumbing fault found mid-campaign stops sends that day, while the team sorts out who knew what.
9. Protect the core domain at all costs. If a choice risks the domain that carries customer and billing mail, the answer is no, whatever the campaign stands to gain.
10. Kill cleanly. A killed campaign gets a log entry with what was tried, what the numbers said, and what the next campaign should do differently. A campaign that fades out with no entry teaches nothing and usually gets relaunched by someone else.