66,000 contacts. Six weeks. A lifecycle system rebuilt around behaviour.
An AI companion subscription platform whose lifecycle system had stopped responding to what users did. Authentication rebuilt, the list cleaned, onboarding moved from a timer to behavioural branching, and every flow given a benchmark. Every figure below says where it comes from.
“Every report said ‘delivered’. Then I read the contact list, the trigger logic and the inbox-placement data, and found a lifecycle system that wasn’t responding to anything a user did — and was training Gmail to distrust the domain while it wasn’t.”
An AI companion app on a monthly subscription, with 66,000 contacts in Customer.io. On paper the system was working: campaigns scheduled, an onboarding sequence live, a re-engagement campaign live. Sends went out every day and every report came back green.
The reports measured whether emails were sent. Nobody was measuring whether they arrived, whether any sequence responded to something a user did, or what the users falling out of the funnel were worth.
I was brought in for six weeks, via Perennus, to audit the whole system, rebuild it, and hand it back documented.
- 01Deliverability instability
Gmail’s user-reported spam rate had spiked repeatedly since January, reaching roughly 28% in early February. SPF, DKIM and DMARC also required correction. The account’s deliverability report showed Gmail bounces at 56.3% and Gmail delivered at 43.7%. Every additional send was working against the domain.
- 02Invalid population
Roughly a third of the 66,000 contacts — 32% — were invalid addresses the system had been emailing for months. The list was poisoning its own sender reputation, and the campaigns that mattered were paying for it.
- 03Poorly controlled triggers
Reading the trigger logic rather than the reports: one misconfigured behavioural entry condition on the re-engagement campaign had queued around 174,000 sends against a 66,000-contact base — nearly three times the list. It appeared in no campaign report.
- 04Timer-based onboarding
Onboarding fired on elapsed days, regardless of what the user had done in the product. In the month before the engagement it sent 76,266 emails and converted 13.3% of new users to companion creation. Roughly 87 of every 100 signups never got there.
- 05Weak behavioural gates
No step in any sequence checked for an open, a click, a product event or a return. The system couldn’t tell an engaged user from a dead address, so it treated them identically.
Figures in the diagnosis are from the account’s own reports and trigger logic at the time of the audit. Where a screen exists it is shown; where it doesn’t, the figure is a finding, not an exhibit.
- 01Authentication rebuild
SPF, DKIM and DMARC corrected and rebuilt, so every receiving provider could verify the domain before volume came back.
- 02List cleanup
The invalid third suppressed. Sends stopped going to addresses that could only bounce.
- 03Controlled ramp
Volume brought back up on a schedule the domain could sustain, instead of re-flagging it on day one. Gmail’s user-reported spam rate read 0% across the eight send days after the fix, 18–25 March.
- 04Behavioural branching
Onboarding rebuilt in Customer.io around what the user does — opened? created a companion? sent a message? came back? Each branch gets a different next email, or exits. The path is decided by behaviour, not by how many days have passed.
ScreenshotThe rebuilt onboarding flow in Customer.io, 1 April 2026 — sign-up trigger, then branches on opened? and companion created?. Email previews masked. Open full size - 05Lifecycle flows
Five flows: onboarding, re-engagement, gate-hit, paywall conversion and broadcast. The re-engagement rebuild replaced the misconfigured entry condition and cleared the queue.
ScreenshotThe rebuilt re-engagement flow, 6 April 2026 — gated sends, a check for a message sent, a check for a return. Email previews masked. Open full size - 06Measurement framework
A KPI benchmark for every flow, reported daily in structured Slack updates, so leadership watched the system recover instead of waiting for a deck. On handoff: a launch-readiness roadmap and the SOPs the internal team runs the system from.
Six weeks, in order.
Companion creation went from 13.3% to 60.2% across the onboarding rebuild, and both halves are captured. A later reading, taken after the product’s paywall was revised, shows 43.4% — a different stage of the product, not a re-measurement. It sits further down, on its own.
- BeforeTo March 2026
Timer-based onboarding on an unverified domain.
13.3%companion creationCustomer.io · monthly view, 76,266 sends - InfrastructureMarch 2026
Authentication rebuilt, list cleaned, volume ramped.
0%Gmail user-reported spam, 18–25 Mar (peak had been 28%)Gmail Postmaster Tools - Onboarding rebuildBy 1 April 2026
Behavioural branching live: opened → companion created → next email.
60.2%companion creation · the primary resultCustomer.io · 9,806 sends - Lifecycle flowsBy 6 April 2026
Re-engagement rebuilt on a correct entry condition; gate-hit and paywall flows live.
1.0% → 8.4%re-engagement conversionCustomer.io · 1,459 vs 743 sends - Paywall revisionLater
The product’s paywall was changed. A later reading of onboarding shows 43.4% on 2,590 sends — a different stage of the product, kept here for completeness, not a re-measurement of the rebuild.
43.4%companion creation after the paywall revision · not comparableCustomer.io · 2,590 sends
28% of recipients reporting spam, down to none.
The same Gmail Postmaster report, before and after the domain authentication rebuild and list clean. The first chart peaks at 28% in early February. The second runs 18–25 March on an axis that tops out at 4%.
The product’s paywall was revised later in the year. A reading of onboarding taken after that change shows 43.4% on 2,590 sends. It is a different version of the product and a different population — not a re-measurement of the rebuild above, and not comparable to it.
Deliverability first. On the account’s report, Gmail bounces went from 56.3% to 2.1% — a 96.3% reduction — and delivered from 43.7% to 97.9%. Gmail’s user-reported spam rate, which had peaked at 28%, read 0% for the eight send days after the fix.
With mail arriving and onboarding branching on behaviour, companion creation went from 13.3% to 60.2% of new users across the onboarding rebuild. That is the primary result of the engagement, and both readings are captured — the month before at 76,266 sends, and the rebuild at 9,806.
Re-engagement, running on a correct entry condition for the first time, converted 8.4% against 1.0% before. Opens went 8.5% → 27.1%, clicks 0.2% → 6.1%.
Later, the product’s paywall was revised. A reading of onboarding after that change shows 43.4% companion creation, 20.7% opened and 5.5% clicked, on 2,590 sends. It belongs to a different stage of the product and a different population — not a re-measurement of the rebuild.
Every row says where it comes from.
| Metric | Before | After | Source |
|---|---|---|---|
| Companion creation · the onboarding rebuild | 13.3% | 60.2% | Customer.io — both readings captured |
| Companion creation · after the paywall revision | — | 43.4% | Customer.io · screenshot · different stage |
| Gmail user-reported spam | 28% peak | 0% (18–25 Mar) | Postmaster · screenshot |
| Gmail bounced | 56.3% | 2.1% | Account deliverability report |
| Gmail delivered | 43.7% | 97.9% | Account deliverability report |
| Re-engagement converted | 1.0% | 8.4% | Customer.io · screenshot |
| Re-engagement opened | 8.5% | 27.1% | Customer.io · screenshot |
| Re-engagement clicked | 0.2% | 6.1% | Customer.io · screenshot |
A lifecycle system that doesn’t respond to behaviour reports success anyway. The fix wasn’t better emails. It was making the system react to what users actually did — and reading the trigger logic instead of the dashboard.