# Churn Feedback Loop Tracker

The five-stage tracker that connects a cancellation to a shipped change.
From saasfeedback.ai — https://saasfeedback.ai/blog/churn-feedback-loop-product-roadmap

---

## Stage 1 — Detect

| Event | Source | Automated? | Owner |
|---|---|---|---|
| Subscription cancelled | Stripe webhook | | |
| Trial expired, no conversion | Billing / product | | |
| Downgrade | Stripe webhook | | |
| Payment failed ×2 | Stripe webhook | | |
| 21 days no login, paid plan | Product analytics | | |

Target: every row automated, with an owner. A detection step that depends on
someone remembering will fail in the month you are busiest — which is also the
month churn spikes.

---

## Stage 2 — Collect

| Metric | This month | Last month | Target |
|---|---|---|---|
| Churn events detected | | | |
| Conversations attempted | | | |
| Conversations completed | | | |
| **Completion rate** | | | >40% |
| Median days from event to conversation | | | <7 |

The days-to-conversation metric is the one nobody tracks and the one that most
affects answer quality. At 30 days you are collecting a tidy narrative; at 3 you
are collecting what happened.

---

## Stage 3 — Categorise

| Theme | Accounts | MRR lost | Response class | Verbatim |
|---|---|---|---|---|
| | | | build / fix / teach / position / package | |
| | | | | |
| | | | | |

Keep the verbatim column populated. A theme without an exact customer sentence
attached will lose every roadmap argument it enters, regardless of its numbers.

---

## Stage 4 — Prioritise

Rank by MRR at risk, not by frequency.

```
priority_score = (churned_MRR + at_risk_MRR) / estimated_effort_weeks
```

`at_risk_MRR` is the sum of *still-active* accounts showing the same signal. This
is the number that turns a churn post-mortem into a prevention argument — and it
is almost always larger than the churned figure, which is why frequency-ranked
lists systematically under-prioritise the right work.

| Theme | Churned MRR | At-risk MRR | Effort (wks) | Score | Decision | Owner |
|---|---|---|---|---|---|---|
| | | | | | | |

---

## Stage 5 — Measure

For each shipped fix, record the counterfactual you are testing.

| Shipped | Date | Theme | Metric watched | Baseline | 30 days | 90 days |
|---|---|---|---|---|---|---|
| | | | | | | |

Pick the metric before you ship, not after. Post-hoc metric selection is how
teams convince themselves every release worked.

**Also track loop closure:**

- [ ] Accounts who raised it, told it shipped
- [ ] Churned users who raised it, offered a win-back with evidence
- [ ] Declined themes, reason recorded and communicated

---

## The monthly one-pager

Everything above compresses into this. If it does not fit on one page, the loop
has become a reporting exercise rather than a decision tool.

> **Month:** ___
> **Churn events:** ___ | **Conversations:** ___ | **Completion:** ___%
> **Top theme by MRR at risk:** ___
> **Best verbatim of the month:** "___"
> **Shipped against churn themes:** ___
> **Loops closed:** ___