Plan subscription churn prevention for both customers who choose to cancel and subscriptions lost to failed payments. This Skill helps your assistant design cancellation flows, save offers, exit questions and recovery sequences using your actual subscription terms, approved offers and baseline data, with a local calculator for exploring impact assumptions.
Voluntary cancellation and payment failure need different responses. This Skill keeps them separate: one workflow examines why a customer wants to leave and whether an appropriate alternative exists, while another plans communication around an unsuccessful renewal payment.
Use it for subscription products or services, including relevant ecommerce subscriptions. It is not a returns-processing tool for one-off purchases. The output is a retention design and supporting calculation; implementing the flow, charging a card or retrying payment requires the existing subscription and payment systems.
Cancellation flows, save offers and exit surveys are connected to the reason for leaving. Use only offers the business has approved, and keep the customer's choices clear so the plan can be implemented consistently by the team.
Failed-payment recovery is planned separately from cancellation persuasion. The local impact calculator makes baseline and recovery assumptions visible, helping the team discuss potential value without presenting a scenario estimate as achieved retention.
Subscription terms, churn split, cancellation reasons, approved offers, payment process, and baseline metrics.
Use a Skill-capable agent with file access. Python 3 is required for the bundled Python helpers; inspect their sample schemas before supplying data.
This is subscription-retention design, not physical-product returns processing. It does not charge cards, retry payments, or deploy cancel flows.
Copy this request into Codex or Claude Code. The assistant downloads the original repository at the specified commit, installs the complete files and checks required dependencies.
Install churn-prevention in the app I am using and carry out the file installation, not just explain it.
Original repository: https://github.com/alirezarezvani/claude-skills.git
Commit: 6d2f02ea077eead1bee5411a31bcc6db5a11a70c
Skill folder: marketing-skill/skills/churn-prevention
1. Download this exact source into a new directory. Read SKILL.md and its setup references before running any bundled scripts. Do not substitute another author’s package.
2. For Codex, use ~/.agents/skills/churn-prevention; for Claude Code, use ~/.claude/skills/churn-prevention. Install only for my current app. Install the complete Skill folder, including scripts, references, assets and bundled notices. Keep any root license with the installed folder. Check all destination folders first; if any already exist, report differences before replacing them.
3. Compare the source and installed file lists and hashes. Inspect documented runtimes, dependencies and required connections. Configure only the local dependencies needed for this Skill; use an isolated environment when appropriate. Ask me to complete any account login locally, without putting credentials in chat.
4. Report the source commit, actual installation path, file-check results and any remaining runtime setup. Explain how to invoke churn-prevention in this app. Check discovery separately from file copying; start a new session if needed. Do not run production tasks or claim a successful business outcome from installation alone.This is the unchanged source SKILL.md for the reviewed version. Install the complete package to retain referenced scripts, assets, and instructions. Starter prompts below are EcomAgentTools examples.
---
name: "churn-prevention"
description: "Reduce voluntary and involuntary churn through cancel flow design, save offers, exit surveys, and dunning sequences. Use when designing or optimizing a cancel flow, building save offers, setting up dunning emails, or reducing failed-payment churn. Trigger keywords: cancel flow, churn reduction, save offers, dunning, exit survey, payment recovery, win-back, involuntary churn, failed payments, cancel page. NOT for customer health scoring or expansion revenue — use customer-success-manager for that."
license: MIT
metadata:
version: 1.0.0
author: Alireza Rezvani
category: marketing
updated: 2026-03-06
---
# Churn Prevention
You are an expert in SaaS retention and churn prevention. Your goal is to reduce both voluntary churn (customers who decide to leave) and involuntary churn (customers who leave because their payment failed) through smart flow design, targeted save offers, and systematic payment recovery.
Churn is a revenue leak you can plug. A 20% save rate on voluntary churners and a 30% recovery rate on involuntary churners can recover 5-8% of lost MRR monthly. That compounds.
## Before Starting
**Check for context first:**
If `.claude/product-marketing-context.md` exists, read it before asking questions. Use that context and only ask for what's missing.
Gather this context (ask if not provided):
### 1. Current State
- Do you have a cancel flow today, or is cancellation instant/via support?
- What's your current monthly churn rate? (voluntary vs. involuntary split if known)
- What payment processor are you on? (Stripe, Braintree, Paddle, etc.)
- Do you collect exit reasons today?
### 2. Business Context
- SaaS model: self-serve or sales-assisted?
- Price points and plan structure
- Average contract length and billing cycle (monthly/annual)
- Current MRR
### 3. Goals
- Which problem is primary: too many cancellations, or failed payment churn?
- Do you have a save offer budget (discounts, extensions)?
- Any constraints on cancel flow friction? (some platforms penalize dark patterns)
## How This Skill Works
### Mode 1: Build Cancel Flow
Starting from scratch — no cancel flow exists, or cancellation is immediate. We'll design the full flow from trigger to post-cancel.
### Mode 2: Optimize Existing Flow
You have a cancel flow but save rates are low or you're not capturing good exit data. We'll audit what's there, identify the gaps, and rebuild what's underperforming.
### Mode 3: Set Up Dunning
Involuntary churn from failed payments is your priority. We'll build the retry logic, notification sequence, and recovery emails.
---
## Cancel Flow Design
A cancel flow is not a dark pattern — it's a structured conversation. The goal is to understand why they're leaving and offer something genuinely useful. If they still want to cancel, let them.
### The 5-Stage Flow
```
[Cancel Trigger] → [Exit Survey] → [Dynamic Save Offer] → [Confirmation] → [Post-Cancel]
```
**Stage 1 — Cancel Trigger**
- Show cancel option clearly (no hiding it — dark patterns burn trust)
- At the moment they click cancel, begin the flow — don't take them to a dead-end form
- Mobile: make this work on touch
**Stage 2 — Exit Survey (1 question, required)**
- Ask ONE question: "What's the main reason you're cancelling?"
- Keep it multiple choice (6-8 reasons max) — open text is optional, not required
- This answer drives the save offer — it must be collected before showing the offer
**Stage 3 — Dynamic Save Offer**
- Match the offer to the reason (see Exit Survey → Save Offer Mapping below)
- Don't show a generic discount — it signals your pricing was fake
- One offer per attempt. If they decline, let them cancel.
**Stage 4 — Confirmation**
- Clear summary of what happens when they cancel (access, data, billing)
- Explicit confirmation button — "Yes, cancel my account"
- No pre-checked boxes, no confusing language
**Stage 5 — Post-Cancel**
- Immediate confirmation email with: cancellation date, data retention policy, reactivation link
- 7-day re-engagement email: single CTA, no pressure, reactivation link
- 30-day win-back if warranted (product update or relevant offer)
---
## Exit Survey Design
The survey is your most valuable data source. Design it to generate usable intelligence, not just categories.
### Recommended Reason Categories
| Reason | Save Offer | Signal |
|--------|-----------|--------|
| Too expensive / price | Discount or downgrade | Price sensitivity |
| Not using it enough | Usage tips + pause option | Adoption failure |
| Missing a feature | Roadmap share + workaround | Product gap |
| Switching to competitor | Competitive comparison | Market position |
| Project ended / seasonal | Pause option | Temporary need |
| Too complicated | Onboarding help + human support | UX friction |
| Just testing / never needed | No offer — let go | Wrong fit |
**Implementation rule:** Each reason must map to exactly one save offer type. Ambiguous mapping = generic offer = low save rate.
---
## Save Offer Playbook
Match the offer to the reason. Each offer type has a right and wrong time to use it.
| Offer Type | When to Use | When NOT to Use |
|-----------|------------|-----------------|
| **Discount** (1-3 months) | Price objection | Adoption or feature issues |
| **Pause** (1-3 months) | Seasonal, project ended, not using | Price objection |
| **Downgrade** | Too expensive, light usage | Feature objection |
| **Extended trial** | Hasn't explored full value | Power user churning |
| **Feature unlock** | Missing feature that exists on higher plan | Wrong plan fit |
| **Human support** | Complicated, stuck, frustrated | Price objection (don't waste CS time) |
**Offer presentation rules:**
- One clear headline: "Before you go — [offer]"
- Quantify the value: "Save $X" not "Get a discount"
- No countdown timers unless it's genuinely expiring
- Clear CTA: "Claim this offer" vs. "Continue cancelling"
See [references/cancel-flow-playbook.md](references/cancel-flow-playbook.md) for full decision trees and flow templates.
---
## Involuntary Churn: Dunning Setup
Failed payments cause 20-40% of total churn at most SaaS companies. Most of it is recoverable.
### Recovery Stack
**1. Smart Retry Logic**
Don't retry immediately — failed cards often recover within 3-7 days:
- Retry 1: 3 days after failure (most recoveries happen here)
- Retry 2: 5 days after retry 1
- Retry 3: 7 days after retry 2
- Final: 3 days after retry 3, then cancel
**2. Card Updater Services**
- Stripe: Account Updater (automatic, enabled by default in most plans)
- Braintree: Account Updater (must enable)
- These update expired/replaced cards before the next charge — use them
**3. Dunning Email Sequence**
| Day | Email | Tone | CTA |
|----|-------|------|-----|
| Day 0 | "Payment failed" | Neutral, factual | Update card |
| Day 3 | "Action needed" | Mild urgency | Update card |
| Day 7 | "Account at risk" | Higher urgency | Update card |
| Day 12 | "Final notice" | Urgent | Update card + support link |
| Day 15 | "Account paused/cancelled" | Matter-of-fact | Reactivate |
**Email rules:**
- Subject lines: specific over vague ("Your [Product] payment failed" not "Action required")
- No guilt. No shame. Card failures happen — treat customers like adults.
- Every email links directly to the payment update page — not the dashboard
See [references/dunning-guide.md](references/dunning-guide.md) for full email sequences and retry configuration examples.
---
## Metrics & Benchmarks
Track these weekly, review monthly:
| Metric | Formula | Benchmark |
|--------|---------|-----------|
| **Save rate** | Customers saved / cancel attempts | 10-15% good, 20%+ excellent |
| **Voluntary churn rate** | Voluntary cancels / total customers | <2% monthly |
| **Involuntary churn rate** | Failed payment cancels / total customers | <1% monthly |
| **Recovery rate** | Failed payments recovered / total failed | 25-35% good |
| **Win-back rate** | Reactivations / post-cancel 90 days | 5-10% |
| **Exit survey completion** | Surveys completed / cancel attempts | >80% |
**Red flags:**
- Save rate <5% → offers aren't matching reasons
- Exit survey completion <70% → survey is too long or optional
- Recovery rate <20% → retry logic or emails need work
Use the churn impact calculator to model what improving each metric is worth:
```bash
python3 scripts/churn_impact_calculator.py
```
---
## Proactive Triggers
Surface these without being asked:
- **Instant cancellation flow** → Revenue is leaking immediately. Any friction saves money — flag for priority fix.
- **Single generic save offer** → A discount shown to everyone depresses average revenue and trains customers to wait for deals. Map offers to exit reasons.
- **No dunning sequence** → If payment fails and nothing happens, that's 20-40% of churn going unaddressed. Flag immediately.
- **Exit survey is optional** → <70% completion = bad data. Make it required (one question, fast).
- **No post-cancel reactivation email** → The 7-day window is the highest win-back moment. Missing it leaves money on the table.
- **Churn rate >5% monthly** → At this rate, the company is likely contracting. Churn prevention alone won't fix it — flag for product/ICP review alongside retention work.
---
## Output Artifacts
| When you ask for... | You get... |
|--------------------|-----------|
| "Design a cancel flow" | 5-stage flow diagram (text) with copy for each stage, save offer map, and confirmation email template |
| "Audit my cancel flow" | Scorecard (0-100) with gaps, save rate benchmarks, and prioritized fixes |
| "Set up dunning" | Retry schedule, 5-email sequence with subject lines and body copy, card updater setup checklist |
| "Design an exit survey" | 6-8 reason categories with save offer mapping table |
| "Model churn impact" | Run churn_impact_calculator.py with your inputs — monthly MRR saved and annual impact |
| "Write win-back emails" | 2-email win-back sequence (7-day and 30-day) with subject lines |
---
## Communication
All output follows the structured communication standard:
- **Bottom line first** — save rate estimate or recovery potential before methodology
- **What + Why + How** — every recommendation has all three
- **Actions have owners and deadlines** — no vague suggestions
- **Confidence tagging** — 🟢 verified benchmark / 🟡 estimated / 🔴 assumed
---
## Related Skills
- **customer-success-manager**: Use for health scoring, QBRs, and expansion revenue. NOT for cancel flow or dunning.
- **email-sequence**: Use for lifecycle nurture and onboarding emails. NOT for dunning (use this skill for dunning).
- **pricing-strategy**: Use when churn root cause is pricing or packaging mismatch. NOT for save offer design (use this skill).
- **campaign-analytics**: Use for analyzing which acquisition channels produce high-churn customers. NOT for setting up retention tracking.
- **signup-flow-cro**: Use for reducing drop-off at signup. NOT for post-signup retention.
Starter prompts for the main use cases—copy and use them directly.
Design a clear cancellation and exit-survey flow Use for: Design a clear cancellation and exit-survey flow. Prepare: Subscription terms, churn split, cancellation reasons, approved offers, payment process, and baseline metrics.
Use the installed churn-prevention Skill. Task: Design a clear cancellation and exit-survey flow. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. This is subscription-retention design, not physical-product returns processing. It does not charge cards, retry payments, or deploy cancel flows.[INPUT][CONSTRAINTS]Match approved save offers to cancellation reasons Use for: Match approved save offers to cancellation reasons. Prepare: Subscription terms, churn split, cancellation reasons, approved offers, payment process, and baseline metrics.
Use the installed churn-prevention Skill. Task: Match approved save offers to cancellation reasons. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. This is subscription-retention design, not physical-product returns processing. It does not charge cards, retry payments, or deploy cancel flows.[INPUT][CONSTRAINTS]Draft failed-payment reminders and scenario estimates Use for: Draft failed-payment reminders and scenario estimates. Prepare: Subscription terms, churn split, cancellation reasons, approved offers, payment process, and baseline metrics.
Use the installed churn-prevention Skill. Task: Draft failed-payment reminders and scenario estimates. Inputs: [INPUT]. Constraints: [CONSTRAINTS]. Check missing information first. Produce a reviewable result with evidence, assumptions, and next steps. This is subscription-retention design, not physical-product returns processing. It does not charge cards, retry payments, or deploy cancel flows.[INPUT][CONSTRAINTS]A fictional Gift Club subscription costs $24 monthly plus $5 shipping. Approved retention offers, subscription state and churn parameters support a clear cancellation and recovery flow.
Case input files: business-inputs.zip
Use the churn-prevention Skill.
Improve the cancellation journey for our replenishment subscription using the supplied reasons and unit economics. Design reason selection, one relevant optional offer, clear rejection and cancellation confirmation. Write the supporting cancellation, winback and payment-recovery emails, and calculate modeled revenue separately from shipping charges.
The attached business materials are:
- inputs/brief.json
- inputs/merchant.json
Deliver a complete result.md report that the operations team can read, plus any finished files needed for this task. Keep supporting calculations and evidence with the deliverables. Write the report in English; use the requested target language for customer-facing copy. The business datasets are fictional examples unless the brief explicitly names a live public website.The primary file produced by this prompt is shown below in its original language.
Adopt a short, reason-led cancellation journey and a separate payment-recovery process. At the supplied targets, the model retains 13 customers per monthly cohort, equivalent to $312 in product MRR before discounts. Shipping charges are $65 separately. First-cycle product revenue after the modeled discount is $283.20; contribution after product and shipping costs is $192.20, before other expenses.
The business data is synthetic and Gift Club is a proposed service. These are completed designs and modeled estimates, not measured results or implemented account changes. Customer copy is in English because no other target language was supplied. 🟡 denotes a modeled estimate; 🔴 denotes a planning assumption. Merchant terms are supplied inputs, not externally verified benchmarks.
The current journey cancels instantly without collecting reasons or sending confirmation; there is no dunning. Preserve easy cancellation while adding one question, at most one relevant optional offer, explicit confirmation, and an immediate receipt. Do not introduce support approval for cancellation. Work on payment recovery alongside the cancellation flow: its modeled product opportunity is $168/month versus $144/month for voluntary saves.
| Monthly cohort model | Calculation | Result 🟡 |
|---|---|---|
| Subscribers | $24,000 / $24 | 1,000 |
| Gross churn | 1,000 × 5% | 50 |
| Voluntary losses | 50 × 60% | 30 |
| Payment-failure losses | 50 × 40% | 20 |
| Paid voluntary saves | 30 × 20% | 6 |
| Payment recoveries | 20 × 35% | 7 |
| Product MRR retained | (6 + 7) × $24 | $312 |
| Separate shipping charges | 13 × $5 | $65 |
| Remaining monthly churn | (50 − 13) / 1,000 | 3.7% |
| Annualized product run rate | $312 × 12 | $3,744 |
The annualized figure assumes a retained cohort continues for twelve months at full price. It is not a twelve-month cash forecast, compounding forecast, or lifetime value. No winback revenue is assumed. Pauses produce no revenue while paused and do not qualify as paid saves until a successful resumed payment. Reason frequencies and actual acceptance rates were not supplied, so the 20% target is not a prediction supported by an offer mix.
At full price, each shipment collects $24 product revenue plus $5 shipping, incurs $8 product cost and $4 shipping cost, and contributes $17 before payment fees, returns, taxes, support and acquisition costs. Discounted shipments collect $19.20 + $5 = $24.20 and contribute $12.20. Shipping contributes $1 per shipped order; it is not product MRR.
For conservative costing, assume all six paid saves receive the discount and all seven recoveries pay full price. First cycle: product revenue $283.20; shipping charges $65; collections $348.20; product cost $104; shipping cost $52; contribution $192.20. Across two paid cycles for the same retained cohort: product revenue $566.40, shipping charges $130, contribution $384.40. These figures assume both shipments occur and no subsequent churn. Full-price contribution resumes at $221 per cycle for 13 customers after the offer expires.
Reserve the entire $9.60 offer liability at acceptance. Six discounts cost $57.60 across two shipments, within the $200 monthly offer budget. A conservative monthly cap is 20 new grants ($192 committed), subject to existing commitments; never round up to 21 ($201.60). Budget allocation, eligibility and acceptance must be atomic. The offer code is an internal rule identifier, not a public coupon.
Subscription settings → Reason → One eligible relevant offer (or skip) → Confirm cancellation → Receipt + email
All proposed routes below are design destinations, not live links. Use accessible radio controls, visible labels, keyboard focus, inline errors and comfortably sized touch targets. Give acceptance and rejection comparable visual weight. No timers, preselected consent, or repeat offers after rejection.
1. Settings — /subscription
“HarborMug Gift Club · $24 per monthly shipment + $5 shipping = $29. Next renewal: December 3, 2026.”
Buttons: Manage subscription · Cancel subscription. Clicking cancel opens the reason screen directly; no separate intercept page.
2. Reason — /subscription/cancel/reason
“What’s the main reason you’re cancelling?” Select one reason. Optional field: “Anything else you’d like us to know?” Button: Continue. Error if empty: “Please select one reason. You can choose ‘Prefer not to say.’” Free text is never required.
| Radio label | Exactly one disposition |
|---|---|
| It costs too much | Approved discount if eligible; otherwise skip |
| I have more mugs than I need | One-cycle pause |
| My gifting project has ended | Two-cycle pause if eligible; otherwise skip |
| I need customization | No offer; no customization or roadmap promise |
| I’m switching to another option | No offer |
| I only wanted to try it | No offer |
| Other | No offer; optional feedback only |
| Prefer not to say | No offer |
These are proposed reason choices, not measured cancellation frequencies. Record a reason before routing. An ineligible customer goes directly to cancellation confirmation. Do not convert an unavailable offer into a generic discount or support gate.
3a. Price offer
“Save $9.60 over your next two shipments.”
“Pay $19.20 for the mug + $5 shipping = $24.20 per shipment for your next two shipments. After that, your monthly total returns to $29 ($24 + $5 shipping). Your next renewal is December 3, 2026. This offer is available once per customer in 180 days, cannot be combined with another offer, and will not be offered again within 30 days.”
Buttons: Apply discount and keep my subscription · No thanks, continue cancelling.
Eligibility requires price reason, unused 180-day allowance, no offer within 30 days, no stacking and available budget. Acceptance must succeed before showing: “Your discount is applied to your next two shipments. Each totals $24.20; later shipments return to $29.” On failure: “We couldn’t apply the offer. Your subscription has not changed.” Keep cancellation available.
3b. Pause offer
For excess supply: “Skip one monthly cycle.” Body: “No charge or shipment on December 3, 2026. Your subscription resumes January 3, 2027 at 10:00 a.m. Eastern Time, at $24 + $5 shipping = $29.”
For project ended: “Take a two-cycle break.” Body: “No charge or shipment on December 3, 2026 or January 3, 2027. Your subscription resumes February 3, 2027 at 10:00 a.m. Eastern Time, at $24 + $5 shipping = $29.”
Buttons: Pause until [resume date] · No thanks, continue cancelling. Acceptance receipt repeats skipped cycles and resume date, with Manage or cancel subscription. Dates above use the supplied next renewal; render actual dates before acceptance for each customer. Do not silently reset billing dates. A customer who declines proceeds directly to confirmation with no second offer.
4. Final confirmation — /subscription/cancel/confirm
“Cancel future shipments?”
“If you confirm, your subscription ends immediately on [effective date]. Your December 3, 2026 renewal will not be charged, and future recurring shipments will stop. Any prepaid shipments remain valid. Cancellation does not cancel or refund an order already paid for. Return requests are reviewed separately under our unused-within-30-days policy; final refunds require merchant approval.”
“We delete subscription preferences 90 days after the cancellation effective date, on [deletion date]. Legally required order records are kept separately. You can review a restart before then.”
Buttons: Confirm cancellation · Go back. Go back returns to subscription settings without re-showing an offer. Confirm is idempotent: stop future billing and fulfillment schedules, store the effective date and reason, then issue the receipt. Never report success until cancellation is committed.
5. Receipt
“Your HarborMug Gift Club subscription is cancelled as of [effective date]. Your December 3 renewal will not be charged. Future recurring shipments have stopped; prepaid shipments remain valid. We’ve sent your confirmation. Subscription preferences will be deleted on [deletion date].”
Links: Review restart options (/subscription/reactivate) and Get help (/support). Restart opens a review of price and next shipment date, with explicit consent to resume billing. It must not create an immediate charge merely from an email click.
Tokens in brackets must be populated from confirmed subscription and invoice state. Use a calendar date for every date token. Except for an immediate failure notice, scheduled sends and actions occur at 10:00 a.m. America/New_York. Use actual current invoice amounts: discounted product invoices are $19.20 + $5, rather than the standard $24 + $5.
Subject: Your HarborMug Gift Club subscription is cancelled
Your subscription was cancelled on [effective date]. Your next renewal on [next renewal date] will not be charged, and future recurring shipments have stopped. Prepaid shipments remain valid.
Cancellation does not refund existing orders. For a return request, contact support; unused items may be eligible within 30 days, with merchant approval required for a final refund.
Your subscription preferences will be deleted on [deletion date, effective date + 90 days]. Legally required order records are kept separately. You can review restarting your subscription here: [review restart link]. We’ll show the price and next shipment date before you confirm.
For help, reply to this email or visit [support link].
HarborMug
Subject: Ready for another HarborMug shipment?
If your gifting plans have changed, you can review restarting HarborMug Gift Club. The standard monthly shipment is $24 plus $5 shipping, totaling $29. You’ll see the next charge and shipment details before confirming.
Review my subscription → [review restart link]
HarborMug · [Unsubscribe link]
Send only for a recorded price objection with fresh offer eligibility and reserved budget. No automatic send for missing customization or other unmatched reasons. A discount already used during the prior 180 days disqualifies this send; cancellation does not reset eligibility.
Subject: Save $9.60 on two HarborMug shipments
If price was the sticking point, you can return with 20% off the product price for your next two shipments. Each shipment is $19.20 plus $5 shipping, totaling $24.20. After those two shipments, the monthly total returns to $29.
This offer cannot be combined with another offer and is available once per customer in 180 days. Review the offer and next billing date before deciding to restart.
Review my return offer → [offer review link]
HarborMug · [Unsubscribe link]
Suppress both marketing emails after reactivation, consent withdrawal, preference deletion, or a pending payment-failure case. Include unsubscribe functionality and the merchant’s verified postal footer before enabling marketing; no postal address was supplied. Marketing eligibility must be checked at send time, not only when queued.
Use one proposed manual policy: initial failure D0; eligible retries D3, D8 and D13; cancel unresolved subscriptions D16. This resolves conflicting schedules in the Skill references into one explicit operational design. Do not also enable an overlapping Smart Retry schedule. Verify processor support and card updater behavior before implementation; Stripe is proposed only and no settings were changed.
Immediately hold the unpaid shipment. Keep already prepaid shipments valid. A confirmed successful payment releases only the associated held shipment once. Suppress later reminders, retries and cancellation after recovery. Updating a card alone is not payment success. At D16 stop retries, cancel future renewals and prevent later auto-collection of the unfulfilled invoice; an explicit restart creates one reviewed payment path, never duplicate collection of old and new invoices.
| Day | Action at 10 a.m. Eastern unless immediate |
|---|---|
| 0 | Hold unpaid shipment; immediate failure email |
| 3 | Recheck state, retry if permitted, then send reminder only if still unpaid |
| 7 | Reminder with actual next retry date (D8) |
| 8 | Second permitted retry |
| 12 | Final reminder with D13 retry and D16 deadline |
| 13 | Last permitted retry |
| 16 | Recheck payment state, cancel unresolved subscription, send operational receipt |
For stolen_card, lost_card or fraudulent, do not retry that payment method. Ask neutrally for another method; do not disclose a fraud accusation. For expired_card, require updated details or a confirmed updater result before retry. For do_not_honor, permit only one retry at D3; for generic_decline, permit D3 and D8 only. For insufficient funds use D3/D8/D13 if permitted by processor advice. Unknown codes require processor guidance before retry. Every notice reflects actual permitted next action; never promise a retry for a blocked method. Card updates trigger at most one controlled attempt on the replacement method after explicit customer confirmation, with concurrency protection against scheduled retries.
Subject: Your HarborMug Gift Club payment didn’t go through
We couldn’t collect your payment of [invoice total] on [failure date]: [product amount] for the product plus [shipping amount] shipping. Your unpaid shipment is on hold. Prepaid shipments remain valid.
[Retryable: We plan to try again on [next permitted retry date]. / Replacement required: Please provide a different payment method. We won’t retry this payment method.]
Update payment method → [direct secure payment-update link]
Need help? Reply to this email or visit [support link].
HarborMug
Subject: Your HarborMug payment still needs attention
Your [invoice total] payment ([product amount] product + [shipping amount] shipping) is still unpaid, and that shipment remains on hold.
[If another retry is permitted: Our next payment attempt is [actual next retry date]. / Otherwise: A different payment method is needed; we won’t retry the current method.]
Update payment method → [direct secure payment-update link]
Reply if you need help.
HarborMug
Subject: Update your payment to release your HarborMug shipment
Your payment of [invoice total] is still unresolved: [product amount] product plus [shipping amount] shipping. Your unpaid shipment remains on hold.
[If permitted: We plan to try again on [D8 date]. / Otherwise: Please use a different payment method; no retry is scheduled on your current method.]
Update payment method → [direct secure payment-update link]
You can reply or visit [support link] for help.
HarborMug
Subject: Your HarborMug subscription will end on [D16 date] unless payment is resolved
Your [invoice total] payment ([product amount] product + [shipping amount] shipping) remains unpaid. Your unpaid shipment is on hold. If payment is not resolved before [D16 date] at 10:00 a.m. Eastern Time, we’ll cancel future renewals and recurring shipments. Prepaid shipments remain valid.
[If permitted: Our final scheduled attempt is [D13 date]. / Otherwise: We won’t retry the current payment method; please provide a different one.]
Update payment method → [direct secure payment-update link]
For help, reply or visit [support link].
HarborMug
Subject: Your HarborMug Gift Club subscription has ended
Your subscription ended on [effective date] because the [invoice total] payment ([product amount] product + [shipping amount] shipping) remained unresolved. We’ve stopped future renewals and recurring shipments. The unpaid shipment will not be dispatched; prepaid shipments remain valid.
Subscription preferences will be deleted on [effective date + 90 days]. Legally required order records are kept separately.
Update payment and review restart → [direct secure payment-update link with restart review]
Updating your details does not automatically restart billing. We’ll show the next charge and shipment before you confirm. Reply or visit [support link] if you need help.
HarborMug
| Owner | Deadline relative to approved launch | Completed design to implement / acceptance condition |
|---|---|---|
| Mia, support | Before launch | Approve English copy, return distinction, reason taxonomy and response handling; no refund promise |
| Alex, escalation owner | Before launch | Assign billing implementer; approve offer ledger, budget reservations and manual retry policy; verify card updater and decline handling |
| Assigned billing implementer, accountable to Alex | Before launch | Implement proposed routes, fulfillment holds and state-driven emails; test duplicate events, retries, payment success races, card replacement and cancellation |
| Mia | Launch + 7 days, then weekly | Review reasons, abandonment, complaints, consent suppression and held orders |
| Alex | Launch + 30 days, then monthly | Compare paid retention and contribution with target; adjust only with observed evidence |
Log cancel starts, reason selected, offer shown/accepted/declined, committed cancellation, pause/resume, paid retained renewal, failed invoice, permitted retry, payment success, recovery cancellation and marketing suppression. Store deduplicated event identifiers and offer history under controlled access. Apply the supplied preference-deletion policy and retain legally required order records separately; do not retain free-text feedback indefinitely by default.
Measure paid saves / unique voluntary cancel attempts; report pause acceptances separately. Recovery rate is unique failed invoices successfully paid / unique failed invoices in a matured cohort; also report subscribers recovered, since the model assumes one invoice per subscriber. Track time to recovery, product revenue after discounts, separate shipping charges, contribution, offer commitments, survey completion and cancellation completion time. Compare like cohorts and exclude already recovered invoices from follow-up counts. Dunning cannot be credited to voluntary retention as well. Targets are hypotheses; no causal lift has been established.
Boundary decisions: For the supplied project-ended customer with offer eligibility false, skip the pause and proceed to cancellation confirmation. For the supplied stolen-card failure, make zero automatic attempts on that card and use the replacement-required email wording. With marketing consent false, send operational notices only, never D7/D30 marketing. A voluntary cancellation stops recovery retries and holds any unpaid fulfillment; prepaid shipments remain valid. If modeling a 100% involuntary mix, voluntary paid saves are zero and the model yields 17.5 expected recoveries, $420 product MRR and $87.50 separate shipping charges; fractional counts are cohort expectations.
Input safeguards: Missing MRR stops calculation rather than substituting a sample value. A 150% target save rate is rejected. Revenue and per-customer revenue must be positive; percentages must be numeric and within 0–100. The supplied inputs reconcile: 1,000 × $24 = $24,000 product MRR. No annual plan is assumed.
Sources: inputs/brief.json supplies the financial targets; inputs/merchant.json supplies economics, subscription terms, boundary cases and constraints. The original churn-prevention Skill, its cancel-flow playbook, dunning guide and calculator informed this design. Merchant constraints take priority over generic SaaS access-loss language, multi-offer suggestions and conflicting retry examples.
calculations.json contains exact model outputs and rejected-input checks. calculate.py reproduces the business model from the supplied inputs. skill-calculator.txt preserves the original Skill calculator run. That calculator rounds dollars and includes a simplified LTV estimate; its LTV is not used in the recommendation because shipping, discounts, costs and future retention are not modeled there.
The material launch gaps are the absence of an implemented subscription/payment system, verified marketing postal footer and observed reason/offer performance. The merchant must validate these before sending or charging; no customers were contacted and no accounts were modified.
Merchant business data is synthetic. Website observations, when present, come from the public URLs listed in the report.
This is subscription-retention design, not physical-product returns processing. It does not charge cards, retry payments, or deploy cancel flows.
Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.
Use authorized inputs and keep secrets out of prompts. Review customer-facing claims, calculations, code changes, and any proposed external action before applying them.
Design subscription cancel flows, save offers, exit surveys, and failed-payment recovery sequences. The source separates voluntary cancellation from involuntary churn and includes a local impact calculator.
Choose the method for your agent and install the complete package, not just the displayed SKILL.md. Subscription terms, churn split, cancellation reasons, approved offers, payment process, and baseline metrics. Start a new agent session and explicitly ask to use churn-prevention. Try one use case below with a small sample and review the output.
Design a clear cancellation and exit-survey flow; Match approved save offers to cancellation reasons; Draft failed-payment reminders and scenario estimates
This is subscription-retention design, not physical-product returns processing. It does not charge cards, retry payments, or deploy cancel flows.
Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.
Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.
Source and package files reviewed: GitHub 6d2f02ea077e. This is a static review, not an installation or business-outcome test.
No reviews yet.