What Phase 0 and Phase 1 actually did

• 20% holdout: one in five eligible people receives no rescue email, so we can measure whether the email creates incremental progress.
• 100 sends per hour: a campaign with no explicit throttle defaults to 100, not unlimited.
• 24-hour minimum gap: even if configuration is wrong, two campaign steps cannot stack closer than one day.
• 48-hour overdue expiry: a stale rescue message does not suddenly send days later after an outage or pause.
• 14-day staff-touch block: recent human engagement blocks automated rescue so the CRM does not talk over staff.
• 30-minute uncertain-send threshold: a send that crashed mid-provider-call becomes "needs human review"; it is never automatically repeated.
• 30-day unsubscribe link validity: each email mints fresh body and one-click links that are valid for 30 days from that send. Both links in an older email expire; a later spam complaint can still suppress through the provider webhook.
• Owned addresses only: the email must be attached to the CRM contact; arbitrary template addresses cannot receive marketing.
• Agent digests remain operational: ordinary agent service digests are not stopped by vendor marketing rules. Agent mass-marketing is still gated.
• Turning off an agent digest is broad: disabling an agent's digest subscription is treated as a full marketing unsubscribe across all of that agent's known addresses. Reversal requires recorded evidence.
• Manual stops stay stopped: a completed journey may be deliberately re-enrolled after checks; an unsubscribe or staff stop cannot silently reactivate.

It is a new safety window for nurture steps. If a Sydney property's email becomes due at 7:30pm Sydney time, it waits until 8am Sydney time the next day. A Hobart property uses Hobart time. Waiting does not count as a failed attempt.

It is separate from the old workflow "Correct time" dropdown. That dropdown changes a legacy workflow action to choices such as "Right now" or "+1 day, 8AM". The nurture runner does not use the old workflow engine, so it stores its own visible per-step window. In the first version the window is configured when the campaign is created; it is not yet an editable dropdown.

It is better described as a 10-minute due-work checker. Every ten minutes it wakes up, looks for up to 100 journeys that are due, and re-checks campaign status, expiry, customer progress, suppression, staff touch, local time window and hourly throttle.

It does not email everyone every ten minutes. It does not enrol people, does not touch draft or paused campaigns, and does not retry failures. When one journey is genuinely due and eligible, it creates one unique send instruction; the normal queue worker performs the actual provider call.

The early draft asked the database several questions separately for every contact. That is acceptable for a 15-person pilot but would create roughly 70,000 queries for a 10,000-person newsletter audience.

That issue was fixed before completion. The final code asks the database a small fixed set of bulk questions for the whole audience. A regression test caps the core bulk eligibility work at nine queries for 25 contacts, and the rescue conflict checks are also bulk queries.

Remaining Phase 2 work: the large utility preview still loads its full candidate set into memory and renders synchronously. Before the 10,000-person utility lane, the preview should be lazy-loaded and paginated. This is not a blocker for the 15-lead rescue pilot.

It is central configuration, not duplicated throughout the code, but today changing it requires a code/config deployment. It is not editable in the CRM and it is not shown clearly enough on the campaign screen.

The cap counts marketing-class sends only. A staff member's normal one-to-one service email does not consume the marketing allowance.

Recommendation: keep it fixed for the small pilot so the experiment has one stable policy. Before Phase 2, surface it in Parameters with an audit log, show the effective value on every campaign, and apply it globally across campaigns.

The database now stores the normalized email address, reason, source, linked contact, occurrence count, first/last seen dates, whether it is active, and any controlled lift evidence. Sources include body and one-click unsubscribes, SendGrid unsubscribe/spam/bounce/block/invalid/drop events, legacy unsubscribe tags, manual suppression and historical backfill.

The audience preview shows that someone was excluded for ADDRESS_SUPPRESSED, and the contact journey shows status. There is not yet a dedicated suppression list screen. I agree that you need one. It should be read-only by default and make every inclusion explainable.

The legacy CRM has several ways to copy another address: a template's "CC (Email Only)" field, agent digest CC addresses, and company CC addresses. This is not a hidden second contact record; it is simply an extra copied recipient. For example, an operational agent digest may go to an agent and copy their assistant.

A marketing CC is unsafe because the copied person has not independently passed consent, suppression and frequency checks, and their unsubscribe cannot be tracked cleanly. The new rule therefore removes CC from marketing-class sends and logs that it happened. Operational messages can still use CC. If two people should receive marketing, each needs a separate, individually checked send.