If you run a subscription brand, churn is the workload you are about to ask an agent to own. It is also the workload most fragmented across systems, which is why most teams stall before they start.
A single churn signal lives in three places at once. The subscription itself, with its cadence, last charge, and skip history, sits in Recharge, Stripe Billing, or Bold. The lifecycle signal, the open rates falling, the win-back flow already attempted, lives in Klaviyo. The conversation, the support ticket where the customer said "shipping again, ugh," lives in Gorgias or Zendesk. No single platform sees the whole picture, and no agent should pretend to.
This is the architectural move. Recharge or Stripe Billing stays source of truth for the subscription. Klaviyo stays source of truth for lifecycle. Your helpdesk stays source of truth for the conversation. Dock holds what the agent produces: a churn-risk row, an intervention plan, a draft outreach. The row carries pointers, stripe_subscription_id, recharge_subscription_id, klaviyo_profile_id, and the agent reads fresh from each platform every time it works the case. Dock's consent gate fires the actual intervention, the discount, the pause, the win-back send, only after a human approves it.
One worked example. Recharge fires a subscription/skipped webhook for the third consecutive cycle. Klaviyo flags the same profile as "engagement decay, 60 days." Gorgias has an unresolved ticket from the customer about box variety. The retention agent picks up all three signals, opens a row in the Churn-risk queue, attaches the lifecycle history and the ticket transcript, and drafts a save offer: a one-time variety swap plus a 20 percent loyalty credit on the next charge. The retention manager reviews the row, edits the credit down to 15 percent, clicks Approve. Dock fires the Recharge subscription update and the Klaviyo Saved with offer event. The row closes with an attribution trail: who drafted, who approved, what fired, and where.
The data flow, five steps:
- Webhook or scheduled pull surfaces a churn signal from Recharge or Stripe.
- Agent reads the matching Klaviyo profile and helpdesk ticket through their MCP tools.
- Agent writes a Churn-risk row in Dock with pointers and a drafted intervention.
- Retention manager reviews, edits, approves at the consent gate.
- Dock fires the platform-side action and logs the result against the same row.
Why this matters. LTV protection is now an agent workload, not a quarterly project, and the team that catches a churn signal inside one billing cycle saves an account the team that catches it in two cannot. Brand voice on win-back is non-negotiable, and a drafted-in-Dock outreach can be edited by a human before it ships, which a fully autonomous flow cannot promise. Retention attribution stops being a debate, because every save is tied to the agent, the manager, and the offer that closed it. Recurly's 2026 State of Subscriptions tracks reactivation and pause strategies across 76 million subscribers, and the pattern is consistent: the wins come from intervention timing and offer fit, not from sending more email.
If you sell on a recurring cadence, your churn workspace is the highest-leverage thing your retention agent can own this quarter. See the broader pattern in our ecommerce overview and the full stack pattern in running an ecommerce stack with AI.
Open a Churn-risk workspace in Dock and route your first save through it this week.
FAQ
How do cross-system pointers actually work in a Dock churn row?
The row stores platform IDs as columns, stripe_subscription_id, recharge_subscription_id, klaviyo_profile_id, helpdesk_ticket_id. The agent re-fetches live data from each platform on every read, so the row is never a stale mirror. The platforms stay source of truth.
How do we keep win-back voice on-brand when an agent drafts it? The agent drafts into a Dock row, not into Klaviyo. A human reviews, edits, and approves before the send fires. The consent gate is the brand-voice gate.
How do we stop the agent from stacking discounts on customers who already have one?
Add a guardrail column on the row that reads current discount_codes_applied from Recharge or Stripe, and instruct the agent to skip drafting a credit if any active discount exists. Stacking becomes a policy, not a vibe.
What happens if a customer cancels anyway?
The row closes as not_saved, attribution holds, and the agent files the case into a recurring retro workspace. Honoring the cancel is non-negotiable; the consent gate cannot fire a pause against a cancel request.